Azure VPN NAT does not fix overlapping VNet addresses
Two VNets with the same private range will not connect just because NAT exists. Check the connection type first, then renumber or own a translation alias.
Both VNets use 10.40.1.0/24, the tunnels come up, and nothing works. Adding a second VPN gateway does not change that, and neither does a lower route metric, because the problem is not path selection. Two workloads answering to the same private address leave every packet with an ambiguous destination and an unverifiable return path. Before planning any translation, find out which connection type you actually created, since that single choice decides whether Azure's NAT feature is available at all.
What the symptom is really telling you
When a host in VNet A sends to 10.40.1.10, the routing table can only point it somewhere. If VNet B also contains 10.40.1.10, that address is not a destination the path can distinguish; it is one address with two owners.
The second gateway people usually deploy does not help. It gives you another tunnel, not another address, and the duplicate range travels inside the tunnel unchanged. It also doubles the configuration you have to keep consistent. What it cannot do is make one address mean two hosts.
Changing the public addresses of the VPN peers does nothing either. Those addresses identify the tunnel endpoints, while the collision is in the private range carried inside it.
The connection type decides whether NAT is available
Azure VPN Gateway does have a NAT capability, and it is documented for route-based IPsec cross-premises connections on specific gateway SKUs. The same documentation excludes VNet-to-VNet and point-to-site connections, so the feature is not a checkbox that appears on every gateway relationship.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Native VNet-to-VNet also requires the VNet and local-network ranges to be nonoverlapping in the first place, which is consistent with the exclusion. VNet peering is not an overlap workaround for the same reason.
There is a supported alternative that people conflate with the native type: model the other VNet as a local network and connect it as a site-to-site. That is a different resource and a different design, so treat a relabelled connection as a change to be validated, not a rename.
Renumber, or translate with something that owns the alias
If both VNets are yours, compare a planned renumbering against the ongoing cost of translation. Renumbering touches application configuration, DNS records, security rules and every existing connection, but it leaves a network that reads normally afterwards. Do it one subnet at a time, with the DNS change last. A half-renumbered range is worse than either option, because both prefixes then look authoritative to whoever reads the table next.
Where renumbering is not practical, use a translated design with a real owner for the alias. Callers in VNet A might reach VNet B's 10.40.1.10 as 10.140.1.10, but that alias needs a device that translates, a route toward it, and matching behaviour for the reply. An address added to DNS alone is not a translation.
Record both ranges in both directions: what the caller dials, what the destination sees as the source, and which side may initiate. Azure's own NAT rules include the reverse translation for their SNAT mappings, so you do not write a matching DNAT rule by hand, but that convenience stops at the connection types the feature supports.
What will not work
A user-defined route or a route metric cannot create a missing address distinction. Both operate on a destination that is still ambiguous, and the packet arrives at whichever next hop the table prefers.
Adding the duplicate range to a route table as a more specific prefix only moves the ambiguity one step. It also tends to break the other direction, where the reply now has two plausible sources.
Accept the design with traffic in both directions
Prove the design with a fresh permitted operation from each side, not with tunnel status. A connected IPsec tunnel says the peers agree on crypto; it says nothing about whether the destinations became distinguishable.
Then run the denied paths: an address that should stay unreachable, and a service the policy should block. If both still succeed, the translation is wider than the design intended.
Close with the facts that explain the setup later: the original range, the presented range, the device that translates, and the direction each side may initiate. If any of those is missing, the next engineer inherits a network where two hosts share a name and nobody remembers why one of them answers.