VPN Gateway- S2S connection Failing

Question

VPN Gateway- S2S connection Failing

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

The existing Azure route for 172.19.0.0/16 is advertised on the Local Network Gateway, the connectivity is getting 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`172.19.20.0/22` prefix and saved the configuration, connectivity is immediately restored. and deleting the entry also its working and issue occurring back in few days.

so we are trying to understand why adding this its restoring the connectivity.

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

Why only 1 segment is getting affected? in the same connection, multiple different subnets are allowed, the other subnets are not facing any issue.
How to identify and resolve this issue.

Requesting some insights, on how to troubleshoot this issue, as its impacting users connecting to Azure from that subnet.

0 comments

1 answer

Your answer

Answer 1

Hi @Abrar Adil S

The fact that simply saving the Local Network Gateway fixes it is the biggest clue. That save forces the gateway to reprogram routes and tear down and rebuild every IPsec security association. So whatever breaks is stateful and gets reset, it isn't the config itself.

Why only one subnet breaks: most on-prem firewalls build a separate child SA per subnet pair (traffic selector). If one of those SAs goes stale after a rekey, only that subnet loses traffic while the others keep flowing through their own healthy SAs. The "fixes itself without changes" part fits too, it recovers at the next rekey cycle.

To confirm and fix it:

Compare traffic selectors on both sides. Azure route-based gateways expect any-to-any (0.0.0.0/0). If the on-prem device is policy-based or defines per-subnet selectors, enable UsePolicyBasedTrafficSelectors on the connection with a custom IPsec/IKE policy that matches on-prem exactly, or switch the on-prem side to route-based (VTI) with 0.0.0.0/0 selectors. This mismatch is the most common cause of exactly this pattern.
Align the SA lifetimes and PFS settings on both ends. Azure defaults are 28,800 seconds for IKE and 27,000 seconds for IPsec. A mismatch often breaks just one child SA at rekey time.
Check for overlap on 172.19.0.0/16. Look at the effective routes on an Azure VM NIC in the affected path and make sure no VNet, peered VNet, UDR or BGP route also covers part of 172.19.x.x. A more specific route elsewhere would explain why adding 172.19.20.0/22 changes behavior.
Next time it drops, before touching anything, run VPN troubleshoot in Network Watcher on the connection and turn on gateway diagnostics to Log Analytics (IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog). The IKE log will show which SA failed and why.
If your VpnGw1AZ is active-active, make sure on-prem has tunnels to both gateway instances. Otherwise Azure can return traffic through the instance with no tunnel.

If this helped, please click Accept Answer so others with intermittent S2S drops can find it.

References: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps https://learn.microsoft.com/en-us/azure/vpn-gateway/troubleshoot-vpn-with-azure-diagnostics