Azure Site to Site VPN connection disconnect after adding the NAT rule

Question

Azure Site to Site VPN connection disconnect after adding the NAT rule

Aeko Admin 0

Azure Site to Site VPN connection disconnect after adding the NAT rule.

I am creating a Site to Site VPN connection, and the client already has LAN subnet(10.0.0.0/24) configured for another tunnel on their end. From Azure portal am adding a NAT rule in the VNG - the connection is connected before adding the rule, and disconnect immediately after adding the NAT rule. How can I fix this issue

Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-06-01T21:32:26.2433333+00:00
Hi Aeko Admin,

Thanks for reaching out in Microsoft Q&A forum,

Your Site-to-Site VPN disconnects immediately after adding the NAT rule because the on-premises device is still expecting the original overlapping subnet (10.0.0.0/24) while Azure is now advertising the translated external network. This causes Phase 2 IPsec Security Association negotiation to fail.

Follow these steps in order:

Remove the current NAT rule that caused the disconnect (to restore the working connection first)

Verify your gateway supports NAT

Check your VPN Gateway SKU: Must be VpnGw2, VpnGw3, VpnGw4, VpnGw5 or their AZ variants

VpnGw1 and Basic SKUs do not support NAT rules

Ensure Route-Based VPN (not Policy-Based)

Go to your connection > Configuration

Make sure "Use Policy Based Traffic Selectors" is Disabled

Create a new Egress NAT rule with non-overlapping addresses

In the Azure portal: Virtual Network Gateway > NAT Rules > + Add

Type: Static or Dynamic (Static requires matching subnet sizes)

Mode: Egress (for traffic leaving Azure to on-prem)

Internal Mapping: Your Azure VNet range (e.g., 10.1.0.0/16)

External Mapping: A non-overlapping range the client doesn't use (e.g., 172.16.100.0/24, NOT 10.0.0.0/24)

If using BGP: Enable "Enable Bgp Route Translation"

Click Save (takes = 10 minutes)

Associate the NAT rule with your connection (critical step)

Go to the VPN Gateway > Connections > select your connection

In the connection settings, add the NAT rule under Egress NAT rules

This links the NAT translation to your specific VPN tunnel

Update the on-premises firewall/router (most common failure point) Ask your client to:

Add a route for the external NAT range (172.16.100.0/24) pointing to Azure's gateway public IP

Update encryption domains / traffic selectors / Phase 2 proxy IDs to use 172.16.100.0/24 instead of the original 10.0.0.0/24

Without this, the tunnel will drop because the device still expects the original overlapping subnet

Recreate or reconnect the VPN connection

Delete the existing connection and recreate it with the NAT rule associated

Or disconnect and reconnect to force Security Association renegotiation

Why This Happens

Your client already has 10.0.0.0/24 configured for another tunnel. When you add NAT without updating their device, Azure translates traffic to the external range but their firewall still expects 10.0.0.0/24, causing IPsec Phase 2 mismatch and immediate tunnel drop

Official Microsoft Documentation:

Configure NAT on VPN Gateway - Azure VPN Gateway | Microsoft Learn

Troubleshoot Azure Site-to-Site VPN disconnects intermittently - Azure VPN Gateway | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Aeko Admin 0 Reputation points

2026-06-02T14:22:42.27+00:00

Client already configured 172.20.15.0/24 subnet to use for this tunnel, they gave me that subnet to use.

I wouldnt be able to configure NAT with a basic Virtual Network Gateway.

Policy based selector is disabled.

I tried to simulate this with a firewall I have access to, and the azure tunnel and got the same issue.

The tunnel works fine without NAT, but disconnect after adding the NAT.
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-06-02T18:32:53.5466667+00:00

Hi Aeko Admin,

Thank you for your patience. The issue where the VPN tunnel disconnects immediately after adding the NAT rule. The tunnel works fine without NAT, which confirms the issue is related to NAT configuration mismatch.

To provide the correct configuration and resolve this, I need the following information from your side:

1. What is your actual on-premises LAN subnet that needs to communicate with Azure? You mentioned 10.0.0.0/24 is already used on another tunnel. Is this the same subnet, or is there a different subnet for this connection?

2. What is the Azure VNet CIDR you're connecting to? This is needed to determine which subnet needs NAT translation.

3. What does 172.20.15.0/24 represent on your firewall? Is this the local network (your LAN that will be translated) or the remote network (what you expect to see from Azure)?

4. What should Azure see as the source IP when traffic reaches your network? This determines the external NAT mapping.

5. What are your firewall's encryption domains / Phase 2 traffic selectors for this tunnel? After NAT is applied, Azure expects the translated network range, not the original. Your firewall must match this.

6. Is BGP enabled on this VPN connection? If yes, BGP route translation must be enabled on the Azure NAT rule.

7. What firewall/VPN device model are you using? (e.g., Fortinet, Palo Alto, Cisco ASA, etc.) > Different vendors handle NAT differently.
Aeko Admin 0 Reputation points

2026-06-03T11:03:29.51+00:00
On-premises LAN subnet is 172.27.0.0/24, this is the vendor site. They have a tunnel with 10.0.0.0/24 configured for another client. And I have 10.0.0.0/24 in azure, this is where NAT comes in picture.

10.0.0.0/24

172.20.15.0/24 is a subnet I gave the vendor to use to for the tunnel - and I created a NAT in the Virtual Network Gateway to NAT it to 10.0.0.0/24

172.20.15.0/24

Encryption works fine, otherwise I wouldnt have the tunnel up before configuring the NAT

No

Cisco Meraki

After the back and forth NAT issues - I now have a bigger issue.

Virtual Network Gateway is in a failed state and I cannot get it back online, I tried both the GUI and PowerShell to reset it but the results is the same.
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-06-03T18:06:35.2733333+00:00
Hi Aeko Admin,

The NAT rule is configured incorrectly. Current Setup: -

LisYour actual LAN: 172.27.0.0/24

Tunnel subnet you're using: 172.20.15.0/24

Azure VNet: 10.0.0.0/24

NAT rule: Translating 172.20.15.0/24 → 10.0.0.0/24 (WRONG)

The Problem: Azure VNet is already 10.0.0.0/24. Translating traffic TO 10.0.0.0/24 creates a routing conflict because Azure can't distinguish between its own VNet and translated VPN traffic.

Option A : Change Azure VNet Address Space

Change Azure VNet from 10.0.0.0/24 to 10.1.0.0/16 (or non-overlapping range)

Update NAT rule to:

Internal mapping: 172.27.0.0/24 (your real LAN)

External mapping: 172.20.15.0/24 (tunnel subnet)

Mode: Ingress SNAT

Update Local Network Gateway in Azure with new VNet CIDR

Reconnect VPN tunnel

Option B: Remove NAT Entirely

Delete the NAT rule

On your Meraki firewall, set Phase 2 local network to: 172.20.15.0/24

On your Meraki firewall, set Phase 2 remote network to: 10.0.0.0/24 (Azure VNet)

No NAT needed since 172.20.15.0/24 doesn't overlap with Azure's 10.0.0.0/24.

After the back and forth NAT issues - I now have a bigger issue.

Virtual Network Gateway is in a failed state and I cannot get it back online, I tried both the GUI and PowerShell to reset it but the results is the same.

If portal/PowerShell reset fails, try manual provisioning state fix:

Go to https://resources.azure.com/

Log in with your Azure credentials

Navigate to: subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworkGateways/<gateway-name>

Click Read/Write

Look for provisioningState and manually change it from Failed to Succeeded

Click Put to save

Similar case: https://learn.microsoft.com/en-us/answers/questions/87958/azure-virtual-network-gateway-connection-in-failedAlso, kindly share required details via private message?
Praveen Bandaru 11,635 Reputation points Microsoft External Staff Moderator

2026-06-05T09:42:14.88+00:00

Hello **Aeko Admin
Based on my analysis shows that the VPN tunnel was establishing successfully before NAT was enabled on the Azure Virtual Network Gateway, which confirms the initial IPsec/IKE configuration and encryption settings were correct. The issue began right after the NAT rule was added, suggesting that the problem is related to NAT traffic selector negotiation between the Azure VPN Gateway and the Cisco Meraki device.

The Azure VNet is using the 10.0.0.0/24 subnet, but the vendor has this same subnet configured for another VPN tunnel on their side. To avoid overlapping address conflicts, NAT was set up on the Azure VPN Gateway to translate 10.0.0.0/24 to 172.20.15.0/24 for this tunnel.

In this case, the Azure VPN Gateway should have an EgressSNAT rule only, mapping 10.0.0.0/24 (internal) to 172.20.15.0/24 (external). Once NAT is enabled, the remote device must use 172.20.15.0/24 as the remote encryption domain/traffic selector. If it still expects 10.0.0.0/24, Phase 2/IPsec negotiation will fail and the tunnel will disconnect after applying NAT.

During troubleshooting, the Azure Virtual Network Gateway entered a failed provisioning state. We tried recovery through the Azure Portal and PowerShell, but the gateway is still unavailable.

Recommended next steps are to:

Remove the NAT association from the VPN connection if possible

Clear the NAT configuration from the gateway

Check the traffic selectors on the Cisco Meraki device

Confirm the vendor is using 172.20.15.0/24 as the Azure-side network after NAT

If the gateway remains in a failed state, escalate to Microsoft support for further recovery

Right now, the main priority is to restore the Virtual Network Gateway before proceeding with more NAT testing. Please update us when the vendor confirms the configured encryption domains on the Meraki side so we can assist further.