Cisco IOS ACL Configuration

Cisco IOS / IOS-XEIntermediate

Named extended and standard ACLs with interface application for Cisco IOS/IOS-XE. Includes object-group references and time-based ACE support.

↓ example.txt

What is it?

An ACL (Access Control List) is an ordered list of permit/deny rules that a Cisco IOS router or switch evaluates against IP traffic. Each rule (ACE — Access Control Entry) matches on source/destination IP, protocol, and ports. The router processes rules top to bottom, and the first match wins. If no rule matches, the implicit 'deny any' at the end drops the packet. ACLs are the primary tool for traffic filtering on IOS devices — from blocking unwanted traffic to protecting management access.

✓ When to use

·Filtering traffic entering or leaving a router interface (inbound/outbound)
·Protecting the router's management plane — restrict SSH/Telnet to specific source IPs
·Defining 'interesting traffic' for VPN tunnels (crypto ACL)
·Rate-limiting or classifying traffic for QoS policies
·Blocking specific protocols or hosts between network segments

✗ When NOT to use

·Complex stateful firewall rules — use a dedicated firewall (ASA, Palo Alto) instead. IOS ACLs are stateless.
·Application-layer filtering (HTTP content, URL filtering) — IOS ACLs work at L3/L4 only
·High-availability environments requiring connection state tracking — ACLs don't track TCP sessions

How it compares

vs Cisco ASA ACLASA ACLs are stateful — return traffic for permitted connections is automatically allowed. IOS ACLs are stateless — you must explicitly permit return traffic (or use 'ip inspect' / ZBFW). ASA is better for perimeter security.

vs Zone-Based Firewall (ZBFW)ZBFW is Cisco IOS's stateful inspection feature. It's more complex to configure but tracks TCP sessions and is more secure. ACLs are simpler but require careful bidirectional rule design.

vs Palo Alto Security PolicyPalo Alto policies are application-aware (App-ID), user-aware, and fully stateful. IOS ACLs are only IP/protocol/port based. Palo Alto is far more capable for security use cases.

Prerequisites

→Understanding of wildcard masks: 0.0.0.255 matches any host in the /24 (inverse of subnet mask)
→Know which direction to apply the ACL: 'in' filters traffic as it arrives on the interface, 'out' filters before it leaves
→Plan the ACE order carefully — more specific rules must come before general ones
→Always include a permit for return traffic when filtering bidirectional flows (unless using stateful inspection)

Config Generator

Hostname *

Access Control Lists

ACL Entries

Apply to Interfaces

Verification commands

show ip access-lists

Show all ACLs with hit counts per ACE

Expected: Each ACE shows a match count. Zero matches may indicate the rule is never reached (blocked by an earlier rule).

show ip interface <interface>

Verify which ACLs are applied to an interface and in which direction

Expected: Shows 'Inbound access list' and 'Outbound access list' fields

show access-lists <name>

Show a specific ACL with its entries and hit counts

Expected: Entries with 0 hits may indicate misconfigured ACE or traffic not reaching the interface

Debug commands

debug ip packet <acl-name> detail

Debug packets matching a specific ACL — shows permit/deny decisions in real time

⚠ Generates heavy output. Only use in lab or maintenance window. 'undebug all' immediately after.

Common mistakes & fixes

⚡ Traffic blocked even though permit rule exists

Cause: A more specific deny rule above the permit is matching first, or wrong wildcard mask

Fix: Check ACE order with 'show ip access-lists'. Verify wildcard mask: 0.0.0.255 = last octet wildcard, not subnet mask.

⚡ Cannot SSH to router after applying ACL

Cause: ACL on VTY lines or inbound interface is blocking TCP 22 from management source

Fix: Check 'show running-config | section line vty' for applied ACLs. Add 'permit tcp <your-mgmt-ip> <wildcard> any eq 22' before the deny.

⚡ VPN traffic not triggering the tunnel (crypto ACL issue)

Cause: Crypto ACL is missing or doesn't match the actual traffic source/destination

Fix: Verify the crypto ACL with 'show crypto map'. The ACL source must be the local LAN, destination must be the remote LAN (opposite of the remote end).

⚡ Return traffic being blocked

Cause: Stateless ACL applied outbound is blocking TCP reply packets (SYN-ACK)

Fix: Add 'permit tcp any any established' to allow established TCP return traffic, or use 'ip inspect' for stateful inspection.