VPN Gateway: Traffic Drop Inside of S2S VPN — Investigation and Troubleshooting

Question

VPN Gateway: Traffic Drop Inside of S2S VPN — Investigation and Troubleshooting

Michael Schultz 10

I am not permitted to share this information outside of my company, and therefore need a support engineer. Please continue through secure channels.

Ganesh Patapati 12,175 Reputation points Microsoft External Staff Moderator

2026-10-25T19:40:33.08+00:00
Hello @Michael Schultz

Its sounds like you’re seeing site-to-site VPN “Connected” status, but traffic inside the tunnel drops (no response from Azure / no outbound from the gateway). That pattern is usually caused by routing/selector mismatches, NSG/UDR blocks on the GatewaySubnet, IP/subnet definition mismatches, or gateway health/behavior issues.

Here are the Azure VPN Gateway troubleshooting checks you can run (and that are commonly effective for “inbound but no outbound” / “inside tunnel no reply” scenarios):

Verify VPN peer IPs match exactly

Make sure the definitions on both sides are symmetric:

In Azure, the Local Network Gateway object IPs should match the on-prem VPN device IP.

On the on-premises VPN device, the Azure gateway IP configured there should match the actual Azure VPN gateway IP.

Check UDRs and NSGs on the GatewaySubnet

This is a top cause of “packets enter, but replies don’t make it back”.

Inspect the GatewaySubnet for any UDR (route table) or NSG associations.

If present, remove/temporarily disable them and retest.

If it resolves, validate the required rules/routes that those UDR/NSG introduced.

Confirm subnet address spaces match exactly

For Azure policy-based gateways especially, mismatched subnets can cause traffic selectors issues.

Verify the VNet address space(s) matches the on-prem expectations exactly.

Verify the on-prem subnet definitions (Local Network Gateway) match exactly.

If you see sporadic disconnects: check on-prem external interface IP usage

If the Internet-facing IP of the on-prem VPN device is included in the Local network definition in Azure, you can get sporadic disconnections.

If applicable, remove it from the Local network definition and retest.

Note: Basic SKU VPN gateways do not reply to health probe and aren’t recommended for production.

If the on-prem device has PFS enabled, disable it

Perfect Forward Secrecy (PFS) on the on-prem VPN device can cause disconnection problems:

Disable PFS on the on-prem device

Then update the Azure VPN Gateway IPsec policy accordingly

Collect/verify connection diagnostics in Azure (Tunnel/Route logs)

If you have access to diagnostics:

Enable VPN Gateway diagnostic logs (for example TunnelDiagnosticLog and RouteDiagnosticLog)

Then look specifically for symptoms around tunnel state/routing issues (common for “traffic in / no response out” patterns)

Reference docs

https://learn.microsoft.com/en-us/troubleshoot/azure/vpn-gateway/vpn-gateway-troubleshoot-site-to-site-disconnected-intermittently

Troubleshoot an Azure site-to-site VPN connection that can’t connect and stops working

https://learn.microsoft.com/en-us/answers/questions/2337378/vpn-gateway-is-not-replying-for-the-traffic-inside?page=0#answer-2291570

https://learn.microsoft.com/en-us/answers/questions/2262536/azure-vpn-gateway-connection-traffic-suddenly-stop?page=1&wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#answer-2028142

Kindly provide the necessary details in the private messages. The purpose of private messaging functionality is to allow Microsoft moderators to privately engage with question authors in scenarios where troubleshooting steps might contain PII (Personally identifiable information.)

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them
Michael Schultz 10 Reputation points

2026-10-25T22:17:47.27+00:00

This was resolved with the assistance of a Microsoft employee. This was caused by a separate, inactive VPN connection taking the route to a black hole, which took priority over the UDR defined.

3 answers

Your answer

Michael Schultz 10 Reputation points

2026-10-25T22:17:47.27+00:00

This was resolved with the assistance of a Microsoft employee. This was caused by a separate, inactive VPN connection taking the route to a black hole, which took priority over the UDR defined.

Answer 1

Michael Schultz 10

This was resolved with the assistance of a Microsoft employee. This was caused by a separate, inactive VPN connection taking the route to a black hole, which took priority over the UDR defined.

0 comments

Answer 2

Hi Michael Schultz & thx for join me at Q&A platform,

Understood. If your company's security policy doesn't allow sharing VPN configuration, network details, or diagnostic logs publicly, then Microsoft Q&A isn't the appropriate channel for investigating this issue.

I'd recommend opening a technical support request through the Azure portal under Help + Support > Create a support request, selecting Azure VPN Gateway and the affected subscription.

That will allow you to work directly with an assigned Microsoft support engineer rather than discussing sensitive infrastructure details in a public forum.

For a site-to-site VPN traffic-drop issue, the support engineer may need to review VPN Gateway diagnostic logs, IPsec/IKE events, tunnel metrics, routing information, and timestamps of the affected connections. These can be provided through the official support process, subject to your organization's security requirements.

Technical support requests normally require an eligible Azure support plan or an existing enterprise support agreement. If your organization already has one, your Azure administrator or designated support contact should be able to help initiate the case.

Please don't share confidential VPN configuration, internal IP addresses, or diagnostic captures here. Also, keep in mind that posting on Microsoft Q&A doesn't automatically create a private support ticket or assign an engineer.

If you already have a support case open, I'd continue through that case and request escalation to the Azure Networking team if the investigation isn't progressing.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Answer 3

Hello Michael,

Because the diagnostic information cannot be shared publicly, Microsoft Q&A cannot provide a secure channel or assign a support engineer. Please create an Azure technical support request at: https://portal.azure.com/#view/Microsoft_Azure_Support/NewSupportRequestV4Blade/assetId/

Select the affected subscription and use Technical > VPN Gateway > Site-to-site VPN or connectivity, with severity based on production impact.

Upload sensitive material only through the private support case. Include:

VPN Gateway and connection resource IDs.
Exact failure timestamps and time zone.
Azure and on-premises address spaces.
Local Network Gateway configuration.
IKE/IPsec policy, traffic selectors, and PFS settings.
BGP and relevant route tables.
GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, and IKEDiagnosticLog.
On-premises VPN-device logs and packet captures from both sides.
Relevant NSGs and user-defined routes.
Whether resetting the connection or gateway temporarily restores traffic.

Before opening the case, verify symmetrical address spaces and traffic selectors and check for overlapping address spaces or return traffic directed incorrectly by a UDR. Do not post these details publicly if company policy prohibits it.

Documentation:

A paid Azure support plan may be required for technical troubleshooting; billing support alone cannot perform the network-level investigation.