Monday, February 20, 2012
Can an ACL itself has an implicit deny after it is executed on an ip range?
Can an ACL itself has an implicit deny after it is executed on an ip range. to clarify see below:
20 access-list 101 permit ip 10.168.10 255.255.255.255 192.168.1.0 255.255.255.255
30 access-list 101 permit ip 10.168.1.10 255.255.255.255 192.168.2.0 255.255.255.255
40 access-list 101 permit ip 192.168.2.0 255.255.255.255 10.168.1.10 255.255.255.255
Does the acls in sequence 30 and 40 get invalidated because in ACL sequence 20,
the same IP address (10.168.1.10)is only permitted to 192,168.1.0
(hence packets going to 192.168.2.0 which are permited later will not be allowed
as they are dropped on a previous ACL). So later on when we added further access
for an IP which is part of an earlier ACL sequence it got negated because
access for the same IP has already been defined.
Also does sequence 20 negate sequence 40 although it is an ACL for packets
coming to 10.168.1.10 instead of packets going from it?
When an ACL is evaluated, it is evaluated in a first-match method. ACL's will have an implicit deny at the end. When evaluating whether a packet will be permitted or denied by an ACL, you need to consider each line of the ACL starting from the top. For instance in your example - if line 20 did not match, no decision has yet to be made on that packet. Line 30, then line 40 will be evaluated. If neither of those match, the packet will be implicitly denied.
So - in your question you asked if the source was matched in ACL line 20 - but the destination did not match, would it be implicitly denied since it did not fully match line 20? The answer is no. It will continue to be evaluated against the other ACL entries, in order, until a match is found (or not found - and it is implicitly denied).
The second part of your post asked about ACL's and traffic direction. When an ACL is applied to an interface, it must be applied with a direction. Remember, the direction is from the perspective of the interface with the ACL applied.
For example, say VLAN 10 is inclusive of 192.168.1.0/24, and the SVI (interface vlan 10) is 192.168.1.1. Let's also say that VLAN 20 is inclusive of 192.168.2.0/24, and the SVI is 192.168.2.1. You want an ACL to control traffic routing between these two subnets, and active hosts are 192.168.1.10 and 192.168.2.10.
If you applied an ACL as an "inbound" access-list on interface VLAN 10, the ACL would be applied to traffic entering the router from VLAN 10. Traffic between 192.168.1.10 and 192.168.2.10 would be evaluated with the source of 192.168.1.10 and the destination of 192.168.2.10. If your ACL included an entry that had a source of 192.168.2.10 and destination of 192.168.1.10, that line would never be matched in this scenario.
Alternatively, if you applied the ACL as an "outbound" on interface VLAN 10, this means it is evaluating the ACL on traffic leaving the router towards VLAN 10. With that in mind, traffic would be evaluated with a source of 192.168.2.10 and destination of 192.168.1.10. So that line that was never matched when it was applied as an inbound ACL would now be matched.
An exception to this is when you are routing between two subnets on the same interface (for instance with ip address secondaries configured). In this scenario the router is hairpinning traffic in and out the same interface, so the ACL has to include both directions.
Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.