Choosing an RFC 1918 range that will not collide with your VPN peers
RFC 1918 defines three private address ranges available for internal use: 10.0.0.0 divided by 8, 172.16.0.0 divided by 12, and 192.168.0.0 divided by 16. When you connect multiple networks via VPN, routing becomes impossible if two peers claim the same subnet. This guide walks you through a repeatable allocation strategy that prevents collisions and scales across your organization.
Why RFC 1918 collisions break VPN connectivity
A VPN tunnel connects two or more networks by encrypting traffic between them. Your router learns routes to subnets on the far end and forwards matching packets into the tunnel. If your office uses 10.0.0.0 divided by 24 and your branch office also uses 10.0.0.0 divided by 24, the router cannot distinguish which traffic belongs to which peer. Packets destined for 10.0.1.5 might go to the wrong site, or the tunnel may refuse to establish at all. Most VPN concentrators detect this during configuration and reject overlapping proposals.
The three RFC 1918 ranges and their capacity
- →10.0.0.0 divided by 8: 16,777,216 addresses. Largest range, suitable for enterprise networks with many sites.
- →172.16.0.0 divided by 12: 1,048,576 addresses. Medium range, often used for secondary or isolated segments.
- →192.168.0.0 divided by 16: 65,536 addresses. Smallest range, common in small offices and home networks.
Most organizations begin with 10.0.0.0 divided by 8 because it offers the most flexibility. If you have fewer than 16 sites, you can subdivide it into /16 blocks (10.0.0.0 divided by 16, 10.1.0.0 divided by 16, etc.), giving each site 65,536 usable addresses. If you have more sites or expect rapid growth, use /20 or /24 blocks and document your allocation in a spreadsheet or IPAM system.
Allocation strategy for multi-site VPN networks
Start by listing all sites and estimating the number of hosts at each. Then assign a non-overlapping subnet to each site from a single RFC 1918 range. Write it down. For example:
Site Subnet Hosts --- ------ ----- Headquarters 10.0.0.0 / 22 800 Branch-1 10.0.4.0 / 23 300 Branch-2 10.0.6.0 / 24 100 Branch-3 10.0.7.0 / 25 50 Remote-VPN 10.0.8.0 / 21 1200
Each subnet is contiguous, non-overlapping, and routable across all VPN peers. When you add a new site, assign the next available block. If you run out of space in 10.0.0.0 divided by 8, migrate non-critical segments to 172.16.0.0 divided by 12 or 192.168.0.0 divided by 16, but keep the migration plan documented and coordinate with all stakeholders before making changes.
Avoiding collisions with existing infrastructure
Before you assign RFC 1918 ranges, audit your current network. Check your office LAN, guest networks, management networks, and any legacy systems. Many organizations inherit 192.168.1.0 divided by 24 from old equipment or ISP-provided routers. If you plan to use 192.168.0.0 divided by 16 for VPN, you must first renumber or isolate conflicting subnets. Document all in-use ranges and mark them as off-limits in your allocation plan.
Also verify that your VPN concentrator, firewall, or SD-WAN controller does not reserve any ranges for its own use. Some platforms use 10.255.0.0 divided by 16 for management traffic or 192.168.0.0 divided by 24 for default configurations. Consult your vendor documentation and test your allocation in a lab before deploying to production.
Testing and validation
Once you have assigned subnets, validate them in your VPN configuration. Most platforms allow you to preview the tunnel parameters before activation. Confirm that each peer has a unique local subnet and that no remote subnet overlaps with any other. After the tunnel is live, ping across the VPN and verify that traffic reaches the correct destination. Use traceroute or your vendor's tunnel diagnostics to confirm the path.