LEARN. PRACTICE. GROW.Start with the observed flow
In a fictional APS example, an agent at 192.0.2.10 sends HTTPS to 198.51.100.20:443. The change request should identify actual source, destination, protocol and port, and the interface and direction where the ACL will apply. If NAT or a proxy exists, confirm addresses visible at that point; do not infer processing order from a logical diagram. Separate access to the router from traffic crossing it. An interface ACL and VTY line access control apply at different points. Capture a flow sample before writing the rule, including the response and required dependencies.
Order, sequence and shadowed rules
The exercise permits TCP from 192.0.2.0/24 to one host on port 443. A broad denial at sequence 5 prevents that flow from reaching the permit at sequence 10. If denial is at sequence 20, the first match still decides. No match ends at the filtering ACL’s implicit deny in this example. A change can fail even when the correct rule exists: another entry covering the same packets may precede it. Before moving a rule, identify other flows whose decisions change and test them. A maintenance exception should have a defined scope, owner and removal condition.
Wildcards and port position
For address matching, each zero wildcard bit requires equality and each one bit is ignored. With base 192.0.2.0, 0.0.0.255 covers the last octet; 0.0.0.0 selects the exact address. Wildcard 0.0.0.254 differs from a /24 mask: it preserves the least significant bit and, with this base, selects even last-octet values. The model checks.0 and.254 as matches, and.3 and 192.0.3.2 as non-matches. A port after the destination filters destination port; a port after the source filters source port. Do not transfer the request rule to the response without exchanging endpoint roles.
Permitting a request does not create session state
In the model, the TCP request uses source port 51000 and destination 443; the response uses source 443 and destination 51000. Applying the same ACL to the response creates no automatic permission. A return rule may match server and source port, but that is not a stateful firewall. The established keyword in a classic TCP ACL checks ACK or RST; it does not establish that the device observed a valid handshake. The model accepts an ACK packet for a session it never recorded precisely because it maintains no sessions. This demonstrates the predicate’s limitation, not a guarantee about the entire security architecture.
Acceptance with positive and negative tests
The original excerpt below is an IOS XE reading exercise, with no Cisco device execution. Build and review the complete ACL first; confirm its application point before attaching it to an interface. The acceptance matrix should include the authorized flow, an out-of-scope source, another port and another destination, plus return traffic. Compare counters over a known window with transaction evidence; an accumulated counter does not prove that the current request passed. Record dependency failures, such as name resolution or authentication, before broadening permissions. The next lesson’s Python model executes these decisions without networking but does not validate hardware, fragments, IPv6 or NAT behaviour.
! Original IOS XE reading exercise only; not executed on Cisco hardware.
ip access-list extended APS-HTTPS
10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.20 eq 443
20 deny ip any any! Do not attach this illustrative ACL without the complete flow inventory.! Inspection example:
show ip access-lists APS-HTTPS
Sequence 5 deny ip any any shadows the sequence 10 HTTPS permit.
Common pitfalls
Confusing interface and VTY ACLs; reversing source and destination ports; ignoring the first rule; treating established as stateful inspection.
Related topics: Network assurance and diagnosis · Infrastructure security and device access
Follow the actual packet, identify the first decision and also test what should remain blocked.
Reference: IP Access List Overview · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise