Access-control matching
A platform may pair a base address with a wildcard mask to describe matching sources or destinations. Confirm the platform's syntax and whether it permits noncontiguous wildcards.
Wildcard Mask Calculator
A wildcard mask marks variable IPv4 bits with ones and fixed bits with zeros. Calculate the inverse mask, inspect the complete match range, and test one address before using it in an access-control expression.
Inputs stay in your browser. The calculator accepts only contiguous IPv4 network masks.
Network maskFixed bits
↕Wildcard maskVariable bits
Calculate and test the match
Provide an address with a prefix or a separate contiguous netmask. The optional test address shows whether its fixed bits equal the calculated network.
Wildcard bit 0 means compare. Wildcard bit 1 means ignore.
This result describes IPv4 matching only. It does not create, approve, or deploy an access-control rule.
Read wildcard masks from the fixed side first
The network mask identifies fixed prefix bits. The wildcard is its bitwise inverse, so it identifies which positions may vary. For a normal contiguous mask, the resulting match is the same address block represented by the CIDR prefix.
Routing protocol configuration
Some network interfaces use wildcard expressions in protocol configuration. The expression can select interfaces rather than advertise the literal network you expect, so current product documentation controls.
What this calculator deliberately rejects
A dotted value such as 0.0.5.255 can be a valid noncontiguous vendor wildcard, but it is not the inverse of a contiguous subnet mask. This calculator focuses on CIDR-equivalent masks because their range is predictable and reviewable. It rejects invalid or noncontiguous netmasks instead of silently guessing.
Read the result with one test address
Do not approve a match from the dotted values alone. Test one address that should match and another just outside the intended boundary. The fixed-bit comparison in the result explains the decision and catches common errors such as using a subnet mask where the product expects its inverse.
Check a boundary with concrete addresses
| Input | Calculated meaning | Review question |
|---|---|---|
| 192.168.20.37/24 | Base 192.168.20.0 with wildcard 0.0.0.255 | Should every address from 192.168.20.0 through 192.168.20.255 match? |
| 192.168.20.220 | Matches because the fixed first 24 bits are equal | Is this intended source owned by the expected network? |
| 192.168.21.1 | Does not match because a fixed bit differs | Does a separate rule allow the neighboring network? |
- Calculate the CIDR boundary independently with the subnet calculator.
- Test the first address, final address, one intended member, and one address immediately outside the block.
- Confirm whether the platform expects a netmask, wildcard mask, prefix, or address object.
- Preserve the tested values with the change record so another reviewer can repeat the check.
Verify the complete policy path
A correct wildcard does not prove that the rule is ordered correctly, applied in the expected direction, or limited to the intended service. Draft the complete decision with the firewall rule planner and inspect ordered policy with the firewall rule conflict checker.
The underlying prefix model follows RFC 4632. Vendor behavior can add syntax and matching rules that the mathematical result cannot validate.