Plan Subnets Before a Site VPN: Renumber or Translate

Two offices both use 192.168.1.0/24 because nobody planned otherwise, and the tunnel is expected to sort it out. It cannot: a router cannot make the same private address mean two different places. The work that prevents this happens before the first tunnel parameter is typed.

Inventory every range, including the ones you forgot

Collect the LANs, server segments, remote-access client pools, cloud VPC ranges and any container or overlay networks that hosts must reach. Client pools are the ones people forget, and they overlap an office range surprisingly often because both were picked from the same default. Include the management network and any out-of-band segment.

Record owner, gateway, purpose and whether the prefix must be reachable from the other site. A prefix that never needs to cross the tunnel does not have to be unique, and knowing that reduces the renumbering work.

Do IPv6 separately, because its plan and its overlaps are independent.

Compare prefixes, not familiar addresses

Two networks with different host addresses can still overlap, because overlap is a property of masks rather than of the numbers people remember. 10.20.0.0/16 contains 10.20.30.0/24 whether or not anyone says so out loud. Compare full prefix pairs, and check aggregates against the smaller networks inside them. That is why the check belongs in a spreadsheet rather than in someone's head.

The same check applies to the VPN's own client pool and to any translated range you plan to introduce, since a translated range that collides is worse than the original overlap.

A table of prefixes with masks is enough; a diagram without masks is not.

Decide what actually has to cross

A site may contain thirty subnets while one service network needs remote access. Start from that requirement and advertise only what it needs, because smaller advertisements and matching access rules are easier to review and harder to widen by accident. Announcing every private range in use is a habit that turns a tunnel into a bridge. The narrower the advertisement, the smaller the blast radius of a future mistake.

Private DNS has to return addresses the intended clients can reach, so a name pointing at an unadvertised or overlapping range stays broken even when the lookup succeeds.

Write the access list before the tunnel config, not after it fails.

Renumber or translate, and know the cost

Renumbering one network is usually the clearest long-term remedy, and it touches reservations, devices, DNS, firewall rules and anything with an address baked into a config. Translating an access range is the alternative when renumbering is impractical, and it costs source identity plus a class of protocols that embed addresses in payloads. Pick one and finish it, because a half-renumbered network is worse than either option.

Whichever you choose, document both the original and the presented address, because every later troubleshooting conversation needs them.

A workaround without a reply path is not a workaround.

Use a route matrix as the acceptance test

Finish with a matrix: local prefix, remote prefix, permitted service and return gateway. That table is the acceptance test when the tunnel comes up, and it is also the document the next engineer will read. Test from real hosts on the selected subnets rather than from the gateways.

A ping between tunnel addresses proves the tunnel exists and nothing about the address plan behind it.

Keep the matrix with the tunnel configuration, and the next site addition starts from data instead of memory. The strongSwan forwarding guide covers the gateway side once the plan exists.