Most ACL mistakes are not syntax mistakes. They come from evaluating the packet in the wrong order, on the wrong interface, or in the wrong direction.
1. IOS stops at the first matching ACE
An access control entry is evaluated from top to bottom. When a packet matches one entry, IOS applies that permit or deny action and stops evaluating the list. Therefore, a broad entry placed too early can make every more-specific entry below it unreachable.
ip access-list extended WEB-IN
10 permit tcp 10.10.10.0 0.0.0.255 host 192.0.2.20 eq 443
20 deny ip 10.10.10.0 0.0.0.255 any
30 permit ip any anyHTTPS traffic to the server matches sequence 10. Other traffic from the source subnet matches sequence 20. Sequence 30 only processes packets that did not match either earlier entry.
2. Remember the implicit deny
Every IPv4 ACL ends with an implicit deny any or deny ip any any. It is not displayed as a configured line, but packets that reach it are discarded. Add an explicit final permit only when the security policy actually requires all remaining traffic to pass.
3. Determine direction from the router's perspective
The packet enters the router through the interface before the routing decision.
The packet has already been routed and is about to leave through the interface.
Trace one packet from source to destination. Name the interface where it enters and the interface where it exits. Only then choose in or out.
4. Use this verification sequence
- Read the ACL and its sequence:
show access-lists. - Confirm the exact interface and direction:
show ip interface. - Generate representative permitted and denied traffic.
- Read match counters again and confirm the intended ACE increments.
- If the policy is wrong, remove or resequence the erroneous ACE before retesting.