Azure Site-to-Site VPN With a Peer Behind NAT: Checklist

Work these checks in order and stop at the first one that fails. Most reports that Azure does not support a NATed device turn out to be a peer address Azure cannot reach, or a tunnel that never initiates from the correct side. The outer transport and the inner routing are two different problems, and mixing them wastes an afternoon. Each step below produces an observation you can hand to someone else.

Step 1: confirm the peer is behind NAT at all

Compare the address on the device's WAN interface with the address Azure sees for it. If they differ, something is translating, and that translator is now part of your VPN design. Ask the provider whether the mapping is static or shared, because a shared mapping changes what you can rely on. A device with a private WAN address and no forwarding is a different case from one behind a carrier-grade NAT with a stable public mapping.

If the two addresses match, stop here: NAT is not your problem and the rest of this list will not help.

Record both addresses and the translator's model in the ticket. That one line prevents the next round of questions about why the configured peer does not answer.

Step 2: agree on who initiates

The Azure VPN Gateway FAQ states NAT-T support and adds that the on-premises device should initiate the IPsec tunnel when it sits behind NAT. That matches how stateful translation works, since the translator keeps a mapping because the inside device sent the first packet. If Azure is expected to initiate and nothing arrives to create that mapping, the tunnel never starts.

Configure the peer so a responder-only mistake is obvious, and check whether the device retries on its own or needs a trigger. Some devices only bring a tunnel up when interesting traffic appears, which is fine until the interesting traffic is a health probe that never comes.

Watch the IKE exchange on the device during a manual initiation; silence there is a routing or firewall answer, not an Azure answer.

Step 3: get the peer address right

Azure needs a reachable public address for the peer in its local network gateway object, normally the translator's public address rather than the device's inside address. The identity the device authenticates with is a separate field and can legitimately differ from the address Azure dials. Keep the two straight, because swapping them produces an authentication failure that looks exactly like a NAT problem.

If the public address changes, that object has to change with it. A name that resolves to a stale address is worse than a static one you have to update by hand.

Write down all three values: device local address, translated public address, configured peer identity.

Step 4: open only the ports NAT-T needs

NAT-T carries ESP inside UDP, and RFC 3948 describes that encapsulation with port 4500 used after the initial negotiation on port 500. Your firewall and the translator both have to permit the exchange and its return traffic. Allowing an unrelated TCP port proves nothing about this path, and a rule that permits outbound but not the reply will still fail.

A static inbound port forward is not automatically required when the peer initiates and the translator keeps state. It becomes necessary when the mapping is unstable or when something in the path expires state aggressively.

Capture on both sides of the translator once; the encapsulation difference is immediately visible.

Step 5: separate outer transport from inner routing

A tunnel that establishes and carries nothing is a routing problem, not a NAT-T problem. The sites still need compatible traffic selectors, matching address spaces, access rules and a return path for the application networks. None of that is supplied by a successful IKE exchange.

If the two sites use overlapping private ranges, translating inside the tunnel is a separate design with its own rules. Do not renumber a subnet just because the outer gateway happens to sit behind a home router.

Classify the failure by stage before you change anything, and keep that classification in the ticket so the next person starts where you stopped.