Two sites, one subnet: build an alias view for each

Two customer sites both run 192.168.50.0/24, and a remote engineer needs to reach a printer at the same address in each. No routing trick resolves that ambiguity on its own. Each site needs a distinct address view, and the gateway must pick the site from that view before it forwards anything.

The plan has four parts: alias prefixes, both translation directions, overlay policy and names. Each has to agree with the others.

Pick one alias prefix per site

Assign each site a whole alias prefix that belongs to nobody else in the estate. A two-site plan might map Site A's 192.168.50.0/24 to 172.21.10.0/24 and Site B's identical LAN to 172.21.20.0/24. Check the candidates against every participating network, including cloud VPCs and other VPN pools. Private address space is shared by every organisation, so a range being RFC 1918 says nothing about it being free here.

Publish the alias, not the native subnet, to remote users. The native range stays a local fact.

Translate in both directions

Translate in both directions. Destination mapping rewrites an alias address into the native address at the owning site. Source mapping rewrites the remote caller into an alias that other sites can distinguish.

A static one-to-one mapping is deterministic, and that does not make the implementation stateless. Reverse translation can depend on connection state, and failover or asymmetric paths can break a plan that ignores it. The platform's documentation decides which of those applies.

The exact stage where policy, selectors and routes apply differs between policy-based IPsec, route-based tunnels and other products. Design to the one you run.

Carry the plan through the overlay

In a hub, assign each alias prefix to the site path that owns it and permit only the transit the task needs. In a mesh, every relevant peer needs the same prefix and policy knowledge. Adding tunnels does not fix ambiguous addressing by itself.

Whole-subnet publication is broader than publishing one service. If only a few machines or ports are needed, keep the access rules narrower than the mapping.

Header translation does not rewrite application payloads. Redirects, embedded addresses in configuration files and source-based permissions can all still carry the native address. Test the application path, not only the ping. A working ICMP reply proves the mapping exists and says nothing about whether the application accepts the alias.

Fix the names each caller sees

Give maintenance names answers that match the caller's view. If the remote engineer resolves a hostname, it should return the alias address for that site, not the shared native range.

Check DNS views per site before the first maintenance window. A name that resolves to the native subnet sends the caller back into the ambiguity the plan was meant to remove.

Record and verify per site

Accept each site separately from a real caller and confirm which machine answered. Record the native address, the alias, the owning gateway and the permitted service together.

That inventory is what preserves the distinction when a third site arrives with the same default LAN. The policy-based IPsec NAT guide documents one concrete translation model; it is not a contract for every platform.