An Access Control List (ACL) is a sequential list of permit or deny statements that apply to IP addresses or upper-layer protocols. While Stateful Firewalls track entire sessions, ACLs are typically stateless and are traditionally deployed directly on Routers and Layer 3 Switches to perform basic traffic filtering.
Note: Terminology varies heavily by vendor. Cisco refers to them as ACLs, while cloud providers like AWS refer to them as Network ACLs (NACLs).
How ACLs Work (Top-Down Processing)
When a router receives a packet on an interface with an ACL applied, it reads the ACL rules sequentially from the top down.
- The router compares the packet to Rule 1. If it matches, it executes the action (Permit or Deny) and stops reading.
- If it doesn't match Rule 1, it moves to Rule 2, and so on.
- If the packet reaches the bottom of the list without matching any rule, it hits the Implicit Deny. The router silently drops the packet.
Standard vs Extended ACLs
In traditional routing environments (like Cisco IOS):
- Standard ACLs: Can only filter traffic based on the Source IP Address. They are simple but lack precision.
- Extended ACLs: Can filter based on Source IP, Destination IP, Protocol (TCP/UDP), and specific Network Ports.
Conceptual Example: Securing a Server
Imagine we have a web server at 198.51.100.10. We want to allow our internal office network (192.0.2.0/24) to access it via HTTPS, but block absolutely everyone else.
Because ACLs are stateless, if you apply this to a router, you must remember that traffic flows in two directions. If you apply an ACL blocking all inbound traffic from the server, the server's replies to the office PC will be blocked. You would need a complementary rule allowing return traffic.
Inbound vs Outbound Application
Writing an ACL is only half the job. You must apply it to a physical interface in a specific direction:
- Inbound (Ingress): Filters packets as they arrive into the router's interface, before the router makes a routing decision.
- Outbound (Egress): Filters packets as they exit the router, after the router has checked its routing table.
Common ACL Troubleshooting
1. The Shadowed Rule
Problem: You wrote a rule to permit 192.0.2.50, but it's being blocked.
Troubleshooting: Because ACLs are processed top-down, rule order is critical. If Rule 10 denies the entire 192.0.2.0/24 subnet, and Rule 20 permits 192.0.2.50, Rule 20 is "shadowed." The router drops the packet at Rule 10 and never even sees Rule 20. You must move the specific permit rule above the general deny rule.
2. Wrong Wildcard Mask / Subnet
Problem: An ACL is permitting traffic it shouldn't.
Troubleshooting: Many vendors (like Cisco) use inverse wildcard masks instead of standard Subnet Masks for ACLs. A standard mask of 255.255.255.0 becomes a wildcard mask of 0.0.0.255. Using the wrong notation will completely alter the scope of the rule.
3. Unexpected Implicit Deny
Problem: You applied an ACL to an interface to block one specific bad IP. Suddenly, the entire network went down.
Troubleshooting: You forgot the Implicit Deny. When you applied the ACL containing only one DENY statement, the router added an invisible DENY ANY at the bottom. To fix this, you must explicitly add a PERMIT ANY ANY rule at the very bottom of the ACL.
Best Practices
- Document Intent: Always add remarks or comments to your ACLs explaining why a rule exists and who requested it.
- Test Before Production: A single typo in an ACL can disconnect an entire datacenter.
- Least Privilege: Only permit exactly what is required. Avoid broad permits like "Permit IP Any Any" unless strictly necessary.