Azure S2S VPN Connectivity Restored After Updating Local Network Gateway Address Space – VpnGw1AZ

Question

Azure S2S VPN Connectivity Restored After Updating Local Network Gateway Address Space – VpnGw1AZ

Abrar Adil S 476

We are facing an intermittent connectivity issue between our on-premises network and Azure over a Site-to-Site VPN.

Environment:

Azure VPN Gateway SKU: VpnGw1AZ
VPN type: Route-based

During the failure:

The client sends TCP SYN packets towards Azure server.
Palo Alto packet capture confirms that the traffic reaches the firewall and is sent towards the VPN tunnel.
However, no SYN-ACK/return traffic is received from Azure.
Azure VM NIC packet capture does not show the SYN arriving at the VM during the failure window.
Azure-to-on-prem tracepath also does not reach the first on-premises hop.

The existing Azure route for 172.19.0.0/16 is already present through the Virtual Network Gateway, so the affected client is covered by the configured address space.

The connectivity is restored when we edit and save the Local Network Gateway address space.

For example, 172.19.0.0/16 was already configured. When we added the more-specific 172.19.20.0/22 prefix and saved the configuration, connectivity was immediately restored.

172.19.20.0/22 is already a subset of 172.19.0.0/16, so we are trying to understand why adding this prefix appears to restore connectivity.

In some cases, connectivity also restores automatically without making any configuration changes.

Additional observation

Azure VPN Gateway metrics also show some Tunnel Egress Packet Drops / Traffic Selector Mismatch events, although we are still correlating these specifically with the affected VPN connection.

Questions

When a Local Network Gateway address space is modified and saved, does Azure reapply/reconcile the VPN connection or tunnel configuration, potentially causing a brief tunnel interruption/re-establishment even when there is no explicit VPN connection reset event?
Why only one segment of IP's are getting affected, as the connection is supporting multiple other IP segments, receiving connection issues only for the 172.19.0.0/16 segment, if the tunnel is going down the other segments should also be affected

0 comments

1 answer

Your answer

Answer 1

Hello @Abrar Adil S

The key clue here is the Traffic Selector Mismatch metric. A traffic-selector mismatch causes connectivity failures when the local/remote addresses don't match the selectors negotiated between the VPN peers.

Regarding your questions:

1. Does saving the Local Network Gateway reapply/reconcile the connection?

Modifying a Local Network Gateway that already has a connection may cause tunnel disconnects and downtime. Therefore, connectivity returning after changing/saving the address space could be because the VPN configuration is reapplied. However, I cannot find Microsoft documentation confirming that every LNG address-space save forces a specific IKE/IPsec SA renegotiation or explaining this exact recovery behavior.

2. Why is only 172.19.0.0/16 affected?

That actually makes a complete tunnel outage less likely. A traffic-selector mismatch can affect traffic whose source/destination addresses don't match the negotiated selectors. Other prefixes can therefore continue working while traffic associated with a problematic selector is dropped.

Adding 172.19.20.0/22 should not normally be required for Azure routing if 172.19.0.0/16 already represents the on-premises network correctly. The fact that adding the more-specific prefix temporarily restores connectivity suggests the next investigation should focus on the negotiated Phase 2/Quick Mode traffic selectors, rather than treating the /22 as the permanent fix.

I recommend capturing the failure before modifying the LNG again and comparing:

Azure VPN Gateway traffic-selector/drop metrics
IKE diagnostic logs
the negotiated Phase 2 selectors on the Palo Alto
an Azure VPN Gateway packet capture filtered to the affected 172.19.20.0/22 traffic

Microsoft supports VPN Gateway packet capture to isolate whether traffic is being lost on the Azure side, the customer side, or between them.

Given the observed Traffic Selector Mismatch events, focus on establishing exactly which selector is negotiated during the failure versus after the LNG save.

References:

Troubleshoot S2S VPN error codes

VPN Gateway traffic selectors

Modify Local Network Gateway settings

VPN Gateway packet capture

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.