Advanced IPv4 Access Control Lists for CCNA 200-301: Configuration, Placement, and Troubleshooting

1. Introduction and Exam Relevance

For CCNA 200-301, when I say “advanced” IPv4 ACLs, I’m really talking about being able to follow packet flow the right way and build classic Cisco IOS or IOS XE ACLs without just stabbing in the dark. You should be able to answer four questions pretty quickly: which interface sees the packet first, is the ACL applied inbound or outbound, which ACE gets hit first, and what happens if nothing matches at all. Honestly, that’s the real skill the exam is checking, and it’s the same skill that makes ACLs actually useful in production networks.

ACLs still show up everywhere: inter-VLAN filtering, branch-to-HQ restrictions, management access control, basic edge filtering, and NAT matching. This article focuses on classic IPv4 ACL behavior as tested in CCNA. Minor syntax, hardware forwarding, logging behavior, and verification details can vary by platform and release, especially on multilayer switches where ACLs may be compiled into hardware resources such as TCAM.

2. ACL Processing Order and Packet Path

An ACL is an ordered list of ACEs. The device evaluates entries from top to bottom. First match wins. If no entry matches, there is an implicit deny at the end. Conceptually, that behaves like a final deny, although the exact syntax context still depends on ACL type.

The packet path matters:

So basically, the packet shows up, the inbound ACL gets first crack at it, then the router or switch does the routing lookup, and after that it checks the outbound ACL if one’s in place before finally forwarding the packet.

When you apply an ACL inbound, the device checks that packet before it’s even figured out the next hop or exit interface. If it is applied outbound, routing happens first, then the packet is checked before leaving the interface.

ACLs are stateless. They do not track sessions like a firewall. Each packet is evaluated on its own. That does not mean you always need mirrored ACLs in both directions. It means you must evaluate the actual reverse path. If there is no ACL on the return path, replies may work fine. If there is an ACL on the reverse path, you must account for reply traffic too.

Also remember a common troubleshooting point: interface ACLs affect traffic traversing that interface. Traffic originated by the router or switch itself is not always filtered the same way as transit traffic. That matters when the device can ping something even though hosts behind it cannot.

3. Standard vs Extended ACLs

Standard ACLs are pretty simple—they only care about the source IPv4 address, and that’s it. Extended ACLs give you way more control, honestly, because they can match the source, the destination, the protocol, and, for TCP or UDP, the Layer 4 ports too. Standard ACLs are broad tools. Extended ACLs are precise tools.

The usual design guideline is: standard ACLs near the destination, extended ACLs near the source. That is a best practice, not a hard law. The reason is simple. A standard ACL cannot distinguish destinations, so placing it too close to the source can block more traffic than intended. An extended ACL can make a more specific decision early and stop unwanted traffic before it crosses the network.

4. Numbered ACLs, named ACLs, remarks, and how to edit them without breaking anything

For CCNA, you’ve really got to know the numbered ACL ranges: standard ACLs use 1 to 99 and 1300 to 1999, while extended ACLs use 100 to 199 and 2000 to 2699. Named ACLs can be either standard or extended, and in real networks I usually prefer them because they’re a lot easier to read and maintain.

access-list 10 permit 192.168.10.0 0.0.0.255

ip access-list extended BRANCH_WEB
10 remark Permit branch web access
20 permit tcp 192.168.10.0 0.0.0.255 10.10.20.0 0.0.0.255 eq 443

Sequence numbers are great for maintenance, but they are not exclusive to named ACLs on modern IOS/IOS XE. Many platforms allow sequence-based editing for numbered ACLs too when you enter ACL configuration mode or resequence the list.

Useful maintenance actions:

ip access-list extended BRANCH_WEB
15 permit udp 192.168.10.0 0.0.0.255 any eq 53
no 15

ip access-list resequence BRANCH_WEB 10 10

In production, use remarks, leave spacing between sequence numbers, and verify before applying changes. An ACL edit can immediately affect traffic.

5. Wildcard Masks Made Practical

Wildcard masks tell the ACL which bits have to match exactly and which bits it can ignore. A 0 bit means “must match.” A 1 bit means “ignore.” That is why wildcard logic feels backward compared to subnet masks.

Common conversions:

Honestly, the quickest way I’ve found is just to subtract each subnet-mask octet from 255. For a single host, use host or wildcard 0.0.0.0. For any address, use any, which is equivalent to 0.0.0.0 255.255.255.255.

One mistake I see all the time is people typing a subnet mask when the ACL is actually expecting a wildcard mask:

access-list 10 permit 192.168.10.0 255.255.255.0

That’s not the wildcard you want for a /24 network, not even close. IOS might still accept the line, but it’ll match a very different set of addresses than you intended. So the problem isn’t just syntax — it’s the meaning of the line.

For CCNA, most of the examples use the usual inverse-subnet wildcard patterns, but wildcard masks aren’t limited to just those. Cisco ACLs can technically use noncontiguous wildcards too, although the exam usually sticks to the simpler subnet-style patterns.

6. Building Extended ACLs and Port Operators

Extended ACL syntax is a little broader than one neat little formula. With TCP and UDP, you can match source and destination addresses, and if you need to, you can also match source and destination ports. For ICMP, you’re not dealing with ports at all — you match ICMP message types instead.

Generalized forms:

access-list <num> permit|deny tcp|udp <src host|any|addr wc> [src-operator ports] <dst host|any|addr wc> [dst-operator ports]

access-list <num> permit|deny icmp <src> <dst> [echo|echo-reply|unreachable]

Port operators you should know: eq, neq, lt, gt, and range. In client-to-server filtering, you usually match the destination service port, not the client source port.

Examples:

access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 10.10.20.10 eq 80

access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 10.10.20.10 eq 443

access-list 110 permit udp 192.168.10.0 0.0.0.255 any eq 53

access-list 110 permit tcp 192.168.10.0 0.0.0.255 any eq 53

access-list 110 deny tcp any any eq 23 log

access-list 110 permit icmp any any echo

That DNS pair matters. UDP/53 is the common exam answer for client queries, but DNS can also use TCP/53. If a question says “DNS” generically, read the scenario carefully.

FTP is a good reminder that ACLs are stateless and some protocols are awkward. FTP control uses TCP/21. Active FTP data involves TCP/20 in one direction, while passive FTP uses high ephemeral ports. So a simple range 20 21 is not a full “FTP policy.”

You may also see the classic established keyword for TCP return traffic in older ACL discussions. It matches TCP packets with the ACK or RST bits set, so it can help approximate return traffic, but it’s still not stateful inspection.

7. Applying ACLs to Interfaces

An ACL doesn’t actually do anything until you apply it somewhere. Use ip access-group on routed interfaces, subinterfaces, or SVIs. A key operational rule: only one IPv4 ACL per interface, per direction, per protocol can be applied with ip access-group.

interface g0/0
ip access-group 110 in

interface vlan 30
ip access-group 10 out

Packet walk examples:

Inbound on source SVI: Host 192.168.10.50 in VLAN 10 sends HTTP to 10.10.20.10. That packet reaches the VLAN 10 SVI first, so an inbound ACL can stop it before the device even has a chance to make the routing decision.

Outbound on destination SVI: The same packet enters another interface, gets routed, and is checked only as it leaves the server VLAN SVI. That can be the right choice for a standard ACL near the destination.

Router-on-a-stick: If traffic from VLAN 10 enters subinterface G0/0.10, an inbound ACL there filters before routing to G0/0.30. The same ACL placed outbound on G0/0.30 changes where the decision happens.

8. Controlling Management Access with SSH and access-class

For VTY access, use access-class, not ip access-group. access-class controls which source addresses can open management sessions to the device. It does not enable SSH by itself.

Complete SSH setup example:

hostname R1
ip domain-name lab.local
username admin secret Cisco123!
crypto key generate rsa modulus 2048
ip ssh version 2

ip access-list standard MGMT_SSH
10 permit 192.168.50.0 0.0.0.255
20 deny any

line vty 0 4
login local
transport input ssh
access-class MGMT_SSH in

The explicit deny any is optional because of the implicit deny, but many engineers include it for readability and possible logging intent.

Better verification commands than platform-dependent line displays are:

show running-config | section line vty

show access-lists

show ssh

show users

9. Verification and troubleshooting

My ACL troubleshooting flow is pretty straightforward: confirm the intended path, check the ACE order, verify the wildcard and ports, confirm the interface and direction, then test it and look at the counters.

Useful commands:

show access-lists
show ip access-lists
show ip interface
show ip interface brief
show running-config | section access-list
show running-config interface g0/0

If NAT is involved, add:

show ip nat translations
show ip nat statistics

Hit counters are valuable, but test carefully. In labs, clear counters before testing so you know which traffic matched:

clear access-list counters

If counters stay at zero, think wrong interface, wrong direction, wrong wildcard, or traffic taking another path. If ping works but HTTP fails, check protocol and destination port. If transit traffic works but SSH to the router fails, check VTY configuration and source match. If NAT works but no security policy exists, remember a NAT ACL is not a filter.

Logging can help:

deny tcp any any eq 23 log

log generates syslog messages on matches. log-input can add ingress interface and source MAC details on some platforms. Both increase CPU and control-plane work, so use them deliberately.

Use debug ip packet very carefully, if at all, on production devices. It can be expensive and noisy.

10. NAT ACL vs Filtering ACL

This is a major CCNA trap. An ACL used by NAT is a classification ACL, not a forwarding filter.

Filtering ACL example:

ip access-list extended INTERNET_FILTER
10 deny tcp 192.168.10.0 0.0.0.255 any eq 23
20 permit ip 192.168.10.0 0.0.0.255 any

interface g0/0
ip access-group INTERNET_FILTER in

NAT ACL example:

access-list 1 deny 192.168.10.128 0.0.0.127
access-list 1 permit 192.168.10.0 0.0.0.127
ip nat inside source list 1 interface g0/1 overload

In the NAT example, the deny does not drop traffic. It simply excludes that subnet from translation. If the routing is in place and there isn’t a filtering ACL stopping it, that traffic can still be forwarded — it just won’t get translated by NAT. And yeah, that distinction matters a lot when you’re troubleshooting.

11. Security and Performance Considerations

Use least privilege. Avoid broad permit ip any any unless it is truly intentional. Put specific denies or permits before broader matches, because any broader matching ACE below or above can make later entries ineffective.

Document intent with remark. Consider explicit deny logging near the end when you need visibility. On busy platforms, keep logging selective. Order high-hit ACEs efficiently. On multilayer switches, ACLs may be handled in hardware, but that doesn’t mean the box can’t run into resource limits.

A practical edge-style example is anti-spoofing, which is a common sanity check at the network edge:

ip access-list extended EDGE_IN
10 deny ip 10.0.0.0 0.255.255.255 any log
20 deny ip 172.16.0.0 0.15.255.255 any log
30 deny ip 192.168.0.0 0.0.255.255 any log
40 permit ip any any

That is not a full Internet edge design, but it shows the idea: deny impossible or private source addresses where they should never appear.

12. Compact Labs and Exam Traps

Lab 1: Application filtering.

ip access-list extended BRANCH_TO_SERVERS
10 remark Permit web
20 permit tcp 192.168.10.0 0.0.0.255 10.10.20.0 0.0.0.255 eq 80
30 permit tcp 192.168.10.0 0.0.0.255 10.10.20.0 0.0.0.255 eq 443
40 permit udp 192.168.10.0 0.0.0.255 any eq 53
50 deny tcp 192.168.10.0 0.0.0.255 any eq 23 log
60 permit ip any any

interface g0/0
ip access-group BRANCH_TO_SERVERS in

Try HTTP, HTTPS, DNS, and Telnet as your test traffic. Then check hit counts.

Lab 2: Secure SSH management.

Configure SSH prerequisites, apply access-class MGMT_SSH in under VTY, test from an allowed admin subnet and a denied subnet, then verify with show ssh and show access-lists.

A few exam traps are worth memorizing:

• Implicit deny at the end
• Wildcard mask is not a subnet mask
• Destination port usually matters for client-to-server filtering
• ip access-group is for interfaces; access-class is for VTY lines
• NAT ACLs match translation candidates; they do not filter by themselves
• Standard near destination, extended near source is a guideline, not an absolute rule
• Check the actual path before assuming return traffic is blocked

13. Summary and CCNA Readiness Checklist

IPv4 ACLs are all about packet reasoning: top-down processing, first-match wins, implicit deny, correct wildcard, correct interface, correct direction. Standard ACLs match source only. Extended ACLs add destination, protocol, and ports. Named ACLs improve readability, and sequence-based editing improves maintainability.

CCNA checklist:

• Explain inbound vs outbound ACL processing order
• Choose standard vs extended ACL correctly
• Convert prefix lengths to wildcard masks
• Use host, any, and address/wildcard pairs correctly
• Match destination service ports for common client/server traffic
• Know eq, neq, lt, gt, and range
• Apply ACLs to routed interfaces, subinterfaces, or SVIs with the correct direction. ports, SVIs, or subinterfaces, and make sure the direction is right
• Protect VTY access with access-class and SSH prerequisites
• Be able to tell filtering ACLs apart from NAT ACLs
• Verify with show commands and hit counters
• Troubleshoot order, wildcard, direction, port side, reverse path, and NAT confusion

If you can read an ACL, trace the packet, and predict the result without guessing, you are in good shape for both the CCNA exam and real operations work.