When NAT Inside a Site-to-Site VPN Earns Its Place

Two sites both use the same private range, and the tunnel comes up while nothing useful crosses it. Translation is the usual answer, and it is a real one: presenting a different range to the far side can solve an overlap or a return path that the other network cannot route. The part that gets skipped is that translation changes the addresses every later decision sees. Treat it as a documented design decision with a written mapping, not as a rule added until a ping succeeds.

Decide Which Address Gets Rewritten

Source translation changes what the remote service and its logs see as the client, so a branch host becomes a gateway address on arrival. Destination or prefix translation presents an alternate address for a remote resource instead. Some deployments need coordinated translation on both sides to separate two otherwise identical networks, and the combination is where most confusion starts.

Write down the source before translation, the destination as the application names it, and the address pair each gateway matches on. Three columns are enough, and the third column is the one people leave out.

Selector order matters as well. IPsec policy selection and translation happen at defined stages, so a selector written for pre-translation addresses may never match the packet at the stage you assumed. Check the policy that is installed rather than the policy you intended to install, because the two diverge exactly when a rule was accepted by one component and ignored by another:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Follow the Payload and the Return Path

A server that logs the translated source instead of the individual branch host will break any rule or report keyed to the original address. Before you change the mapping, find out whether anything downstream makes a decision from that field: access lists, audit reports, rate limits, licence checks. Each of those is a place where the translation surfaces later as an unexplained failure.

Protocols that carry addresses inside their payload need separate planning, because rewriting the outer header does not touch the inner reference. Active FTP, SIP and some remote-access products are the classic cases, and a design that ignores them will work for web traffic and fail for the application that mattered.

Return traffic depends on stateful mappings. Gateway failover can lose that state, asymmetric routing can bypass it, and a restart can clear it while sessions remain open on the far side. That is why a request that reaches the destination and a session that completes are two different acceptance results.

Weigh It Against Renumbering a Site

Renumbering one conflicting site removes the mapping entirely and leaves an address plan that can be read without translation tables. It is operationally expensive: DNS records, static assignments, firewall rules and every documented address have to change together. The cost lands once, in a planned window, with a clear end state. What you buy is the ability to read a packet capture years later without a lookup table.

Translation avoids most local changes and creates a mapping that has to be maintained in DNS, documentation and troubleshooting forever. The cost lands continuously, in the form of every future engineer who has to learn that one prefix means something else inside the tunnel.

For a temporary connection or a partner network you do not control, the continuous cost is usually worth paying. For two sites you own and will own for years, renumbering is often the cheaper decision once the migration is counted honestly.

Prove Both Directions With a Real Session

Test an application session rather than a single probe. A successful echo request proves that one direction of one protocol works, and it is entirely compatible with a return path that fails for anything stateful. Use the service that motivated the design, and read its log at the far end to see which source address it recorded.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Then confirm that only the intended services are reachable across the mapping. Translation changes addressing and does nothing about authorisation, so firewall policy still decides what is allowed. A design that relies on an obscure translated prefix as its access control has no access control at all.

Record the mapping, the tested session and the addresses each side observed. The next person to debug this tunnel needs those three facts more than they need the configuration file.