ACL Order and Implicit Deny

The First Law of ACLs: Order Is Everything

An Access Control List is not a loose collection of rules; it's a strictly ordered sequence. When a packet arrives at an interface with an ACL, the switch processes the list from the top down (from the lowest sequence number to the highest).

The instant it finds a statement that the packet matches, it executes the corresponding action (permit or deny) and stops processing the list for that packet. No subsequent statements are ever evaluated.

Let's see a clear demonstration of this principle.

The Classic Mistake: General Before Specific

This top-down, first-match rule leads to a critical design principle: More specific rules must always be placed before more general rules.

Consider a policy: "Deny the Sales subnet (192.168.10.0/24) from accessing the servers, but create an exception for the Sales Manager's PC (192.168.10.10) to have access."

If you write the general rule first, the specific exception will never be reached.

The correct sequence would be:

1. 10 permit ip host 192.168.10.10 ... (The specific exception)
2. 20 deny ip 192.168.10.0 0.0.0.255 ... (The general rule)

A packet from 192.168.10.10 hits line 10 and is permitted. The list processing stops.
A packet from any other host in the subnet, like 192.168.10.25, does not match line 10, so processing continues. It then matches line 20 and is denied.

The Second Law of ACLs: The Invisible 'Deny All'

What happens if a packet goes through the entire ACL and doesn't match any of the statements you wrote?

The answer is the second fundamental rule: every ACL ends with an invisible, unwritten statement that denies all traffic. This is called the implicit deny.

ip access-list extended MY_ACL
 10 permit tcp any host 10.1.1.5 eq 443
...
...
(implicit) deny ip any any 

The rationale for this is security. The default posture of a firewall or a filtered interface should be to deny everything and only explicitly permit what is known to be necessary.

This concept is visualized well in the following image.

Now, let's get the formal definition from a couple of resources.

Overriding the Implicit Deny

As the reading mentioned, the implicit deny causes a common problem: you write an ACL to deny one specific thing, apply it, and suddenly all traffic is blocked.

Example: You want to block a single problematic host, 10.20.30.40, from accessing the network.

You write this ACL:
ip access-list extended BLOCK_HOST
10 deny ip host 10.20.30.40 any

If you apply this to an SVI, you will not only block that host, but you will also block every other host because their traffic won't match line 10 and will be dropped by the implicit deny.

The solution is to add an explicit permit at the end to override the implicit deny.

Corrected ACL:
ip access-list extended BLOCK_HOST
10 deny ip host 10.20.30.40 any
20 permit ip any any

Now, traffic from 10.20.30.40 matches line 10 and is denied. All other traffic fails to match line 10, proceeds to line 20, is explicitly permitted, and network access is maintained for everyone else.

What's Wrong With This ACL?

Let's test your understanding by analyzing a couple of broken ACLs.

Scenario 1: The Ineffective Exception

• Policy: "The entire Finance VLAN (10.10.20.0/24) is blocked from accessing the Development server farm (10.10.50.0/24). However, the finance director's PC (10.10.20.5) must be allowed to access the main development server (10.10.50.100)."
• Attempted ACL:

  ip access-list extended FINANCE_OUT
   10 deny ip 10.10.20.0 0.0.0.255 10.10.50.0 0.0.0.255
   20 permit ip host 10.10.20.5 host 10.10.50.100
   30 permit ip any any
  

Question: Will the finance director be able to access the server? Why or why not?

Scenario 2: The Accidental Outage

• Policy: "Block Telnet (TCP port 23) and FTP (TCP port 21) access from the User VLAN (172.16.10.0/24) to the Server VLAN (172.16.20.0/24) for security reasons. All other access is fine."
• Attempted ACL:

  ip access-list extended USER_OUT
   10 deny tcp 172.16.10.0 0.0.0.255 172.16.20.0 0.0.0.255 eq 23
   20 deny tcp 172.16.10.0 0.0.0.255 172.16.20.0 0.0.0.255 eq 21
  

Question: What is the unintended consequence of applying this ACL?

Conclusion

You have now completed a deep dive into the two most critical rules of ACL processing. Internalizing these concepts is essential for designing and troubleshooting network security.

Key Takeaways:

• Top-Down, First-Match: The switch processes an ACL sequentially and stops at the first match. This dictates that you must place specific rules (e.g., permit host) before general rules (e.g., deny subnet).
• Implicit Deny is Always On: Every ACL has an invisible deny ip any any at the end. If a packet doesn't match any of your explicit rules, it will be dropped.
• Use permit ip any any Deliberately: To avoid accidental outages, you must add permit ip any any as the final entry in any ACL that is not intended to have a "default deny" posture.

In our next lesson, we will address the final piece of the ACL puzzle: directionality. We'll learn how to apply an ACL to an SVI in the correct direction (inbound or outbound) to enforce your policy with maximum efficiency and minimal impact on switch performance.