Convert Between CIDR and IP Ranges for Firewall Rules

Firewalls are the front line of network security, and nearly every firewall rule depends on accurately specifying which IP addresses to allow or block. CIDR (Classless Inter-Domain Routing) notation is the standard way to express IP address ranges in a compact format, but a single miscalculation can leave your network exposed or accidentally block legitimate traffic. Whether you are configuring iptables on a Linux server, setting up AWS Security Groups, or managing a corporate firewall appliance, understanding CIDR is essential. This guide walks through CIDR notation, how to convert between CIDR blocks and IP ranges, and how to build reliable firewall rules using free tools.

Why CIDR Notation Matters for Firewall Rules

Before CIDR was introduced in RFC 4632, IP addresses were divided into rigid Class A, B, and C blocks. This wasted enormous amounts of address space. CIDR replaced that system with variable-length subnet masking, letting network administrators define blocks of any size using a prefix length. Today, every major firewall platform — from Linux iptables to AWS Security Groups to Cloudflare’s WAF — uses CIDR notation to define rules.

Getting CIDR right matters because firewall rules are evaluated in order. An overly broad block like /8 when you meant /24 could deny access to 16 million addresses instead of 256. Conversely, a block that is too narrow leaves gaps that attackers can exploit. Understanding exactly how many addresses a prefix covers and which specific IPs fall inside that range is essential for writing rules that work correctly.

Understanding CIDR Notation

A CIDR block consists of an IP address followed by a forward slash and a prefix length. The prefix length indicates how many bits of the address identify the network. The remaining bits identify individual hosts within that network. For example, 192.168.1.0/24 means the first 24 bits define the network and the last 8 bits are available for hosts, giving 256 total addresses (254 usable, since the first is the network address and the last is the broadcast address).

Here is a quick reference for the most common IPv4 prefix lengths:

The key relationship to remember: every time the prefix length decreases by one, the number of addresses doubles. A /23 has 512 addresses, a /22 has 1,024, and so on. Use the Subnet Calculator to verify any CIDR block instantly.

Converting CIDR Blocks to IP Ranges

To convert a CIDR block to its full IP range, you need two pieces of information: the network address (the first IP in the range) and the broadcast address (the last IP). Here is how to calculate them manually:

1. Convert the IP to binary — write out all 32 bits. For 10.0.5.0, that is 00001010.00000000.00000101.00000000.
2. Apply the prefix length — a /22 means the first 22 bits are fixed (the network portion). The remaining 10 bits can vary.
3. Find the network address — set all host bits to 0. For 10.0.5.0/22, the network address is 10.0.4.0 (the third octet becomes 4 because bits 23-24 round down).
4. Find the broadcast address — set all host bits to 1. For 10.0.4.0/22, the broadcast address is 10.0.7.255.
5. The usable range is every IP between the network address and broadcast address: 10.0.4.1 through 10.0.7.254 (1,022 usable hosts).

For quick conversions without manual math, enter any CIDR block into the Subnet Calculator. It instantly shows the network address, broadcast address, full IP range, subnet mask, and host count.

Converting IP Ranges Back to CIDR

Sometimes you have a start and end IP and need to express it as one or more CIDR blocks. This is common when importing blocklists or translating between firewall platforms. If the range aligns on a power-of-two boundary, a single CIDR block is sufficient. For example, 10.0.0.0 through 10.0.3.255 maps cleanly to 10.0.0.0/22 because 1,024 addresses is exactly 2^10.

If the range does not align on a boundary, you may need multiple CIDR blocks to cover it exactly. The range 10.0.0.0 through 10.0.5.255 requires three blocks: 10.0.0.0/22, 10.0.4.0/23. The Subnet Calculator handles both directions automatically, so you never need to do this math by hand.

Building Firewall Rules with CIDR Blocks

Different firewall platforms use slightly different syntax, but they all accept CIDR notation. Here are examples for the most common environments:

Linux iptables

# Block an entire /24 subnet
iptables -A INPUT -s 203.0.113.0/24 -j DROP

# Allow a specific /32 (single IP)
iptables -A INPUT -s 198.51.100.42/32 -p tcp --dport 443 -j ACCEPT

# Block a large range
iptables -A INPUT -s 10.0.0.0/8 -j DROP

nftables (Modern Linux Replacement)

# Block a subnet in nftables
nft add rule inet filter input ip saddr 203.0.113.0/24 drop

# Allow a specific address
nft add rule inet filter input ip saddr 198.51.100.42 tcp dport 443 accept

AWS Security Groups

AWS Security Groups use CIDR blocks in their inbound and outbound rules. For example, allowing HTTPS from a specific office network: set the source to 203.0.113.0/24, protocol to TCP, and port to 443. To allow traffic from anywhere, use 0.0.0.0/0 (all IPv4) or ::/0 (all IPv6).

Cloudflare and CDN-Level Firewalls

When configuring IP access rules in Cloudflare or similar CDN firewalls, you specify CIDR ranges directly. This is particularly useful for blocking traffic from known malicious networks or restricting access to specific geographic regions. Use the IP Blacklist Check tool to verify whether an IP appears on known blocklists before adding it to your rules. For identifying the full network range of a suspicious IP, run it through the WHOIS Lookup to see the allocated CIDR block from the Regional Internet Registry.

Common Mistakes and Troubleshooting

CIDR math errors are one of the most common causes of firewall misconfigurations. According to NIST SP 800-41 guidelines on firewall policy, misconfigured rules are a leading source of security incidents. Here are the mistakes that cause the most problems:

• Wrong prefix length — Using /16 instead of /24 blocks 65,536 addresses instead of 256. Always double-check the prefix before applying a rule.
• Non-aligned network addresses — 192.168.1.50/24 is technically valid but misleading. The actual network starts at 192.168.1.0. Most tools normalize this automatically, but some firewalls may reject non-canonical CIDR notation.
• Overlapping rules — If you allow 10.0.0.0/16 but later block 10.0.5.0/24, the order of rules determines which takes effect. In iptables, the first matching rule wins. Always place more specific rules before broader ones.
• Forgetting IPv6 — If your network supports IPv6, blocking only IPv4 CIDR ranges leaves IPv6 traffic unfiltered. IPv6 uses the same CIDR notation but with 128-bit addresses (e.g., 2001:db8::/32).
• Stale rules — IP allocations change hands. A CIDR block you blocked six months ago may now belong to a legitimate service. Regularly audit your rules against current IANA IPv4 address assignments to catch outdated entries.

Best Practices for IP-Based Access Control

Writing correct CIDR blocks is only part of effective firewall management. Follow these best practices to maintain rules that stay reliable over time:

• Use allowlists over blocklists when possible — Defining which networks are permitted (allowlisting) is inherently more secure than trying to enumerate every malicious source. For administrative interfaces, restrict access to known office or VPN CIDR blocks.
• Document every rule — Include comments with the date, reason, and who requested the change. In iptables, use -m comment --comment "Block scanning from AS12345 - 2026-04" to annotate rules inline.
• Log before you block — When adding a new block rule, first add a LOG rule for the same CIDR to monitor what traffic it would catch. Review the logs for a day before switching to DROP. This prevents accidentally blocking legitimate traffic.
• Use ASN lookups to find complete ranges — If you need to block traffic from a specific organization, a single IP or small CIDR block is not enough. Use the ASN Lookup tool to find all prefixes announced by that network, then block the entire set.
• Audit rules quarterly — Remove rules that reference decommissioned networks, expired threat intelligence, or one-off incident blocks that are no longer needed. Stale rules accumulate and slow down rule processing.
• Test in staging first — Before deploying firewall changes to production, test the rules in a staging environment. Use the IP Lookup tool to verify that specific IPs fall inside or outside your intended CIDR blocks.
• Separate rules by purpose — Group your CIDR-based rules into categories: infrastructure protection, abuse mitigation, access control, and geo-restrictions. This makes auditing easier and helps new team members understand the intent behind each rule without guessing.

Frequently Asked Questions