VPN Gateway: Site-to-site Connectivity Issue — Traffic Stops Despite Connection Status

Question

VPN Gateway: Site-to-site Connectivity Issue — Traffic Stops Despite Connection Status

AlexanderMakarov-4508 0

Problem description

I am experiencing a critical connectivity issue with our Azure VPN Gateway. On October 21, 2026, around 18:00 UTC, all five Site-to-site VPN connections stopped passing traffic. Although Azure shows each connection as 'Connected,' traffic is no longer reaching at least one private destination, impacting multiple production environments.

Environment

The affected environment involves an Azure VPN Gateway used for site-to-site connectivity, with five VPN connections associated with it. The region, gateway SKU/tier, BGP status, and other network configurations are not specified in the case details.

What I've already tried

I have not attempted any troubleshooting steps yet, as the case details do not document any prior actions taken.

Current status

I am seeking guidance on diagnosing and resolving this connectivity issue, specifically on how to identify shared dependencies or configuration problems that could cause traffic loss despite the VPN connections showing as 'Connected.'

Chris Windle 0 Reputation points

2026-10-28T04:16:04.8366667+00:00

Did you resolve your situation, yet? We experienced the same exact symptoms as you described. We didn't notice the VPN was not passing traffic until Oct 23, 2026. Are you observing IKE_AUTH failures over UDP 4500? Also, are you in the Central US region? We have analyzed the problem enough to have isolated the problem down to Azure not responding to the IKE_AUTH requests from our Local VPN server. We see the initial IKE_SA_INIT packets with Azure over UDP 500, and then our server sends the IKE_AUTH on UDP 4500 and Azure never responds, so it times out and tries again a minute or two later. On the Azure side it times out after not receiving the IKE_AUTH packets. Microsoft's Root Analysis identified my reset of the VPN to try and clear the problem as the cause of the problem and declare it as resolved since it says Connected, but there have been 0 bytes egress for 3 days.

1 answer

Your answer

Chris Windle 0 Reputation points

2026-10-28T04:16:04.8366667+00:00

Did you resolve your situation, yet? We experienced the same exact symptoms as you described. We didn't notice the VPN was not passing traffic until Oct 23, 2026. Are you observing IKE_AUTH failures over UDP 4500? Also, are you in the Central US region? We have analyzed the problem enough to have isolated the problem down to Azure not responding to the IKE_AUTH requests from our Local VPN server. We see the initial IKE_SA_INIT packets with Azure over UDP 500, and then our server sends the IKE_AUTH on UDP 4500 and Azure never responds, so it times out and tries again a minute or two later. On the Azure side it times out after not receiving the IKE_AUTH packets. Microsoft's Root Analysis identified my reset of the VPN to try and clear the problem as the cause of the problem and declare it as resolved since it says Connected, but there have been 0 bytes egress for 3 days.

Answer 1

Hello @AlexanderMakarov-4508

Thanks for reporting this issue.

Since all five site-to-site VPN connections stopped passing traffic at the same time while Azure still reports them as Connected, I'd start by investigating a shared gateway, routing, or IPsec dataplane issue.

The Connected status indicates that the VPN connection is established, but it doesn't independently confirm that application traffic is successfully reaching its destination.

1. Check the VPN Gateway and connection metrics

In the Azure portal, navigate to:

Virtual network gateway > Monitoring > Metrics

Review the metrics around October 21, 18:00 UTC, particularly:

Tunnel ingress and egress bytes.
Tunnel bandwidth.
Tunnel ingress and egress packet drops, where available.
BGP peer status and advertised/learned routes, if BGP is enabled.

Compare the behavior across all five tunnels.

If traffic is entering Azure but not leaving the expected path, this may indicate a routing or forwarding problem.

If traffic isn't arriving at the gateway at all, the investigation should include the on-premises VPN devices and upstream connectivity.

2. Check BGP and effective routes

If your VPN connections use BGP, verify whether the expected routes are still being learned and advertised.

You can inspect the gateway's BGP peer status and learned routes using Azure CLI:

az network vnet-gateway list-bgp-peer-status \
  --resource-group <resource-group> \
  --name <gateway-name>
az network vnet-gateway list-learned-routes \
  --resource-group <resource-group> \
  --name <gateway-name>

If BGP isn't enabled, review the Local Network Gateway address prefixes and any user-defined routes affecting the destination networks.

Also check the effective routes on an affected Azure VM's network interface to confirm that traffic is following the expected next hop.

3. Review VPN diagnostic logs

If diagnostic logging is enabled, review the following categories:

GatewayDiagnosticLog
TunnelDiagnosticLog
RouteDiagnosticLog
IKEDiagnosticLog

These can help identify tunnel state changes, routing events, and IKE/IPsec negotiation issues around the reported incident time.

If logs weren't enabled before the incident, newly enabled logging won't recover historical diagnostic events.

4. Check for common configuration changes

Because all five connections were affected at approximately the same time, please review:

Recent VPN Gateway or connection configuration changes.
Changes to route tables, Azure Firewall, or NSG rules.
BGP route withdrawals or changes to on-premises routing.
IPsec/IKE configuration changes on the on-premises VPN devices.
Azure Service Health notifications affecting the gateway's region.

I wouldn't recommend resetting the VPN Gateway immediately, as this can interrupt all connections and may remove useful evidence of the current failure.

5. Capture the failing traffic path

If the issue persists, select one representative source and destination and test connectivity in both directions.

Where possible, collect packet captures from the affected Azure VM and the on-premises VPN device.

Azure VPN Gateway also supports packet capture for further troubleshooting.

The goal is to establish whether packets reach the VPN tunnel, whether they emerge on the other side, and whether return traffic follows the expected route.

6. Escalate the production incident

Since five production VPN connections are affected, I recommend opening a high-severity Azure Support case, with the severity selected according to your support plan and business impact.

Include the gateway resource ID, affected connection names, approximate start time (October 21, 18:00 UTC), gateway metrics, relevant diagnostic logs, and packet-capture findings.

Ask Microsoft Support to investigate the shared VPN Gateway dataplane and any relevant platform events.

Could you confirm the following?

What Azure region and VPN Gateway SKU are you using?
Are the five connections using BGP or static routing?
Do the VPN Gateway ingress/egress metrics show traffic after 18:00 UTC?
Are all five tunnels connected to the same on-premises VPN device, or to different devices?

These details will help determine whether the issue is related to a shared Azure Gateway dependency, route propagation, or the on-premises network.

Hope this helps narrow down the issue.

References:

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.