Plan Private VPN Address Ranges Before Sites Collide

Two sites that both use 192.168.1.0/24 can each reach the internet and still fail to reach each other. The gateway does not raise an error; it installs one route for that prefix and sends every packet to whichever peer claimed it first. Nothing in the handshake, the cipher list or the interface metric says which peer is wrong. Address planning is the part of the design that settles this before anyone connects.

Inventory every space that has to be reachable

Write down the ranges that must be routed, not only the ones you are configuring. That means site LANs, VPN client pools, cloud subnets, management and out-of-band networks, lab segments, and the networks users routinely connect from at home. A consumer router that ships as 192.168.1.0/24 is not hypothetical, and the same prefix appears in hotels and conference venues. The inventory is a table of prefix, owner and purpose, and it is the only artefact that stops the same range being handed out twice.

Add the prefixes you expect within the next year, because a plan that covers only today fails at the first new site. Mark each row with who can change it, not just who owns it.

Reuse is what makes this hard: private space is finite and every organisation treats 10.0.0.0/8 as its own. A plan cannot promise that no future guest LAN will land on one of your prefixes, so the design has to say what happens when it does. Two rules do most of the work. Put client pools in one contiguous block you can summarise, and never allocate a range that another team already routes. Everything else is a record that somebody keeps current.

Why an overlap defeats the routing table

A route is a prefix plus a next hop, and forwarding picks the longest matching prefix. When two peers both claim 192.168.1.0/24, the table holds one entry for it, so traffic for both sites leaves through the same tunnel. The second site is not misconfigured; it is unreachable because the first one answers for the same addresses. No metric can separate them, since the match happens before metrics are consulted.

The failure is asymmetric and easy to misread. Hosts on site A reach the gateway and some services, while site B's hosts answer nothing, and the log shows a healthy tunnel in both directions. That pattern is an address collision rather than an authentication or firewall fault, and confirming it takes one table dump compared against the inventory.

Size the client pool and the site ranges deliberately

A VPN client pool is a range the gateway hands out one address at a time, so its size caps concurrency. A /24 holds 254 usable addresses, which is generous for a small team and tight for a branch that runs containers; a /22 costs nothing extra inside private space and removes the argument. Keep the pool contiguous and clear of every site LAN, so the summary route toward clients never swallows a site. Reserve the range even while the pool is empty, because an unwritten range is the one the next engineer will allocate.

Sites get ranges sized for expected hosts plus growth, and aligned on a boundary that summarises cleanly. Deliberate gaps between allocations cost nothing and buy room to aggregate later.

Then check the direction people forget: the return path. Each site router needs a route to the client pool, and the concentrator needs a route to every site prefix it serves. A tidy prefix table with no path back to the pool is still a broken design, and the symptom is a one-way connection that answers nothing. Keep both directions in the same table and review it whenever a site is added.

Translation and renumbering solve different problems

When an overlap already exists, there are two honest options and one dishonest one. Renumbering removes the collision permanently and costs a maintenance window plus every hard-coded address you forgot. Address translation maps one side's private range into another range at the tunnel edge, which leaves both sites untouched but adds state, breaks protocols that embed addresses, and makes logs harder to read. The dishonest option is a host route to a single server, which passes one test and fails everything else.

Choose by control and lifetime. A site you own and can schedule belongs on the renumber path; a partner network you cannot touch, used for one application, is a candidate for translation with a documented mapping. Write that mapping down, because translation that exists only inside a configuration file disappears the moment the file is replaced.

Test from the far side before you deploy

Test from a network that does not host the gateway, because the gateway's own LAN hides most routing mistakes. Connect a client behind an ordinary home router, then reach a service on each site and one inside the client pool. Test the reverse direction too, from a site host to the client, since return paths fail independently. A test that only pings the gateway proves the tunnel is up and nothing more.

Keep ranges, owners and translation mappings in one shared record that the next site reads before allocating anything. Review it when a site is added, and treat an undocumented range as a defect rather than a surprise.

The record is the deliverable. A plan that lives in three people's memory fails the first time one of them is on leave, and an overlap found in production costs more than the table would have.