VPN Gateway (VpnGw1AZ): ~300 s periodic data-path stalls on S2S tunnel, follows active instance, no log entries

Francis Morissette 0 Reputation points
2026-11-11T18:52:01.3+00:00

Title: VPN Gateway (VpnGw1AZ): ~300 s periodic data-path stalls on S2S tunnel, follows active instance, no log entries

Problem

On a site-to-site IPsec VPN, traffic through the tunnel stalls for 100 to 400 ms about every 300 seconds (measured interval 300.3 to 300.6 s), in both directions at the same instant, then recovers. There is no packet loss, only delay. Normal RTT through the tunnel is 9 to 10 ms. The connection stays Connected the whole time.

Environment

  • Azure VPN Gateway: VpnGw1AZ, Generation1, Canada East, route-based, active-standby, BGP disabled
  • Connection: IKEv2, default IPsec/IKE policy (no custom policy)
  • GatewaySubnet: no NSG, no route table
  • On-premises device: SonicWall NSa 4700, route-based tunnel, IKEv2, AES-256, SHA1, DH group 2, PFS off, 3600 s lifetimes, DPD 60 s, no NAT between the peers

Evidence that the delay is inside the Azure VPN Gateway

  • VM to VM inside the VNet stays at 0 to 1 ms during the stalls.
  • A ping to the gateway public IP (outside the tunnel, same internet path) stays at 8 to 12 ms during the stalls.
  • On-premises internet traffic and other site-to-site tunnels on the same link do not stall.
  • A packet capture of ESP on the on-premises WAN interface during a stall shows our outbound ESP leaving on schedule, while the replies from the Azure gateway arrive 50 to 66 ms late on the wire (under 17 ms normally).
  • Small packets and 1300-byte DF packets are affected the same way (not MTU related).

What we have already done, with results

  1. Enabled GatewayDiagnosticLog, TunnelDiagnosticLog, IKEDiagnosticLog and RouteDiagnosticLog to Log Analytics. No entry of any category matches any stall time. The only regular entries are the hourly rekeys started by our device.
  2. Reset the gateway. The standby instance (IN_1) became primary, and the tunnel came back within seconds (migrated SA). The stalls continued on IN_1, but on a new schedule: the 300 s timer restarted at the switchover. So the same periodic event happens on both instances and follows whichever instance is active.
  3. Removed an overlapping prefix from the local network gateway (10.0.0.0/8 overlapped the VNet; replaced with the actual on-premises prefixes). The stalls continued, on the same schedule as before the change.
  4. Ruled out on our side: IKE/IPsec rekey timing, DPD/keepalive, MTU, on-premises CPU or inspection load, traffic volume, VM CPU.

Question

Is a periodic (about 300 s) pause in IPsec forwarding a known behavior of VpnGw1AZ Generation1 instances (health probe, route programming, telemetry collection, or similar)? Would moving to Generation2 or a larger SKU avoid it?

Note on support: we opened support case 2611100040008419 and completed every step the support team recommended (above). After the last step, support agreed the issue should go to the engineering team, but the case was then redirected here: the portal no longer lets us escalate it and asks us to post on Q&A instead. The latest case summary also states that no troubleshooting was done, which is not the case.

Since the cause appears to be in the gateway's back end, which only Microsoft can see, we would appreciate it if someone from the Azure VPN Gateway team could look at the telemetry for this gateway at the stall times. We can share exact UTC stall times, the gateway diagnostic log export and 0.2 s ping logs privately.

Azure VPN Gateway
Azure VPN Gateway

An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.

0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 10,800 Reputation points
    2026-11-11T22:34:34.73+00:00

    Hi @Francis Morissette

    The evidence you collected is strong. The synchronized bidirectional delay, ESP replies arriving late from the Azure gateway, and the timer restarting when the active instance changes make an endpoint or ordinary Internet-path issue unlikely. That conclusion is based on your packet captures and failover test.

    The documented five-minute VPN behavior applies to idle policy-based gateways, where Azure tears down an idle tunnel and reestablishes it when traffic resumes. Your gateway is route-based, traffic is active, the connection remains Connected, and you observe latency rather than tunnel teardown. Therefore, that documented behavior doesn’t match this case.

    The documented timers don’t provide a clear match either:

    • The default DPD timeout is 45 seconds, although it can be configured between 9 and 3,600 seconds.
    • The default IPsec quick-mode SA lifetime is 27,000 seconds. While 300 seconds is the minimum configurable lifetime, you’re using the default Azure policy and have correlated the visible rekeys separately.

    The lack of matching log entries doesn’t disprove a gateway data-plane event. Microsoft describes these logs mainly as follows:

    • GatewayDiagnosticLog: configuration, primary-instance and maintenance events
    • TunnelDiagnosticLog: tunnel state changes
    • IKEDiagnosticLog: IKE control-plane messages
    • RouteDiagnosticLog: static-route and BGP changes

    A brief forwarding delay that doesn’t cause a tunnel, IKE, route, or instance-state change might not be represented by these categories. This is an inference from the documented log scope.

    Moving to Generation 2 or a larger SKU can’t be presented as a verified fix. Larger SKUs offer higher throughput and packet-per-second limits, but the documentation doesn’t state that they resolve periodic 300-second latency events. VpnGw1AZ is Generation 1; the Generation 2 AZ range begins with VpnGw2AZ.

    Given that the behavior follows the active gateway instance and survived a reset, Microsoft will need to correlate the exact UTC timestamps with internal gateway-host and data-plane telemetry. In support case 2611100040008419, request:

    1. Reopening or continued escalation to the Azure VPN Gateway engineering team.
    2. Correlation of several exact UTC stall intervals against both gateway instances.
    3. Confirmation of whether an internal five-minute health, telemetry, or route-processing task is occurring.
    4. A Microsoft-directed mitigation test, such as moving the gateway to different backend infrastructure or changing the SKU, before treating a production SKU upgrade as the solution.

    I don't recommend another gateway reset merely for diagnosis. Microsoft warns that resetting causes a connectivity interruption and can limit later root-cause analysis.

    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.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.