Courseiva
ACLCCNA 200-301

ACL with Wrong Wildcard Mask Blocking Unintended Hosts

Presenting Symptom

Hosts in the 192.168.1.0/24 subnet are unable to reach the server at 10.0.0.10, while hosts in other subnets can reach it.

Network Context

A small branch office with a Cisco 4321 router running IOS XE 16.9. The router connects two VLANs: VLAN 10 (192.168.1.0/24) and VLAN 20 (192.168.2.0/24) to a WAN link (10.0.0.0/30) leading to a server at 10.0.0.10. An extended ACL is applied inbound on the WAN interface to permit traffic from VLAN 10 to the server, but the wildcard mask is misconfigured.

Diagnostic Steps

1

Check the ACL configuration

show access-list 100
Extended IP access list 100
    10 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10
    20 deny ip any any

The ACL appears correct at first glance. Note the wildcard mask 0.0.0.255 for 192.168.1.0/24, which is standard. However, if the wildcard mask is wrong, it might not match the intended hosts.

2

Verify which interface the ACL is applied to and direction

show running-config interface gigabitethernet 0/0/0
interface GigabitEthernet0/0/0
 ip address 10.0.0.1 255.255.255.252
 ip access-group 100 in

The ACL is applied inbound on the WAN interface. This means traffic from the LAN to the server is filtered as it enters the WAN interface. Confirm the direction is correct.

3

Test connectivity from a host in VLAN 10 to the server and capture ACL hits

ping 10.0.0.10 source 192.168.1.100 repeat 1 show access-list 100
Extended IP access list 100
    10 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10 (0 matches)
    20 deny ip any any (1 match)

The permit line has 0 matches, but the deny line has 1 match. This indicates the traffic is being denied. The ACL is not matching the permit entry, likely due to a wildcard mask issue.

4

Examine the wildcard mask more closely

show access-list 100 | include permit
10 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10

The wildcard mask 0.0.0.255 matches all hosts in 192.168.1.0/24. But if the actual source IP is 192.168.1.100, it should match. However, if the network statement was misconfigured, e.g., using 192.168.1.0 0.0.0.0, it would only match host 192.168.1.0. Check the actual mask in the running config.

5

Check the running config for the ACL entry

show running-config | section access-list 100
access-list 100 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10
access-list 100 deny ip any any

The wildcard mask appears correct. But if the problem persists, the issue might be that the ACL is applied outbound instead of inbound, or the source network is actually different. However, the scenario states wrong wildcard mask. Perhaps the mask is 0.0.0.0, which would only match 192.168.1.0 exactly. Let's simulate that.

6

Simulate the misconfiguration: change the ACL to use wrong wildcard mask

configure terminal ip access-list extended 100 no 10 permit ip 192.168.1.0 0.0.0.0 host 10.0.0.10 end show access-list 100
Extended IP access list 100
    10 permit ip 192.168.1.0 0.0.0.0 host 10.0.0.10
    20 deny ip any any

Now the wildcard mask 0.0.0.0 matches only the host 192.168.1.0, not the entire subnet. Traffic from 192.168.1.100 will not match and will be denied. This is the root cause.

Root Cause

The ACL entry uses a wildcard mask of 0.0.0.0 instead of 0.0.0.255, causing it to match only the network address 192.168.1.0 rather than all hosts in the 192.168.1.0/24 subnet. As a result, traffic from actual hosts (e.g., 192.168.1.100) is denied by the implicit deny any.

Resolution

Correct the wildcard mask on the ACL entry: configure terminal ip access-list extended 100 no 10 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10 end This changes the wildcard mask from 0.0.0.0 to 0.0.0.255, matching all hosts in the 192.168.1.0/24 subnet.

Verification

Test connectivity from a host in VLAN 10: ping 10.0.0.10 source 192.168.1.100 repeat 1 Expected output: !!!!! (success) Check ACL hits: show access-list 100 Expected output: Extended IP access list 100 10 permit ip 192.168.1.0 0.0.0.255 host 10.0.0.10 (1 match) 20 deny ip any any (0 matches) The permit line now shows matches, and the deny line has no matches.

Prevention

1. Always double-check wildcard masks when configuring ACLs; remember that 0.0.0.0 matches a single host, while 0.0.0.255 matches a /24 subnet. 2. Use named ACLs with clear descriptions to reduce misconfiguration. 3. Test ACLs with a ping from a representative host and verify matches using 'show access-list' before deploying.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario tests understanding of ACL wildcard masks and their impact on traffic filtering. Questions may present a troubleshooting scenario where a host cannot reach a server, and the candidate must identify the misconfigured wildcard mask. The exam expects candidates to know that a wildcard mask of 0.0.0.0 matches a single IP address, while 0.0.0.255 matches all hosts in a /24 network.

Exam Tips

1.

Remember that wildcard masks are inverse of subnet masks: 0.0.0.255 corresponds to /24, 0.0.0.0 is a host mask.

2.

When troubleshooting ACLs, always check the number of matches on each line using 'show access-list' to see if traffic is hitting the intended permit or deny.

3.

Be careful with the order of ACL entries; the first match is applied. In this scenario, the permit line must come before the deny any.

Commands Used in This Scenario

ping [ip]

The ping command sends ICMP echo requests to a destination IP address to test network connectivity and measure round-trip time.

show running-config

Displays the current active configuration in DRAM, showing all non-default settings.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions