Pick VPN Address Space by Allocation, Not by Obscurity

An unusual-looking prefix feels like an escape from the home-versus-office address conflict, and it usually is not. Every block in the IPv4 special-purpose registry has an owner, a purpose and a reason it exists, and borrowing one because it looks quiet moves the collision instead of removing it. Run this as a sequence: read the allocation, inventory what already overlaps, and only then decide whether you are renumbering, translating or generating fresh space. The sequence matters because the third step depends on what the first two found.

Read the allocation before you borrow a range

The IANA special-purpose registry separates ranges that are reusable private space from ranges that serve one specific technical purpose. Private use, shared address space, benchmarking and documentation blocks look similar in a spreadsheet and behave completely differently once they are routed.

Two prefixes that differ only in the second octet are not the same block: 198.18.0.0/15 carries the benchmarking reservation, while 192.18.0.0/16 carries nothing of the kind. A number that merely resembles a reserved range does not inherit its meaning. This confusion is common enough to warrant a second look before it reaches a firewall rule.

Products sometimes use a special range deliberately inside a coordinated overlay, and that is their design to document. It does not make the same range spare space for an unrelated LAN. Public space is not a hiding place either: a private route to an address that belongs to someone else diverts traffic meant for its legitimate destination.

Inventory the overlaps you already have

Before choosing a prefix, list every network that will be reachable from the tunnel. Sites, client pools, cloud VPCs and partner links all count, and the partner link is the one people forget until the first connection attempt fails.

ip -4 route show table all
ip -6 route show
ip -br addr
ip route get 192.168.1.10

Put the results in one table with the owner of each range beside it. A range you cannot name an owner for is a range you cannot renumber later, and the inventory is what turns an argument about "unusual" prefixes into a decision about specific numbers. It also tells you whether the conflict you are trying to avoid is real or imagined.

If a remote worker's home network uses the same prefix as the office LAN, that conflict is visible in the inventory and can be handled explicitly. It is not evidence that a benchmarking block would be a clever choice, and treating it that way is how the next collision gets created.

Generate a unique ULA instead of copying a prefix

IPv6 solves the reuse problem with a different mechanism rather than a better-looking number. RFC 4193 defines locally assigned unique local addresses with a pseudo-random 40-bit global identifier, which gives you a site /48 that is very unlikely to collide with anyone else's. The probability is high, not absolute, and a ULA prefix still provides no internet reachability.

openssl rand -hex 5

Ten hexadecimal digits are forty bits. Prefix them with fd and group them into the /48: an output of 3f9c1a7b02 becomes fd3f:9c1a:7b02::/48. Generate one per site and record it, instead of pasting the same convenient fd00::/48 into every deployment.

Then confirm the whole path actually speaks IPv6. Clients, gateway, routes, private DNS and service policy all have to agree, and assigning a prefix to the tunnel does not make an IPv4-only application use it.

Plan the overlap you cannot remove

Some overlaps are permanent, usually because a partner will not renumber and you cannot make them. That is when you choose a supported mechanism deliberately: renumbering on your side, an isolated routing context, or explicit translation at a boundary. Choosing it deliberately means writing down which one you picked and why the other two were rejected. That note is what a future change review will actually read.

Translation has to preserve the return path, which means recording both the original and the presented prefix and matching them to the private DNS names that resolve into them. A mapped alias can make one connection unambiguous; it does not make the original addresses globally unique, and it will not survive a second overlapping partner without a second mapping.

Write the allocation down with its exception

Finish with a document that lists every prefix, its category, its owner and the reason it was chosen. Add the exceptions with their translation or renumbering rule, and the date someone approved them. Keep it next to the firewall rules that implement it rather than in a wiki nobody opens during an incident. The document is the deliverable, not a summary of it.

That record is what stops the next engineer from hunting for a stranger-looking number, which is how this problem gets rediscovered every few years under a new name. It also gives a change review something concrete to approve instead of an opinion about prefixes. Write it once, at the end of the allocation, while the reasoning is still in front of you.