CCNA 200-301: Basic IPv4 Access Control Lists Explained

1. Introduction: What IPv4 ACLs Are and Why They Matter

IPv4 ACLs are one of the most important CCNA skills because they force you to think like the router.

An Access Control List is really just an ordered set of permit and deny rules. Nothing fancy, just a list the router walks through one line at a time. Those individual entries are called ACEs, and each one is a rule the router checks one by one.

Cisco IOS goes through those ACEs from top to bottom, and the first match wins. That part is really important. If a packet matches an early rule, IOS stops right there and doesn’t keep looking.

If nothing matches, the packet hits the implicit deny at the end.

ACLs are used for basic packet filtering, segmentation, management-plane restriction, and simple policy enforcement.

In CCNA terms, they’re not stateful firewalls. That stateless-vs-stateful distinction matters a lot more than most people realize when they’re first learning this stuff.

A basic IOS ACL is stateless, so every packet gets judged all by itself. The router isn’t remembering some earlier conversation the way a stateful firewall would. It doesn’t remember previous traffic the way a stateful firewall does.

That is why packet flow, interface direction, and rule order matter so much.

For the exam and in real networks, the goal is not just to memorize syntax. The real skill is being able to answer: which ACE matches this packet, on which interface, in which direction, and why?

2. ACL Fundamentals and Packet-Processing Logic

Three rules drive almost everything:

• First match wins.
• Every ACL has an implicit deny.
• Direction and placement matter.

For IPv4 interface ACLs, one IPv4 ACL can be applied per interface, per direction.

So yes, you can absolutely have one inbound ACL and one outbound ACL on the same interface.

IPv6 ACLs are separate.

It also helps to know where ACLs fit in packet handling:

1. A packet arrives on an interface.
2. If an inbound ACL is applied there, IOS checks it before making the routing decision.
3. If permitted, the router performs the routing lookup and selects an exit interface.
4. If an outbound ACL is applied on that exit interface, IOS checks it before forwarding the packet out.
5. If permitted, the packet leaves the interface.

That model explains a lot of troubleshooting. If traffic is not matching the ACL you expect, the ACL may be on the wrong interface or in the wrong direction.

Two precision notes matter here.

First, IPv4 ACLs filter IP traffic, not ARP.

Second, traffic destined to the router itself and traffic merely passing through the router aren’t always handled the same way.

For example, access-class on VTY lines controls management access to the router, while ip access-group on an interface filters transit traffic on that interface.

3. Standard vs Extended ACLs

Standard ACLs match the source IPv4 address only. Extended ACLs can match source, destination, protocol, and Layer 4 details such as TCP or UDP ports.

The placement rule exists for a reason. A standard ACL is usually placed close to the destination because it only knows who the sender is.

If you put a standard ACL too close to the source, you can accidentally block that source from reaching a bunch of destinations, not just the one you were trying to protect. That’s a classic gotcha.

An extended ACL is usually placed close to the source because it can be much more specific and stop unwanted traffic before it burns bandwidth crossing the network.

4. Numbered vs Named ACLs

Numbered ACLs use numeric identifiers. Named ACLs use descriptive names and are usually easier to maintain.

• Standard numbered ACLs: 1-99 and 1300-1999
• Extended numbered ACLs: 100-199 and 2000-2699

Named ACLs are operationally better in many cases because modern IOS supports sequence numbers, remarks, and easier editing.

ip access-list extended WEB-ONLY 10 remark Permit web traffic to the public server 20    permit tcp 192.168.10.0 0.0.0.255 host 10.10.10.10 eq 80 30    permit tcp 192.168.10.0 0.0.0.255 host 10.10.10.10 eq 443 40    deny ip 192.168.10.0 0.0.0.255 host 10.10.10.10 50 permit ip any any

If you need to remove one ACE from a named ACL, you can do it directly:

ip access-list extended WEB-ONLY no 40

And on platforms that support it, you can resequence:

ip access-list resequence WEB-ONLY 10 10

That is much safer than deleting and rebuilding a whole numbered ACL during a change window.

5. Wildcard Mask Fundamentals

Wildcard masks are inverse masks.

A 0 means that bit has to match exactly.

A 1 means ignore that bit.

The quick method is to subtract each subnet mask octet from 255.

• host 192.168.10.10 = exact host = 192.168.10.10 0.0.0.0
• 192.168.10.0 0.0.0.255 = /24
• any = any IPv4 address = wildcard 255.255.255.255

Common conversions:

One subtle point: the address must align with the wildcarded block. For example, 192.168.10.32 0.0.0.31 correctly matches a /27 block from .32 to .63. But 192.168.10.20 0.0.0.31 is not describing a clean /27 network boundary and often causes confusion.

Standard ACLs can use host and any too, not just wildcard notation.

6. Configuring a Standard ACL Correctly

Use a standard ACL when only the source matters.

Host A 192.168.10.25 --- g0/0 [R1] g0/1 --- Server Net 192.168.30.0/24
Host B 192.168.20.25 ---/

Requirement: permit 192.168.10.0/24 to reach the server network and deny 192.168.20.0/24.

Because this is a standard ACL, putting it close to the destination is the better choice. You don’t want to block that source from every other path unless that’s really what you mean to do.

In this topology, the destination-facing interface is g0/1, so applying the ACL outbound on g0/1 is consistent with that rule.

interface g0/0   ip address 192.168.1.1 255.255.255.0 no shutdown
!
interface g0/1   ip address 192.168.30.1 255.255.255.0 no shutdown
!
access-list 10  permit 192.168.10.0 0.0.0.255
access-list 10  deny 192.168.20.0 0.0.0.255
!
interface g0/1 ip access-group 10 out

Packet logic:

• Source 192.168.10.25 to 192.168.30.10 matches ACE 1 and is permitted.
• Source 192.168.20.25 to 192.168.30.10 matches ACE 2 and is denied.
• Source 192.168.40.25 to 192.168.30.10 matches nothing and is denied by the implicit deny.

Could you filter the same traffic inbound on g0/0?

Sure, but then you’d be filtering closer to the source instead of closer to the destination.

For a standard ACL, that can overblock other destinations reached by the same source subnet.

A named version is clearer:

ip access-list standard SERVER-FILTER 10  permit 192.168.10.0 0.0.0.255 20  deny 192.168.20.0 0.0.0.255 30 remark Implicit deny covers everything else

Note that an explicit deny any in a standard ACL is functionally redundant unless you want readability or optional logging.

7. Configuring an Extended ACL Correctly

Use an extended ACL when you care about destination, protocol, or ports.

Client LAN 192.168.10.0/24 --- g0/0 [R1] g0/1 --- Server/DMZ | +--- Web Server 10.10.10.10

Requirement: allow HTTP and HTTPS from 192.168.10.0/24 to 10.10.10.10, deny other traffic from that subnet to that server, but permit other destinations normally.

Because this is an extended ACL, place it close to the source. If clients are behind g0/0, inbound on g0/0 is a good choice.

ip access-list extended WEB-ONLY 10    permit tcp 192.168.10.0 0.0.0.255 host 10.10.10.10 eq 80 20    permit tcp 192.168.10.0 0.0.0.255 host 10.10.10.10 eq 443 30    deny ip 192.168.10.0 0.0.0.255 host 10.10.10.10 40 permit ip any any
!
interface g0/0 ip access-group WEB-ONLY in

This is safer than ending with deny ip any any on the client-facing interface, because that would block all unmatched IP traffic from that interface, not just traffic to the server.

Outcomes:

• TCP from 192.168.10.25 to 10.10.10.10 port 80 matches ACE 10 and is permitted.
• TCP from 192.168.10.25 to 10.10.10.10 port 443 matches ACE 20 and is permitted.
• TCP from 192.168.10.25 to 10.10.10.10 port 22 matches ACE 30 and is explicitly denied.
• Traffic from 192.168.10.25 to 8.8.8.8 matches ACE 40 and is permitted.

That third case fixes a common mistake in ACL explanations: if you configured an explicit deny ACE, the packet is denied by that ACE, not by the implicit deny.

Also remember that client-to-server filtering usually matches the destination port.

For example, web clients connect to the server’s destination port 80 or 443.

Source ports are usually ephemeral and are not what you match for normal service filtering.

8. Common Extended ACL Match Types

HTTP and HTTPS are only part of the story. You should also recognize UDP and ICMP examples.

ip access-list extended SERVICES 10  permit udp 192.168.10.0 0.0.0.255 host 10.10.20.53 eq 53 20  permit icmp 192.168.50.0 0.0.0.255 host 10.10.10.10 echo10.10 echo 30  deny icmp 192.168.60.0 0.0.0.255 host 10.10.10.10 echo 40 permit ip any any

Key points:

• DNS commonly uses UDP destination port 53.
• ICMP does not use TCP or UDP ports. You match the ICMP protocol, and optionally types such as echo or echo-reply.
• Blocking ICMP can break troubleshooting. If you deny ping, you may also hide path or reachability problems from yourself.

Because ACLs are stateless, permitting a client packet in one direction does not automatically guarantee the reverse direction is allowed if another ACL exists on the return path. At CCNA level, know the concept. You may also see the TCP established keyword in some IOS examples, but that is a limited TCP-specific mechanism, not full stateful inspection.

9. Restricting VTY Access with an ACL

Restricting management access is one of the best real uses of ACLs. This is management-plane filtering, not transit filtering.

hostname R1
ip domain-name lab.local
username admin secret C1sc0!
crypto key generate rsa modulus 2048
ip ssh version 2
!
ip access-list standard MGMT-FILTER 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-FILTER in

This does not just restrict source IPs. It also completes the minimum SSH setup: hostname, domain name, local user, RSA keys, SSH version, and login local.

Verification idea:

• From 192.168.50.25, SSH should succeed.
• From 192.168.60.25, SSH should fail because the VTY ACL denies the source.

Be careful with remote changes.

If you’re connected over SSH and you apply an ACL that doesn’t permit your own source address, you can lock yourself out. I’ve seen that happen, and it’s not a fun five minutes.

In production, verify your source IP first, add your permit ACE before applying the ACL, and use a rollback plan when possible.

10. ACL Logging, Verification, and Safe Troubleshooting

Core verification commands:

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

Use them in a workflow:

1. Generate test traffic that should match a specific ACE.
2. Check hit counters with show access-lists.
3. Confirm the ACL is attached to the correct interface and direction with show ip interface.
4. Compare expected behavior to actual matches.
5. Fix order, wildcard, interface, or direction issues.

Sample output may show service names such as www instead of port 80. IOS can display either style.

You can also add log to an ACE for visibility:

access-list 10  deny 192.168.20.0 0.0.0.255 log

That can help during troubleshooting, but use it carefully. Logging every denied packet can increase CPU and syslog volume.

Common mistakes:

• Wrong interface
• Wrong direction
• Wrong wildcard mask
• Broad permit above specific deny
• deny ip any any applied too early or too broadly
• Accidental VTY lockout

If you need to remove or replace an ACL, detach it first when appropriate to avoid unintended impact:

interface g0/0  no ip access-group WEB-ONLY in
!
no access-list 10

11. Safer ACL Design Patterns and Integration Scenarios

A few CCNA-level design patterns show up often:

• Server protection: permit only required services to a server, deny the rest to that host, then permit other traffic.
• Branch edge filtering: place extended ACLs near user subnets to stop unwanted traffic early and reduce unnecessary WAN use.
• Inter-VLAN filtering: apply ACLs on routed interfaces or SVIs to limit which VLANs can reach specific resources.
• Management-plane restriction: use access-class on VTY lines, not just interface ACLs.

At the edge, ACLs may also interact with NAT. For CCNA, the main takeaway is that feature order can vary by platform and design, so always verify behavior with show commands and testing instead of assuming.

ACLs are useful, but they are not a replacement for stateful firewalls, IDS/IPS, or broader management-plane hardening.

12. CCNA Exam Drill: Predict the Packet Outcome

Use this method on every ACL question:

1. Identify the source.
2. Identify the destination.
3. Identify the ingress interface.
4. Determine whether the ACL is inbound or outbound.
5. Test ACEs from top to bottom.
6. Account for the implicit deny.

Quick drills:

1. ACL:

 permit 192.168.10.0 0.0.0.255

.

Packet source 192.168.10.25. Result: permitted.

25. Result: permitted.

2. Same ACL.

2. Same ACL. Packet source 192.168.20.25. Result: denied by the implicit deny.

Result: denied by implicit deny.

3. Extended ACE: permit tcp any host 10.10.10.10 eq 22.

4. Packet enters g0/0 and exits g0/1. Result: outbound ACL on g0/1 is checked before forwarding out.

Result: denied unless another ACE permits it.

4. ACL applied outbound on g0/1. Packet enters g0/0 and exits g0/1. Result: outbound ACL on g0/1 is checked before forwarding out.

5. VTY lines use access-class MGMT-FILTER in. Unauthorized host tries SSH. Result: management access denied even if transit interface ACLs would otherwise allow IP reachability.

13. Final Review and Key Takeaways

Know these cold for CCNA:

• Standard ACL = source only.
• Extended ACL = source, destination, protocol, and ports.
• First match wins.
• Implicit deny always exists.
• Standard ACLs usually go near the destination.
• Extended ACLs usually go near the source.
• Inbound ACLs are checked before routing; outbound ACLs are checked after routing, before exit.
• ip access-group filters interface traffic; access-class filters VTY access.
• Wildcard masks are inverse masks.
• ACLs are stateless.

If you can read an ACL like a packet trace and explain exactly why a packet is permitted or denied, you are where you need to be for Basic IPv4 ACLs on CCNA 200-301.