Access Control Lists are one of the first things I learned when I started studying for my networking certifications, and honestly, they are still one of the most used tools in my day-to-day work. Whether you are filtering traffic, controlling remote access, or building the foundation for more advanced security policies, ACLs are everywhere in Cisco environments. In this article, I will walk you through everything from the fundamentals to full configuration, verification, and troubleshooting of both Standard and Extended ACLs.
What Is an Access Control List?
An Access Control List is a sequential list of permit or deny statements that a Cisco device uses to filter traffic. ACLs can be applied to interfaces, VTY lines, or even routing protocols. They operate by comparing packets against a list of rules, from top to bottom, and taking action on the first match. If no rule matches, an implicit deny at the end of every ACL drops the traffic.
There are two main categories you need to understand at a foundational level:
- Standard ACLs – filter based only on source IP address
- Extended ACLs – filter based on source IP, destination IP, protocol, and port numbers
Cisco also supports named ACLs (as opposed to numbered), which are easier to manage and edit in modern deployments.
How ACLs Work: Protocol-Level Operation
When a packet arrives at an interface with an ACL applied, the router or switch checks the packet against each line of the ACL in order. As soon as a match is found, the corresponding action (permit or deny) is applied, and no further lines are evaluated. This top-down, first-match behavior means that ACL statement order matters enormously — a common source of misconfiguration.
Packet flow with ACL applied:
- Packet enters or attempts to exit an interface.
- Router checks if an ACL is applied inbound or outbound on that interface.
- Router compares the packet against each ACL entry sequentially.
- On first match, action is taken (permit/deny).
- If no match is found, the implicit “deny any” at the end drops the packet.
Standard vs Extended ACLs: Number Ranges
- Standard ACLs: numbered 1–99 and 1300–1999
- Extended ACLs: numbered 100–199 and 2000–2699
- Named ACLs can be either standard or extended, identified by a descriptive name instead of a number
Lab Topology
[PC-A 10.0.0.10] --- [Switch] --- G0/0 [Router R1] G0/1 --- [Server 172.16.0.10]
We will configure ACLs on R1 to control traffic between the LAN and the server subnet.
Standard ACL Configuration
Standard ACLs should always be placed as close to the destination as possible, since they filter based on source address only and cannot make more granular decisions.
Router> enable
Router# configure terminal
Router(config)# access-list 10 permit 10.0.0.0 0.0.0.255
Router(config)# access-list 10 deny any log
Applying it to an interface:
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group 10 out
Router(config-if)# exit
This permits only traffic sourced from the 10.0.0.0/24 subnet outbound on G0/1, and denies (and logs) everything else.
Named Standard ACL Example
Router(config)# ip access-list standard ALLOW-LAN
Router(config-std-nacl)# permit 10.0.0.0 0.0.0.255
Router(config-std-nacl)# deny any log
Router(config-std-nacl)# exit
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group ALLOW-LAN out
Extended ACL Configuration
Extended ACLs should be placed as close to the source as possible, since they can filter with much greater precision and there is no benefit in letting unwanted traffic traverse the network first.
Router(config)# ip access-list extended RESTRICT-SERVER
Router(config-ext-nacl)# permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 443
Router(config-ext-nacl)# permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 22
Router(config-ext-nacl)# deny ip any host 172.16.0.10 log
Router(config-ext-nacl)# permit ip any any
Router(config-ext-nacl)# exit
Apply it inbound on the interface closest to the source:
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip access-group RESTRICT-SERVER in
This configuration allows only HTTPS (443) and SSH (22) traffic from the LAN to reach the server, denies and logs everything else destined to that host, and permits all other traffic elsewhere.
Verification
Router# show access-lists
Standard IP access list ALLOW-LAN
10 permit 10.0.0.0, wildcard bits 0.0.0.255
20 deny any log
Extended IP access list RESTRICT-SERVER
10 permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 443 (12 matches)
20 permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 22 (3 matches)
30 deny ip any host 172.16.0.10 log (5 matches)
40 permit ip any any (240 matches)
Router# show ip interface GigabitEthernet0/0 | include access list
Inbound access list is RESTRICT-SERVER
The match counters next to each line are extremely useful for confirming that traffic is hitting the rules you expect.
Real-World Enterprise Scenario
A typical enterprise use case is restricting access to a finance department’s file server. Only the finance VLAN and IT administrative subnet should be able to reach it, and only over specific protocols like SMB (445) and RDP (3389) for administration. An extended named ACL applied inbound on the finance server’s access-layer interface handles this cleanly:
Router(config)# ip access-list extended FINANCE-SERVER-ACCESS
Router(config-ext-nacl)# permit tcp 10.10.10.0 0.0.0.255 host 172.16.5.20 eq 445
Router(config-ext-nacl)# permit tcp 10.10.20.0 0.0.0.255 host 172.16.5.20 eq 3389
Router(config-ext-nacl)# deny ip any host 172.16.5.20 log
Router(config-ext-nacl)# permit ip any any
This is the kind of segmentation policy that shows up constantly in real enterprise network security designs, especially when preparing for a compliance audit.
Security Considerations
- Always end sensitive ACLs with an explicit
deny ip any any logstatement, even though it is implicit, so that you get visibility through logging. - Avoid overly permissive rules like
permit ip any anyearly in the list, since it can unintentionally allow the traffic you meant to restrict further down. - Combine ACLs with CoPP (Control Plane Policing) to protect the router itself from being overwhelmed by traffic targeting its control plane.
- Regularly review ACLs for stale entries, especially after server decommissioning or IP re-addressing projects.
Best Practices
- Use named ACLs instead of numbered ACLs for readability and easier editing.
- Place standard ACLs close to the destination and extended ACLs close to the source.
- Use sequence numbers so you can insert or remove specific lines without rewriting the whole ACL:
Router(config)# ip access-list extended RESTRICT-SERVER
Router(config-ext-nacl)# 15 permit tcp 10.0.0.0 0.0.0.255 host 172.16.0.10 eq 3389
- Document the purpose of each ACL directly in the configuration using the
remarkkeyword:
Router(config-ext-nacl)# remark Allow finance VLAN SMB access to file server
- Test ACL changes during a maintenance window, since a misplaced deny statement can cause a full outage.
Optimization and Performance Tuning
- Order your ACL entries so that the most frequently matched rules appear first; since ACLs are processed sequentially, this reduces average CPU cycles per packet.
- On platforms supporting CEF, ACL processing is hardware-accelerated, so keep ACLs as simple and specific as possible to take full advantage of this.
- Avoid excessively long ACLs on lower-end routers, since very large ACLs can introduce latency on platforms without hardware-based ACL processing (like most ISR routers running purely in software).
- Use object groups on ASA firewalls (or class-maps on IOS-XE) to simplify and speed up management of large rule sets.
Troubleshooting and Common Configuration Mistakes
Mistake 1: Forgetting the implicit deny Every ACL ends with an implicit deny any. If you only write permit statements and forget this, all unlisted traffic silently gets dropped, which frequently causes “mystery” connectivity issues.
Mistake 2: Wrong wildcard mask Wildcard masks are the inverse of subnet masks. Using a subnet mask by mistake (like 255.255.255.0 instead of 0.0.0.255) is one of the most common beginner errors.
Mistake 3: Applying ACL in the wrong direction Applying an ACL in when it should be out (or vice versa) is a very frequent mistake, especially for engineers new to the concept of interface direction relative to the router.
Mistake 4: Standard ACL applied too close to the source Since standard ACLs match only on source address, applying them near the source can unintentionally block traffic meant for other destinations.
Useful troubleshooting commands:
Router# show access-lists
Router# show ip interface GigabitEthernet0/0
Router# debug ip packet detail 101
Router# show logging | include %SEC-6-IPACCESSLOGP
Frequently Asked Questions
Q: What is the difference between a wildcard mask and a subnet mask? A wildcard mask uses inverted logic compared to a subnet mask — a 0 bit means “must match” and a 1 bit means “don’t care,” which is the opposite of how subnet masks work.
Q: Can I apply more than one ACL per interface? You can apply one ACL per protocol, per direction, per interface — meaning one inbound and one outbound IP ACL per interface.
Q: Do ACLs affect router-generated traffic? Standard outbound ACLs on an interface do not filter traffic originated by the router itself unless it is explicitly routed back through that interface; this is a nuance that often confuses newer engineers.
Q: What is the difference between an ACL and a firewall? ACLs perform stateless packet filtering based on defined rules, while a dedicated firewall (like a Cisco ASA or firewall appliance) typically performs stateful inspection, tracking the state of active connections.
Q: Can ACLs filter based on time of day? Yes, using time-based ACLs, which reference a time-range object to restrict when a rule is active.
Summary and Key Takeaways
ACLs are foundational to Cisco network security and traffic control. Standard ACLs filter based on source address alone and belong close to the destination, while Extended ACLs offer granular control over source, destination, protocol, and port, and belong close to the source. Understanding the sequential, first-match nature of ACL processing — along with the implicit deny at the end of every list — will save you from the majority of real-world misconfigurations. Whether you’re securing a single interface or building a full segmentation policy across an enterprise network, mastering ACLs is a non-negotiable skill for any serious Cisco engineer.
References
- Cisco IOS Security Configuration Guide, Access Control Lists: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/xe-16/sec-data-acl-xe-16-book.html
- Cisco Comparing Standard and Extended ACLs: https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html
