Quick Summary
- ACLs are ordered lists of permit/deny rules applied to router interfaces
- Rules are evaluated top-to-bottom -- the first match wins, remaining rules are ignored
- Most ACLs end with an implicit "deny all" -- if no rule matches, the packet is dropped
What is an Access Control List?
An Access Control List (ACL) is a set of rules that a router or firewall uses to decide whether to allow or block network traffic. Think of it like a bouncer at a club with a guest list -- each person (packet) is checked against the list, and the first matching entry determines whether they get in or are turned away. ACLs are one of the most fundamental security mechanisms in networking, used on virtually every enterprise router and switch in the world.
ACLs operate at the network layer (Layer 3) and sometimes the transport layer (Layer 4) of the OSI model. A standard ACL filters traffic based on source IP address only, while an extended ACL can filter based on source and destination IP addresses, protocol type (TCP, UDP, ICMP), source and destination port numbers, and even specific TCP flags. This granularity lets network administrators create very precise traffic policies.
Every ACL is bound to a specific interface on the router and applied in a specific direction -- either inbound (filtering packets as they arrive at the interface) or outbound (filtering packets as they leave). This per-interface, per-direction binding gives administrators fine-grained control over traffic flow at every point in the network.
How ACL Rule Matching Works
The critical concept to understand about ACLs is first-match processing. When a packet arrives at an interface with an ACL applied, the router checks each rule from top to bottom. The moment it finds a rule that matches the packet, it takes the specified action (permit or deny) and stops processing. No further rules are evaluated. This means rule ordering is everything -- placing a broad "permit any" rule at the top would render all subsequent deny rules useless.
If no rule in the ACL matches the packet, most implementations apply an implicit deny all at the end. This is a critical safety feature: by default, anything not explicitly permitted is blocked. Administrators must remember this when creating ACLs -- if you forget to add a permit rule for legitimate traffic, it will be silently dropped by the implicit deny.
Interactive ACL Simulator
Try it yourself -- select a packet below and click "Evaluate" to see which ACL rule matches first. Watch how rule order determines the outcome.
ACL Evaluation Engine
ACL Types: Standard vs. Extended
Standard ACLs
Standard ACLs filter traffic based solely on the source IP address. They are numbered 1-99 and 1300-1999 on Cisco devices. Because they can only look at source addresses, they should be placed as close to the destination as possible -- placing them near the source would block that source's traffic to all destinations, not just the intended one. Standard ACLs are simple but limited; they cannot distinguish between different types of traffic from the same source.
Extended ACLs
Extended ACLs can filter on source IP, destination IP, protocol, source port, destination port, and more. They are numbered 100-199 and 2000-2699. Because they can be very specific about what traffic to match, they should be placed as close to the source as possible -- this prevents unwanted traffic from traversing the network at all. Extended ACLs are the workhorse of network security, used for everything from blocking specific services to implementing complex security policies.
Named ACLs
Named ACLs use descriptive names instead of numbers, making them easier to manage and understand. A named ACL like "BLOCK-TELNET" is far more readable than "access-list 101." Named ACLs also allow you to delete and insert individual rules without removing the entire ACL -- a significant advantage when managing complex rule sets on production routers where mistakes can cause outages.
Where ACLs Are Applied
ACLs are applied to router interfaces in one of two directions. An inbound ACL filters packets as they arrive at the interface, before the router makes a routing decision. An outbound ACL filters packets after the routing decision, just before they are forwarded out the interface. The direction you choose affects both performance and behavior.
Inbound ACLs are generally preferred because they drop unwanted traffic before the router wastes CPU cycles routing it. However, outbound ACLs are useful when traffic from multiple inbound interfaces needs to be filtered before exiting through a single outbound interface. A common pattern is to apply extended ACLs inbound on untrusted interfaces (like the internet-facing interface) and standard ACLs outbound on trusted interfaces for additional layer of control.
Real-World ACL Examples
Block SSH from Outside
Deny TCP traffic to port 22 from any external source. This prevents unauthorized remote access to your network devices while still allowing SSH between internal subnets. A critical rule on every internet-facing router.
Allow Web Traffic Only
Permit only TCP ports 80 and 443 outbound from a guest network. This lets visitors browse the web but blocks everything else -- no file sharing, no SSH, no remote desktop. Combined with the implicit deny, this creates a tight policy.
Restrict Management Access
Permit Telnet/SSH only from a specific management subnet (like 10.0.99.0/24). Applied as an inbound ACL on the VTY lines of routers and switches, this ensures only authorized administrators can access device CLI.
Common ACL Mistakes
Wrong Rule Order
Placing a broad "permit any" above specific deny rules renders those denies useless. Because first-match wins, the broad permit catches everything before the denies are ever reached. Always place the most specific rules at the top.
Forgetting the Implicit Deny
Creating an ACL with only deny rules and forgetting that the implicit deny at the end will block everything else too. If you deny SSH but forget to permit web traffic, all traffic gets dropped. Always include explicit permits for legitimate traffic.
Wrong Interface Direction
Applying an ACL in the wrong direction is a classic mistake. An inbound ACL on the wrong interface might block traffic you intended to permit, or worse, have no effect at all because the traffic never enters through that interface.
ACL Best Practices
When designing ACLs, follow the principle of least privilege: deny everything by default and only permit what is specifically needed. Document every rule with comments explaining its purpose -- a rule that made sense six months ago might be a mystery today. Test ACLs in a lab environment before deploying to production, and always have a rollback plan.
Keep ACLs as short as possible. Long ACLs with hundreds of rules are difficult to maintain, slow to process, and prone to errors. If your ACL is growing unwieldy, consider whether a different approach -- like VLANs, firewalls, or network segmentation -- might be more appropriate. Regular ACL audits are essential; remove rules for decommissioned servers and update rules when IP addresses change.
Finally, remember that ACLs are stateless -- they evaluate each packet independently without knowledge of connection state. For stateful inspection that tracks TCP sessions and automatically allows return traffic, you need a stateful firewall. ACLs and stateful firewalls are complementary tools, and most modern networks use both.
Frequently asked questions about ACLs
What is an ACL in networking?
An ACL (Access Control List) is an ordered list of permit and deny rules applied to a router or switch interface. Each packet entering or leaving that interface is checked against the rules from top to bottom, and the first matching rule decides whether the packet is forwarded or dropped.
Why does ACL rule order matter?
ACLs use first-match processing: the moment a packet matches a rule, the router takes that action and stops evaluating. A broad permit rule placed at the top will silently override every deny rule below it. Always place specific deny rules before more permissive permit rules.
What is the difference between a standard and extended ACL?
A standard ACL filters only on the source IP address. An extended ACL can match on source IP, destination IP, protocol (TCP/UDP/ICMP), source port, destination port, and TCP flags, giving you much finer control over which traffic is permitted.
What is the implicit deny in an ACL?
Every ACL ends with an invisible deny any any rule. If a packet does not match any explicit rule, it is dropped by default. This is why you must explicitly permit return traffic, management traffic, and anything else you want to allow.
Are ACLs the same as a firewall?
No. ACLs are stateless — each packet is evaluated independently with no knowledge of connection state. A stateful firewall tracks TCP sessions and automatically permits return traffic. Modern networks usually combine both: ACLs for cheap line-rate filtering and firewalls for deep inspection.
Fix a rule-order mistake
You just learned how rule order makes or breaks a policy. The same first-match logic runs firewalls: open a lab where a deny-all at priority 1 blocks everything, trace packets to see which rule stops them, and reorder the rules until HTTP gets through while SSH stays blocked. Router ACLs are in the app too, as permit and deny rules on a router interface, inbound or outbound.
Launch the rule-order lab →