From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Fri Aug 05 2005 - 13:44:02 GMT-3
I wanted to report back that I worked out a solution to nest ACLs by using a
service policy. I need to do this because the inbound ACL on my VPN router
has several hundred lines and it's becoming unmanagable being all grouped
together. A modular approach to the ACL should be much easier to manage.
Below I've included a small sample with notes for anybody interested. I've
minimally tested this but it appears to work as I thought it should. If
anybody has comments, suggestions or corrections, please feel free to speak
up. I will be testing this more in depth next week.
ip access-list extended A
permit ip host 10.1.1.1 host 192.168.1.1
ip access-list extended B
permit ip host 10.2.1.1 host 192.168.1.1
ip access-list extended C
permit ip host 10.3.1.1 host 192.168.1.1
ip access-list extended DROP
permit ip any any
NOTE: the DROP ACL filters all traffic that the other ACLs don't
specifically permit. Use "permit" here as you will deny later with the
"drop" option in the policy configuration.
class-map match-any INBOUND
match access-group name A
match access-group name B
match access-group name C
class-map DROP
match access-group name DROP
policy-map VPN
class INBOUND
class DROP
drop
NOTE: Make sure the class DROP is the last class in the policy so it will
function like the "deny all" at the end of an ACL. This class is critical
to add so the remaining traffic isn't assigned to the "class-default" class
where you are not permitted to configure the "drop" option. Class-default
class is under the policy whether it is configured or not.
Interface f0/0
service-policy input VPN
Of course there is quite a bit (20+ pages) of additional config that I left
out for the sake of simplicity. ;-)
Rik
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3