An IPv4 access control list, or ACL, is an ordered set of permit and deny rules used by a router or Layer 3 switch to classify and control traffic. ACLs are simple on paper, but small mistakes in rule order, wildcard masks, direction, or placement can block legitimate traffic or leave unwanted traffic permitted.

This lesson follows OSNTC.027: NAT and PAT. It also builds on OSNTC.024: Static Routing and Routing Tables and OSNTC.014: TCP and UDP Transport Basics. Routing decides where a packet can go; an ACL can decide whether that packet is permitted to continue.

Practical Networking — introduction to Cisco access control lists, including standard versus extended ACLs, interface direction, and where filtering occurs.

Learning Objectives

• Explain how an ACL processes packets from top to bottom.
• Distinguish standard and extended IPv4 ACLs.
• Calculate common wildcard masks.
• Configure named and numbered ACLs in Cisco IOS-style syntax.
• Apply an ACL inbound or outbound on an interface.
• Verify matches and troubleshoot incorrect ACL behavior.

ACLs Are Processed Top to Bottom

Cisco documents an ACL as a sequential collection of access control entries, or ACEs. The device tests a packet against each entry in order. The first matching entry determines the result. The remaining entries are not evaluated for that packet.

This makes rule order critical. A broad permit placed before a specific deny can make the deny unreachable. A broad deny placed too early can block traffic that a later rule was supposed to permit.

The end of an IPv4 ACL contains an implicit deny. If no configured rule matches, the packet is denied. Cisco’s current IOS XE ACL configuration guide explicitly describes this first-match behavior and implicit deny.

Standard ACLs

A standard IPv4 ACL primarily matches the source IPv4 address. Because it cannot normally distinguish destination address or TCP/UDP application port, it is a coarse filtering tool.

Example: permit only hosts in 10.20.30.0/24.

Command: access-list 10 permit 10.20.30.0 0.0.0.255

The numbered standard ACL ranges commonly used in Cisco IOS are 1–99 and 1300–1999. A named equivalent is easier to recognize later:

Named standard ACL: ip access-list standard USERS_ONLY
Permit rule: permit 10.20.30.0 0.0.0.255

Extended ACLs

An extended IPv4 ACL can match source address, destination address, protocol, and transport-layer ports. This makes it possible to express policies such as “allow this subnet to reach this server over HTTPS, but deny other traffic to that server.”

Example:

Extended ACL: ip access-list extended WEB_POLICY
Permit HTTPS: permit tcp 10.20.30.0 0.0.0.255 host 192.0.2.50 eq 443
Deny other traffic to the server: deny ip 10.20.30.0 0.0.0.255 host 192.0.2.50
Permit unrelated IP traffic: permit ip any any

The first line permits HTTPS from the user subnet to one server. The second denies other IP traffic from that subnet to the same server. The final line explicitly permits other IP traffic. Without that final permit, unmatched traffic would reach the implicit deny.

Pedro Lino Cáceres — practical Cisco ACL walkthrough covering standard and extended lists, configuration, application, verification, and troubleshooting.

Wildcard Masks

Cisco IPv4 ACLs commonly use wildcard masks. A wildcard bit of 0 means “this bit must match.” A wildcard bit of 1 means “ignore this bit.” For ordinary contiguous IPv4 subnet matching, the wildcard mask is the inverse of the subnet mask.

• /24 mask 255.255.255.0 → wildcard 0.0.0.255
• /26 mask 255.255.255.192 → wildcard 0.0.0.63
• /30 mask 255.255.255.252 → wildcard 0.0.0.3
• host 192.0.2.10 is shorthand for 192.0.2.10 0.0.0.0.
• any is shorthand for any IPv4 source or destination.

Inbound Versus Outbound

An ACL applied inbound evaluates packets as they enter an interface before the router forwards them. An ACL applied outbound evaluates packets after the routing decision as they leave an interface.

Interface: interface GigabitEthernet0/0
Apply ACL inbound: ip access-group WEB_POLICY in

Do not describe “in” and “out” from the user’s point of view. Always describe them relative to the interface on the router or switch.

Where Should the ACL Go?

A common design guideline is to place extended ACLs closer to the source when practical, because they can precisely reject unwanted traffic before it consumes more network resources. Standard ACLs are often placed closer to the destination because they match only source address and can unintentionally block that source from reaching multiple destinations.

That is a guideline, not a substitute for understanding the topology. Before applying an ACL, trace the packet path and confirm which interface and direction will see the packet.

Recent r/ccna discussion — learners compare the field order in standard and extended ACL entries, a useful reminder that extended ACLs add protocol, destination, and optional port matching.

ACLs and NAT Are Different Jobs

An ACL used by a NAT rule may identify which traffic should be translated, but that does not automatically make it a security filter. OSNTC.027 showed that NAT rewrites addressing information. An interface ACL permits or denies packets according to policy.

r/networking discussion — practitioners distinguish translation rules from access-control policy and explain why NAT and ACLs should not be treated as the same function.

Verification Commands

• show access-lists — displays ACL entries and match counters.
• show ip access-lists — displays IPv4 ACLs and counters.
• show running-config | section access-list — inspects configured lists.
• show running-config interface GigabitEthernet0/0 — confirms the ACL name and direction applied to the interface.
• show ip interface GigabitEthernet0/0 — can show inbound and outbound access-list assignments.

Counters are especially valuable. Generate one known test flow, inspect which entry increments, then compare the result with the intended policy. A rule with zero matches may be in the wrong order, on the wrong interface, in the wrong direction, or matching the wrong addresses.

Troubleshooting Order

1. Confirm the packet can be routed without the ACL.
2. Identify the exact source, destination, protocol, and destination port.
3. Trace the packet path through the device.
4. Confirm the ACL is attached to the expected interface.
5. Confirm the direction is correct.
6. Read entries from top to bottom and stop at the first match.
7. Check wildcard masks.
8. Check for an unintended implicit deny.
9. Generate controlled traffic and inspect hit counters.
10. Use packet capture only after the configuration and counters are understood.

Common ACL Failures

• Broad rule first: an early permit or deny prevents a later specific rule from ever matching.
• Wrong wildcard mask: the rule matches too many or too few addresses.
• Wrong direction: the ACL is correct but attached inbound when the packet is evaluated outbound, or vice versa.
• Wrong interface: the traffic never crosses the interface carrying the ACL.
• Forgotten implicit deny: required traffic is not explicitly permitted.
• Wrong transport port: the administrator confuses source and destination ports.
• NAT confusion: the ACL is being used only to classify translation traffic rather than to filter interface traffic.

Hands-On Exercise

Build a lab with user subnet 10.20.30.0/24, server subnet 192.0.2.0/24, and a router between them. Give the web server address 192.0.2.50.

1. Verify routing between both subnets before adding an ACL.
2. Create a named extended ACL that permits HTTPS from 10.20.30.0/24 to 192.0.2.50.
3. Deny other IP traffic from that subnet to the server.
4. Permit unrelated IP traffic.
5. Apply the ACL inbound on the user-facing routed interface.
6. Test HTTPS, ICMP, and one unrelated destination.
7. Run show ip access-lists and record the match counters.
8. Move the deny above the permit and observe how behavior changes, then restore the correct order.

Knowledge Check

1. What does “first match wins” mean in an ACL?
2. What does a standard IPv4 ACL normally match?
3. What additional fields can an extended ACL match?
4. What wildcard mask corresponds to 255.255.255.0?
5. What happens if no ACL entry matches a packet?
6. What is the difference between inbound and outbound ACL application?
7. Why can a NAT classification ACL be different from a security filtering ACL?

Answer Guide

1. The device stops evaluating the ACL at the first entry that matches the packet and applies that entry’s permit or deny action.
2. The source IPv4 address.
3. Source, destination, protocol, and—where applicable—transport-layer port information and other supported fields.
4. 0.0.0.255.
5. It reaches the implicit deny and is denied.
6. Inbound evaluates traffic entering an interface; outbound evaluates traffic leaving it.
7. A NAT ACL may only classify which traffic should be translated, while a filtering ACL controls whether traffic is allowed to pass.

Key Takeaway

ACL troubleshooting becomes predictable when you reason about five things in order: packet fields, rule order, wildcard masks, interface, and direction. Standard ACLs provide coarse source-based control. Extended ACLs add destination, protocol, and port precision. In every case, verify the packet path and counters instead of guessing.

For related switching behavior, review OSNTC.019: Spanning Tree Protocol. For Layer 3 reachability, return to OSNTC.024.

BitcoinVersus.Tech

Editor’s Note: Commands use common Cisco IOS/IOS XE syntax for instruction. Exact features, ranges, hardware behavior, and syntax can vary by platform and software release. Validate production policy against the documentation for the actual device and release.

We volunteer daily to improve the credibility of the information on this platform. If you would like to support the research, please donate here: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb

BitcoinVersus.tech is not a financial advisor. This media platform reports on technical and financial subjects purely for informational purposes.