ACL Wildcard Tester

Understanding ACL Wildcard Masks

Access Control Lists (ACLs) are one of the most fundamental tools in Cisco IOS networking. They let you permit or deny traffic based on source IP, destination IP, protocol, and port numbers. The key to writing effective ACLs is understanding the wildcard mask — a 32-bit value that tells the router which bits of an IP address must match and which bits it can ignore.

How Wildcard Masks Work

A wildcard mask operates on a simple per-bit rule:

• Bit = 0 (must match): The corresponding bit in the test IP address must equal the corresponding bit in the network address.
• Bit = 1 (don't care): The corresponding bit in the test IP address can be anything — it is ignored during matching.

This is the direct inverse of a subnet mask. In a subnet mask, a 1 bit means "this bit belongs to the network portion." In a wildcard mask, a 1 bit means "ignore this bit." The mathematical relationship is:

Wildcard mask = 255.255.255.255 − subnet mask

Example:
  Subnet mask  = 255.255.255.0
  Wildcard     =   0.  0.  0.255

The host and any Keywords

Cisco IOS provides two shorthand keywords to avoid typing common wildcard patterns:

• host 10.0.0.1 is equivalent to 10.0.0.1 0.0.0.0. A wildcard of all zeros means every bit must match — so only the single host 10.0.0.1 matches.
• any is equivalent to 0.0.0.0 255.255.255.255. A wildcard of all ones means no bits need to match — every possible IP address is permitted.

Common ACL Wildcard Patterns

The even/odd host patterns demonstrate an important property of wildcard masks: they do not have to be contiguous. A traditional subnet mask is always a series of consecutive 1-bits followed by 0-bits, but a wildcard mask can have 1s and 0s in any combination. This lets you match specific subsets of addresses — such as every even-numbered host in a subnet — that a simple CIDR notation cannot express.

Standard vs. Extended ACLs

Cisco IOS has two main ACL types, and where you place them matters:

• Standard ACLs (numbered 1–99, 1300–1999): Match on source IP address only. Because they only look at source IP, they should be placed as close to the destination as possible to avoid inadvertently blocking traffic to other destinations.
• Extended ACLs (numbered 100–199, 2000–2699): Match on source IP, destination IP, protocol (TCP/UDP/ICMP/etc.), and port numbers. Much more granular. Place them close to the source so unwanted traffic is dropped early.

Named ACLs (introduced in IOS 11.2) use the same logic but replace numbers with descriptive names, making large configurations easier to manage.

IOS ACL Syntax Examples

! Standard ACL — permit the 192.168.1.0/24 subnet
access-list 10 permit 192.168.1.0 0.0.0.255

! Standard ACL — deny single host
access-list 10 deny host 172.16.5.10

! Extended ACL — permit HTTP from any source to 10.0.0.0/8
access-list 100 permit tcp any 10.0.0.0 0.255.255.255 eq 80

! Extended ACL — deny Telnet from 192.168.0.0/16 to any
access-list 100 deny tcp 192.168.0.0 0.0.255.255 any eq 23

! Named extended ACL
ip access-list extended BLOCK_TELNET
 deny tcp 192.168.0.0 0.0.255.255 any eq 23
 permit ip any any

Every ACL has an implicit deny any at the end. If no rule matches, the traffic is dropped. Always end standard and extended ACLs with an explicit permit ip any any if you want to allow all other traffic through.

Worked Examples with Binary Breakdown

Example 1 — Permit the 10.10.0.0/16 subnet

Suppose you want to permit all hosts in the 10.10.0.0/16 range. The /16 subnet mask is 255.255.0.0, so the wildcard is 0.0.255.255.

Network:  00001010.00001010.00000000.00000000  (10.10.0.0)
Wildcard: 00000000.00000000.11111111.11111111  (0.0.255.255)

Test IP:  00001010.00001010.00010101.01100100  (10.10.21.100)
Bits 0–15 must match → 00001010.00001010 ✓  → MATCH

Example 2 — Permit only even-numbered hosts in 172.16.4.0/24

To match only even host addresses (last bit = 0), use network 172.16.4.0 with wildcard 0.0.0.254 (binary: 11111110). The last bit is forced to 0.

Network:  10101100.00010000.00000100.00000000  (172.16.4.0)
Wildcard: 00000000.00000000.00000000.11111110  (0.0.0.254)

Test IP:  10101100.00010000.00000100.00000110  (172.16.4.6)  → MATCH (even)
Test IP:  10101100.00010000.00000100.00000111  (172.16.4.7)  → NO MATCH (odd)

Example 3 — Deny management traffic from RFC 1918 ranges

You can stack multiple ACE (Access Control Entries) in one ACL to cover several networks. For example, blocking SSH from all private address space:

ip access-list extended BLOCK_SSH_RFC1918
 deny tcp 10.0.0.0 0.255.255.255 any eq 22
 deny tcp 172.16.0.0 0.15.255.255 any eq 22
 deny tcp 192.168.0.0 0.0.255.255 any eq 22
 permit ip any any

Frequently Asked Questions

Q: Is a wildcard mask the same as an inverse mask?

Yes — the terms are interchangeable. Some vendors and textbooks call it an inverse mask or a reverse mask because every bit is the complement of the corresponding subnet mask bit.

Q: Can a wildcard mask be non-contiguous?

Yes, and this is one of the key differences from subnet masks. A subnet mask must always be contiguous (all 1s followed by all 0s). A wildcard mask has no such restriction — you can use 0.0.0.254 (binary: 11111110 in the last octet) to match only even hosts, for example.

Q: What happens if no ACL rule matches?

Cisco IOS appends an invisible deny ip any any to every ACL. If a packet does not match any permit or deny statement, it is silently dropped. This catches many engineers off-guard — always verify there is a terminal permit ip any any when you intend to allow unmatched traffic.

Q: How does this differ from firewall rules?

Traditional Cisco ACLs are stateless — each packet is evaluated independently. A stateful firewall tracks TCP/UDP session state and automatically permits return traffic. ACLs require you to either apply them in both directions or use the established keyword to allow return TCP traffic.

Q: Where should I apply a standard ACL vs. an extended ACL?

The conventional wisdom is: place standard ACLs close to the destination (they only see source IP, so placing them near the source might block traffic meant for other destinations). Place extended ACLs close to the source so you drop unwanted packets before they consume bandwidth on your network.

Related Calculators

• Wildcard Mask Calculator — Convert a subnet mask or CIDR prefix to a wildcard mask
• Subnet Calculator — Calculate network address, broadcast, and host range from CIDR
• OSPF Cost Calculator — Compute OSPF interface costs from bandwidth

Disclaimer: This tool is provided for educational and planning purposes only. Always verify ACL configurations in a test environment before deploying to production networks. Incorrect ACL entries can cause traffic outages or security vulnerabilities.