CIDR Overlap in VPN and Private Networks: How to Find Bad Subnet Planning

The Silent Routing Failure Nobody Checks

Your office LAN uses 10.0.0.0/8. Your VPN assigns 10.8.0.0/24. Your cloud VPC uses 10.1.0.0/16. Everything works until someone in the office tries to reach a specific cloud service, and the packets never leave the local network. The machine sees 10.1.0.50 and thinks, "that is local" — it never sends the traffic through the VPN tunnel.

CIDR overlap is the most common networking mistake in hybrid environments. It produces no error messages, just unreachable hosts that look like they should work. Use the OpsCheck Subnet Calculator to map all your address spaces before you connect networks.

Symptoms of CIDR Overlap

• A host in one network cannot reach a specific IP in another network, but other IPs work
• Traceroute shows the packet never leaving the source network
• Adding a static route fixes it temporarily but breaks something else
• The problem appears only from certain subnets

Auditing Your Address Space

# List all routes on a Linux host
ip route show | grep -E "^10\.|^172\.|^192\."

# Check which interface handles a specific destination
ip route get 10.1.0.50

# Use Python to check overlaps
python3 - <<'PY'
import ipaddress
networks = [
    ipaddress.ip_network("10.0.0.0/8"),
    ipaddress.ip_network("10.1.0.0/16"),
    ipaddress.ip_network("10.8.0.0/24"),
]
for i, a in enumerate(networks):
    for b in networks[i+1:]:
        if a.overlaps(b):
            print(f"OVERLAP: {a} overlaps {b}")
PY

The output is immediate: overlapping ranges mean your routing tables have ambiguous destinations. The kernel picks the most specific route (longest prefix), which might not be the one you intended.

# Quick check: does your VPN route actually cover the conflicting range?
ip route show | grep -E "10\.1\.0\.|tun|vpn"

# Run traceroute to a known host in the conflicting range
# First hop reveals whether traffic stays local or goes through VPN
traceroute -n 10.1.0.50 | head -3

Fix Strategies

The cleanest fix is renumbering one of the overlapping networks, but that is often impractical in production. Pragmatic alternatives: use a /16 for your office, a different /16 for each cloud VPC, and ensure your VPN pool is a /24 outside all of them. The OpsCheck IP Geolocation tool helps verify public IP ranges, but for private space, careful planning is the only defense.

# Map your actual address usage before renumbering
# Find which subnets are actually in use on a Linux host
ip addr show | grep inet | awk '{print $2}'

# Check DHCP pool ranges
grep -E "^range|^subnet" /etc/dhcp/dhcpd.conf 2>/dev/null || true

Real-World Scenario

A team set up a site-to-site VPN between their office (192.168.0.0/16) and a colocation facility (also 192.168.0.0/24). The office had been using the full /16 for years. After the VPN connected, office workstations could not reach the colo servers at 192.168.0.50 — the local switch saw that IP as on the same subnet and never forwarded it to the VPN gateway. The fix was adding a /32 host route for the critical server, then planning a full office renumbering to 10.x space over the next maintenance window.

Checklist

• Run the overlap script above before connecting any two networks
• Document all private address ranges: office LAN, VPN pools, cloud VPCs, management networks
• Prefer 10.x.y.0/24 for small networks — far less likely to overlap than 192.168.x.0
• Use OpsCheck Subnet Calculator to validate new subnet proposals