L3 · security · draft

IPv4 ACLs

IPv4 access control lists

Matches packet fields in order against permit and deny entries, then applies the first hit — with an implicit deny if nothing matched.

Presenter modeEmbed this figure

Packet Filtering and Access ListsRFC 1812 · PROPOSED STANDARD · June 1995Internet Header FormatRFC 791 · INTERNET STANDARD · September 1981Header FormatRFC 793 · INTERNET STANDARD · September 1981Cisco IOS XE 17.x — Creating an IP Access List §Information About Creating an IP Access List

Why it exists

Routers forward by destination. Operators also need to refuse traffic that would otherwise be routed correctly — by source, by application port, or by both. Access lists are that filter on the forwarding path. Packet Filtering and Access ListsRFC 1812 · PROPOSED STANDARD · June 1995

Vendor ACLs are the common teaching surface for that idea: ordered entries, first match, implicit deny at the end, and no effect until the list is applied to an interface or control plane feature. Cisco IOS XE 17.x — Creating an IP Access List §Information About Creating an IP Access List

Standard ACL: source address only

A standard list matches only the IPv4 source address. Applied inbound on the edge, it decides whether packets from a subnet are accepted before any other processing.

A standard ACL can see the source address and little else. Destination, protocol and ports are invisible to it — if you need those, the list must be extended. 10.99.1.10. 10.1.1.10. Edge · ACL in: ACL standard · source only. Inside.

10.99.1.1010.1.1.10Edge · ACL inACL: standard · source onlyInside
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
10.99.1.10host
10.1.1.10host
Edge · ACL inrouterACL: standard · source only
Insidecloud
10.99.1.10Edge · ACL inlinkup
10.1.1.10Edge · ACL inlinkup
Edge · ACL inInsidelinkup
1 / 3

A standard ACL can see the source address and little else. Destination, protocol and ports are invisible to it — if you need those, the list must be extended.

What changed

  • Edge · ACL in: ACL → standard · source only
  • Emphasis on Edge · ACL in

How it works

A standard list matches the IPv4 source address. An extended list can also match destination, protocol, and transport ports from the IP and TCP/UDP headers. Internet Header FormatRFC 791 · INTERNET STANDARD · September 1981

Entries are evaluated top-down. The first match decides permit or deny. If no entry matches, an implicit deny drops the packet. Cisco IOS XE 17.x — Creating an IP Access List §How to Create an IP Access List

Cisco-style wildcard masks invert subnet masks: 0 bits must match, 1 bits are don’t-care. 0.0.0.255 matches a /24; 0.0.0.0 is a host.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

IHL 5, so no options. DF is set because the sender is doing path MTU discovery — which is why a filtered ICMP turns this into a black hole rather than a retry at a smaller size.

Link layer
Ethernet with EtherType 0x0800, or whatever the medium uses to say "IPv4 follows". RFC 791
IPv4 header
Version, length, differentiated services, fragmentation control, TTL, protocol, addresses. RFC 791
Payload
Whatever the protocol field names — 1 for ICMP, 6 for TCP, 17 for UDP, 89 for OSPF, 103 for PIM. RFC 791

Configure it

Permit HTTPS to one host, deny the rest of that subnet, apply inbound.

Cisco IOS-XE 17.12 · ISR 4451, Catalyst 9500draft

  1. ip access-list extended EDGE-IN
     permit tcp any host 198.51.100.10 eq 443
     deny ip 10.99.0.0 0.0.255.255 any
     permit ip 10.1.0.0 0.0.255.255 any

    Specific permit first, then a broad deny, then a permit for the trusted source range. Order is the policy; an implicit deny still ends the list.

    Common mistake: Putting the deny for 10.99.0.0/16 above a host permit inside that range — the host never matches.

    Cisco IOS XE 17.x — Creating an IP Access List §Creating an Extended Access List

  2. interface GigabitEthernet0/0/0
     ip access-group EDGE-IN in

    Applies the list to packets entering this interface. Without this line the ACL does nothing.

    Cisco IOS XE 17.x — Creating an IP Access List §Applying an Access List to an Interface

Verify

show ip access-lists EDGE-IN
Entries and per-line match counts — not sample packet dumps.
show ip interface GigabitEthernet0/0/0
Which ACL is applied inbound and outbound.

Caveats

  • Wildcard bits are don’t-care (0.0.0.255 for /24), not subnet masks.
  • Outbound ACLs do not filter traffic originated by the router unless additional match-local features are enabled.

When it breaks

Symptom first, because that is what you have when it happens.

  1. A host that has an explicit permit is still dropped, and hit counters climb on an earlier deny.

    Narrow it down

    1. Read the list top-down against a packet that fails.
    2. Find the first matching entry — not the entry you intended.
    3. Check whether a broader deny sits above a more specific permit.

    Cause

    First-match evaluation. The deny matched first; later permits never ran.

    Fix

    Move the specific permit above the broad deny, or narrow the deny.

    Cisco IOS XE 17.x — Creating an IP Access List §How to Create an IP Access List
  2. Only the traffic you permitted works; everything else dies even though you never wrote a deny.

    Narrow it down

    1. Confirm whether the list is applied on the path the failing traffic takes.
    2. Account for the implicit deny at the end of every IP ACL.
    3. Check hit counts on the last explicit line versus unexplained drops.

    Cause

    Fall-through to the implicit deny. Absence of an explicit deny is not an implicit permit.

    Fix

    Add the missing permits for traffic that must pass, in the correct order, before relying on the list in production.

  3. The ACL looks correct and is applied, but the traffic it should catch is unaffected.

    Narrow it down

    1. Confirm in versus out on the interface relative to the device.
    2. Trace whether the packet enters or leaves that interface when filtered.
    3. Check whether a different interface is actually on the path.

    Cause

    Direction mismatch. Inbound filters packets entering the interface; outbound filters packets leaving it.

    Fix

    Re-apply on the correct direction, or move the list to the interface where the match keys are still visible.

  4. A line meant to match a /24 matches almost everything, or matches nothing.

    Narrow it down

    1. Compare the wildcard to the intended mask: 0 bits must match, 1 bits are free.
    2. Check for a dotted mask used where a wildcard was required.
    3. Test with a single host address (wildcard 0.0.0.0) as a baseline.

    Cause

    Subnet mask and wildcard mask inverted. 255.255.255.0 as a wildcard matches almost any host octet pattern incorrectly relative to intent.

    Fix

    Rewrite using don’t-care bits: 0.0.0.255 for a /24, 0.0.0.0 for a host.

  5. You need to allow one TCP port and block others to the same host; a standard ACL cannot express it.

    Narrow it down

    1. Confirm the list type: standard versus extended.
    2. Check whether destination or port appears in any line — standard lists reject that syntax.
    3. Verify the feature expecting the list accepts extended ACLs.

    Cause

    Standard ACLs match source address only.

    Fix

    Use an extended ACL (or vendor equivalent) that can match destination and ports.

    Cisco IOS XE 17.x — Creating an IP Access List §Information About Creating an IP Access List

Design notes

Place specific permits before broad denies. The opposite order silently disables the specifics.

Apply inbound to drop unwanted traffic before it consumes internal resources; apply outbound when the decision depends on the exit interface. Direction is relative to the device, not to the traffic’s ultimate destination.

An unapplied ACL does nothing. Creating the list is configuration; applying it is policy. Cisco IOS XE 17.x — Creating an IP Access List §Applying an Access List to an Interface

Misconceptions

You must end every ACL with deny ip any any.
IP ACLs already end with an implicit deny. An explicit final deny is optional and useful mainly when you want a logged counter on that line.
Every matching line in the list contributes to the decision.
Only the first match counts. Later lines are unreachable for that packet. Cisco IOS XE 17.x — Creating an IP Access List §How to Create an IP Access List
Creating the access list enforces it.
The list is inert until applied to an interface, a control-plane filter, a NAT reference, or another feature that consumes it. Cisco IOS XE 17.x — Creating an IP Access List §Applying an Access List to an Interface

More walkthroughs

Extended ACL: destination and TCP portsbaseline

An extended list matches source, destination, protocol and ports. A permit for TCP/443 to one host leaves other ports subject to later entries and the implicit deny.

The list permits tcp any host 198.51.100.10 eq 443. That line reads source, destination, protocol and destination port — all from the IP and TCP headers. Client. Edge · ACL out: ACL permit tcp any host 198.51.100.10 eq 443. Web · :443. Same host · :22.

ClientEdge · ACL outACL: permit tcp any host 198.51.100.10 eq 443Web · :443Same host · :22tcp/443tcp/22
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
Clienthost
Edge · ACL outrouterACL: permit tcp any host 198.51.100.10 eq 443
Web · :443host
Same host · :22host
ClientEdge · ACL outlinkup
Edge · ACL outWeb · :443linkup · tcp/443
Edge · ACL outSame host · :22linkup · tcp/22
1 / 3

The list permits tcp any host 198.51.100.10 eq 443. That line reads source, destination, protocol and destination port — all from the IP and TCP headers.

What changed

  • Edge · ACL out: ACL → permit tcp any host 198.51.100.10 eq 443

Order is the policyfailure

A broad deny sits above a specific permit. The permit never runs. Reordering — not adding another line at the bottom — is the fix.

Line 10: deny ip 10.1.1.0 0.0.0.255 any. Line 20: permit ip host 10.1.1.50 host 198.51.100.10. The host that should be allowed is inside the deny. 10.1.1.50. Edge: ACL 10 deny /24 · 20 permit host. Service host.

10.1.1.50EdgeACL: 10 deny /24 · 20 permit hostService host
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
10.1.1.50host
EdgerouterACL: 10 deny /24 · 20 permit host
Service hosthost
10.1.1.50Edgelinkup
EdgeService hostlinkup
1 / 3

Line 10: deny ip 10.1.1.0 0.0.0.255 any. Line 20: permit ip host 10.1.1.50 host 198.51.100.10. The host that should be allowed is inside the deny.

What changed

  • Edge: ACL → 10 deny /24 · 20 permit host
  • Emphasis on Edge

Terms

Wildcard mask
A Cisco ACL match mask where 0 bits must equal the address and 1 bits are don’t-care. It is the inverse of a subnet mask: 0.0.0.255 matches a /24; 0.0.0.0 matches one host.
Implicit deny
The invisible final deny at the end of an IP ACL. Traffic that matches no explicit entry is dropped — absence of a deny line is not a permit.
Extended ACL
An IPv4 access list that can match source, destination, protocol, and transport ports. Standard lists match source address only.

Check yourself

  • What does a standard IPv4 ACL match?
  • Which wildcard matches a single host?
  • A deny for a /24 sits above a permit for one host inside it. What happens to that host?
  • A packet matches no line in an applied IP ACL. What happens?
  • ip access-group FILTER in on GigabitEthernet0/0 filters packets that…
  • Which headers supply the match keys for permit tcp any host X eq 443?
  • You create an ACL but never apply it. What is its effect on forwarding?
  • Why put specific permits before broad denies?