ACL Configuration Lab: Standard vs Extended

Access Control Lists are one of the trickiest CCNA topics — not because the syntax is complex, but because small mistakes in wildcard masks or placement can silently break things.

This lab walks through both standard and extended ACLs with real configurations, verification steps, and the common mistakes that trip students up.

To generate this lab instantly:

Build an ACL lab with 2 routers, 2 switches, and 4 PCs.
R1 connects to SW1 (VLAN 10 - Sales, VLAN 20 - Engineering).
R2 connects to SW2 (VLAN 30 - Servers).
OSPF between R1 and R2. I want to practice standard and extended ACLs.

Standard vs Extended: When to Use Each

Before configuring anything, understand the difference:

Standard ACLs (1-99, 1300-1999):

• Filter based on source IP only
• Place as close to the destination as possible
• Simple but limited

Extended ACLs (100-199, 2000-2699):

• Filter based on source IP, destination IP, protocol, and port
• Place as close to the source as possible
• More precise control

The placement rule matters. A standard ACL placed at the source would block traffic to all destinations, not just the one you intended.

Lab Topology

• R1 (10.0.0.1/30) — connects to R2 and SW1
• R2 (10.0.0.2/30) — connects to R1 and SW2
• SW1 — VLAN 10 (192.168.10.0/24 - Sales) and VLAN 20 (192.168.20.0/24 - Engineering)
• SW2 — VLAN 30 (192.168.30.0/24 - Servers)
• OSPF area 0 between R1 and R2

Exercise 1: Standard ACL — Block a Subnet

Goal: Prevent the Sales VLAN (192.168.10.0/24) from reaching the Server VLAN (192.168.30.0/24).

Since standard ACLs filter on source IP only, place it on R2 close to the destination:

R2(config)# access-list 10 deny 192.168.10.0 0.0.0.255
R2(config)# access-list 10 permit any
!
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip access-group 10 out

Breaking it down:

• access-list 10 — standard ACL number 10
• deny 192.168.10.0 0.0.0.255 — block anything from 192.168.10.x
• permit any — allow everything else (without this, the implicit deny blocks all traffic)
• ip access-group 10 out — apply to traffic leaving R2 toward the servers

Verify it works:

! From a Sales PC (192.168.10.10) — should fail
PC1> ping 192.168.30.10
Request timed out.
 
! From an Engineering PC (192.168.20.10) — should succeed
PC3> ping 192.168.30.10
Reply from 192.168.30.10: bytes=32 time=2ms TTL=126

Check the ACL hit counters:

R2# show access-lists
Standard IP access list 10
    10 deny   192.168.10.0, wildcard bits 0.0.0.255 (4 matches)
    20 permit any (8 matches)

The match count confirms the ACL is working. The 4 matches are the denied pings from Sales.

Exercise 2: Extended ACL — Block Specific Traffic

Goal: Allow Engineering (192.168.20.0/24) to ping servers but block SSH (port 22) access to them.

Extended ACLs go close to the source, so configure on R1:

R1(config)# ip access-list extended ENG-TO-SERVERS
R1(config-ext-nacl)# deny tcp 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 eq 22
R1(config-ext-nacl)# permit ip 192.168.20.0 0.0.0.255 any
R1(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 any
!
R1(config)# interface GigabitEthernet0/0.20
R1(config-if)# ip access-group ENG-TO-SERVERS in

Breaking it down:

• deny tcp ... eq 22 — block TCP port 22 (SSH) from Engineering to Servers
• permit ip ... any — allow all other traffic from Engineering
• The second permit ensures Sales traffic isn't accidentally blocked by the implicit deny
• Applied in on the Engineering subinterface — catches traffic as it enters R1

Verify:

! Ping from Engineering to Server — should work
PC3> ping 192.168.30.10
Reply from 192.168.30.10: bytes=32 time=2ms TTL=126
 
! SSH from Engineering to Server — should fail
PC3> ssh -l admin 192.168.30.10
Connection timed out

Exercise 3: Named ACL with Logging

Named ACLs are easier to read and modify than numbered ones. Add logging to see what's being blocked in real time:

R2(config)# ip access-list extended PROTECT-SERVERS
R2(config-ext-nacl)# permit tcp any 192.168.30.0 0.0.0.255 eq 80
R2(config-ext-nacl)# permit tcp any 192.168.30.0 0.0.0.255 eq 443
R2(config-ext-nacl)# permit icmp any 192.168.30.0 0.0.0.255
R2(config-ext-nacl)# deny ip any 192.168.30.0 0.0.0.255 log
R2(config-ext-nacl)# permit ip any any
!
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip access-group PROTECT-SERVERS out

This ACL:

• Allows HTTP (80) and HTTPS (443) to servers
• Allows ping to servers
• Denies and logs everything else to servers
• Permits all non-server traffic

The log keyword on the deny line generates syslog messages whenever traffic is blocked — useful for troubleshooting.

Wildcard Mask Cheat Sheet

Wildcard masks are the inverse of subnet masks. Here are the most common ones:

The shortcut: subtract each octet of the subnet mask from 255.

• 255.255.255.0 → 255-255=0, 255-255=0, 255-255=0, 255-0=255 → 0.0.0.255
• 255.255.255.252 → 0.0.0.3

Use host 10.0.0.1 as a shortcut for 10.0.0.1 0.0.0.0 (single host match).

Common ACL Mistakes

1. Forgetting permit any at the end

Every ACL has an invisible deny any at the end. If you only write deny statements, everything gets blocked:

! This blocks ALL traffic, not just Sales
access-list 10 deny 192.168.10.0 0.0.0.255
! Missing: access-list 10 permit any

2. Wrong direction (in vs out)

• in — filters traffic entering the interface
• out — filters traffic leaving the interface

Think about it from the router's perspective. If traffic comes from a PC into the router on Gi0/0, that's in on Gi0/0.

3. Wrong interface

Applying an ACL on the wrong interface is a silent failure — no errors, just unexpected behavior. Draw the traffic flow on paper before applying.

4. ACL order matters

ACLs are processed top-to-bottom, first match wins. A permit any before a deny will never reach the deny:

! Wrong order — the permit matches first, deny never triggers
access-list 100 permit ip any any
access-list 100 deny tcp any any eq 22

What's Next

ACLs are foundational for network security. Once comfortable with standard and extended ACLs, explore:

• NAT/PAT — often configured alongside ACLs
• Zone-Based Firewalls — ACLs evolved for modern security
• Combining ACLs with VLANs — see the VLAN lab guide

For more CCNA hands-on practice, check out the OSPF lab guide or explore all CCNA labs.

Ready to practice? Get started with NetPilot — describe your ACL scenario and get a working lab in under 2 minutes.