Azure VPN Gateway: the site-to-site tunnel is up but traffic does not pass

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Connected tells you the two gateways authenticated and agreed keys. It does not tell you that either side has a route, that the encrypted domain covers your subnets, or that a full-sized packet fits through. In our reading, those three are the first places to look when a tunnel is up but dead.

Work from the Azure route table outward: confirm the workload's next hop, confirm what the gateway knows, compare traffic selectors, inspect the gateway subnet, then test packet size. Capture only after those checks. Do not reset the gateway first, because a reset causes a gap in connectivity and might limit later root cause analysis.

The commands come from Microsoft's published reference and were not run in a lab for this article.

Why it matters

A tunnel that is up but passes nothing is hard to escalate, because each team can show a green status. The on-premises firewall shows an established security association. Azure shows Connected. The application still times out.

A partial failure is harder still. Some subnets work and others do not, or small requests work while file copies hang. Those symptoms point to specific causes, so write down exactly what works and what does not before changing anything.

How the tunnel and the data path differ

Three separate things must be right.

The control plane. IKE (the key exchange protocol) authenticates the peers and builds security associations. This is what the Connected status reflects.

The encryption domain. Each security association covers a set of source and destination ranges, called traffic selectors. A packet outside those ranges is not carried by that association.

Routing. Azure must send the packet to the gateway. The on-premises network must send replies to its VPN device.

Route-based and policy-based behaviour

A route-based gateway forwards anything routed to it, and it normally negotiates a broad selector. A policy-based gateway ties each subnet pair to the tunnel.

Since 1 October 2023, policy-based gateways cannot be created in the portal, but older ones remain. They support IKEv1 only and the Basic SKU, and you cannot convert one to route-based. Replacing one means deleting and re-creating the gateway, which Microsoft says takes about 60 minutes and does not keep the gateway's IP address.

Check the type first, on the gateway's Overview page. The rest of the diagnosis depends on it.

The check order

1. Confirm the status from both ends

az network vpn-connection show \
  --resource-group <rg> --name <connection-name> \
  --query connectionStatus --output tsv

Then record the on-premises device's view of its IKE and IPsec security associations. Note whether the IPsec packet counters climb in both directions while you generate traffic. Counters rising only outbound on the device mean replies are not arriving. The direction is your first clue.

2. Confirm Azure sends the packet to the gateway

From a VM in the affected subnet:

az network watcher show-next-hop \
  --resource-group <rg> --vm <vm-name> \
  --source-ip <vm-ip> --dest-ip <on-prem-ip>

You want VirtualNetworkGateway. Other results have direct meanings:

• None means the traffic is dropped. A UDR can do this. So can a missing route to a private range, because Azure's default routes send 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 to None.
• VirtualAppliance means a user-defined route (UDR) sends it to a firewall first.
• Internet appears when only the default 0.0.0.0/0 route matches. For an on-premises range, that means a public range outside those None blocks with no gateway route (our reasoning from Microsoft's route table).

Spokes need extra attention. A spoke reaches the hub's gateway only with Allow gateway transit on the hub side and Use remote gateways on the spoke side. A route table with gateway route propagation disabled also removes these routes from that subnet, including static ones.

3. Confirm what the gateway itself knows

For a static connection, the local network gateway's prefixes are the only record Azure has of the remote side. A missing subnet there means no route.

For BGP, query the gateway:

az network vnet-gateway list-bgp-peer-status \
  --resource-group <rg> --name <gateway-name> --output table

az network vnet-gateway list-learned-routes \
  --resource-group <rg> --name <gateway-name> --output table

az network vnet-gateway list-advertised-routes \
  --resource-group <rg> --name <gateway-name> --peer <bgp-peer-ip> --output table

The advertised list is the one people skip. If on-premises has no return route, the tunnel looks fine and every packet dies on the way back.

BGP has its own conditions. Azure assigns ASN 65515 to a VPN gateway by default, and the on-premises peer cannot reuse it. If the device peers from an APIPA address, the custom Azure address must be in 169.254.21.0 to 169.254.22.255, and Azure does not initiate the session. The device has to open it. If the session never establishes while IPsec is up, check these two conditions first.

With BGP, the local network gateway needs only a host prefix for the peer address. A leftover list of real subnets is unnecessary, so review it during changes.

4. Compare the traffic selectors

This is the classic cause when one subnet pair works and another does not.

If a route-based connection faces a policy-based firewall, Azure offers the UsePolicyBasedTrafficSelectors connection option. The device must then define every combination of on-premises prefixes and virtual network prefixes, not any-to-any.

With two on-premises ranges and two Azure ranges, that is four pairs. Microsoft's own example:

10.1.0.0/16 <====> 192.168.0.0/16
10.1.0.0/16 <====> 172.16.0.0/16
10.2.0.0/16 <====> 192.168.0.0/16
10.2.0.0/16 <====> 172.16.0.0/16

Selectors set through the connection's trafficSelectorPolicies attribute are proposed only when the Azure gateway initiates, and Azure accepts what a remote device proposes. So the same configuration can behave differently depending on which side brought the tunnel up. Our inference is that this could explain a fault appearing after a rekey or a device restart. Microsoft does not say so.

For policy-based gateways, Microsoft asks you to check two more things: the address ranges match exactly on both sides, and the device uses one tunnel per subnet pair.

The same page gives a limit that it does not tie to either gateway type: 200 subnet security association pairs. That count is Azure subnets multiplied by local subnets, and exceeding it can produce sporadic subnet disconnections.

To see what was actually negotiated on a route-based gateway, read the IKE log. Send gateway diagnostics to a Log Analytics workspace first.

AzureDiagnostics
| where Category == "IKEDiagnosticLog"
| extend Message1=Message
| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2
| extend Event = iif(Message has "SESSION_ID",Message2,Message1)
| project TimeGenerated, RemoteIP, LocalIP, Event, Level
| sort by TimeGenerated asc

That query is Microsoft's published form. Search the output for Traffic Selector. The log samples show both what was received and what was finally negotiated, with start and end addresses.

Policy-based gateways write only GatewayDiagnosticLog and RouteDiagnosticLog, so this log will not exist for them.

5. Inspect the gateway subnet

Microsoft is explicit: UDRs with a 0.0.0.0/0 destination and network security groups on the gateway subnet are not supported. A UDR overlapping the gateway subnet or gateway public IP can also affect diagnostics, data path and control path. BGP route propagation must also stay enabled there.

A UDR on that subnet can restrict some traffic while allowing other traffic, which reads as an unreliable tunnel. Also confirm nothing else has been deployed into the subnet.

6. Look for overlaps and self-reference

Azure does not allow overlapping ranges between connected virtual networks and on-premises sites. Microsoft also warns that overlapping prefixes on different connections can send traffic down an unintended route unless NAT is configured on the gateway.

A quieter mistake is including the VPN device's own public address inside the local network gateway's prefixes, which causes sporadic disconnections.

7. Test packet size

If small things work and large things hang, suspect size first. SSH logs in but stalls on a large listing, a web page loads partly, or a file copy starts and freezes.

Encryption adds overhead, and Microsoft states that IP fragmentation is not supported for ESP packets or for packets encapsulated in a site-to-site tunnel.

The gateway clamps TCP maximum segment size bidirectionally. The published values are 1360 bytes over the internet for IPv4 and 1340 bytes for IPv6, and 1250 bytes for both when the path crosses an ExpressRoute gateway.

MSS clamping only helps TCP. UDP-based applications and anything that sets its own packet size can still exceed the limit, so set the sender or device accordingly.

To test from the on-premises side, send a don't-fragment ping to a VM in Azure and step the payload down until it passes. On Windows that is ping -f -l <size> <vm-ip>, and on Linux ping -M do -s <size> <vm-ip>. Both sizes are payload. An IPv4 ping packet is 28 bytes larger, made up of 8 bytes of ICMP header and a basic 20-byte IPv4 header, which describes the ICMP probe packet, not TCP MSS. MSS is TCP payload size; do not compare the ping payload or its total packet size directly with an MSS value without accounting for the different protocol headers. Do not target the gateway. VPN gateways do not reply to ICMP on their local address. Allow ICMP at the VM's guest firewall and network security group, or the test proves nothing.

8. Use the built-in health checks

Network Watcher's VPN troubleshoot, run with az network watcher troubleshooting start, writes logs to a storage account. It classifies faults such as preshared key mismatch and IkePolicyMismatch. If the result is healthy, the zip holds only ConnectionStats.txt, which shows connectivity state and ingress and egress bytes since connection. A byte count of zero in one direction tells you which side to investigate. Microsoft allows only one VPN troubleshoot operation at a time per subscription, and with Azure CLI the gateway and storage account must be in the same resource group.

Microsoft also documents a gateway health probe at https://<gateway-public-ip>:8081/healthprobe, and port 8083 for the second address of an active-active gateway. Basic SKU gateways do not answer it.

9. Capture on the gateway

Azure VPN Gateway has its own packet capture, run per gateway or per connection, with IKE, ESP and inner packets available. Use a five-tuple filter on a busy tunnel. Only one filter applies at a time, and a maximum of five captures can run in parallel per gateway.

Start-AzVirtualNetworkGatewayConnectionPacketCapture `
  -ResourceGroupName "<rg>" -Name "<connection-name>"

Stop-AzVirtualNetworkGatewayConnectionPacketCapture `
  -ResourceGroupName "<rg>" -Name "<connection-name>" -SasUrl "<sas-url>"

The stop command needs a storage SAS URL, and a badly formed URL makes the trace fail. Treat the URL as a secret. A capture can include inner packets, so handle the file as sensitive data.

Read the capture by question. Do inner packets arrive from on-premises? Do replies leave toward the tunnel? A packet going in with no reply coming out sends you back to the workload's route, network security group or guest firewall.

What to choose and why

These are editorial recommendations.

If you are running a policy-based gateway and are fighting selector limits, plan a replacement. Allow for the new public IP and update the on-premises device.

A note on conflicting guidance

Microsoft's "can't connect" page (content date 31 March 2025 in its metadata) says perfect forward secrecy can cause disconnection problems and tells you to disable it. Its September 2026 troubleshooting page says something different: when you use a custom IPsec/IKE policy, the device must match or contain the PFS group configured on the Azure connection.

Where a custom policy exists, follow the newer guidance and compare the two values, rather than weakening the device's configuration. Without a custom policy the command below has nothing to compare, and that page does not address the case.

az network vpn-connection ipsec-policy list \
  --resource-group <rg> --connection-name <connection-name> \
  --query "[].pfsGroup" --output tsv

A custom policy must specify all IKE and IPsec parameters, and changing it can briefly restart the tunnel. Use a maintenance window.

Risks and limits

Warning: a gateway reset reboots the active instance immediately and interrupts connectivity. Removing a network security group or UDR from the gateway subnet changes the live data path. Plan both as changes.

• Resetting a single connection, which does not reboot the gateway, is the smaller step. Microsoft asks you to verify configuration items first, because any mismatch would disconnect the tunnel again anyway.
• A reset keeps the public IP, so the device does not need reconfiguring.
• The timestamps in diagnostic logs are in UTC. Convert your on-premises log times before comparing them.
• Diagnostic logs must be enabled before the fault to give you history.
• These commands were not lab tested for this article.

Sources

Opened 9 November 2026. Sources behind the corrections reopened 10 November 2026.

• Troubleshoot a site-to-site VPN that can't connect
• Troubleshoot intermittent site-to-site disconnections
• About VPN Gateway settings
• About VPN devices and IPsec/IKE parameters
• Cryptographic requirements and custom IPsec/IKE policy
• VPN Gateway FAQ
• Troubleshoot VPN Gateway using diagnostic logs
• Network Watcher VPN troubleshoot overview
• Configure packet capture for VPN gateways
• Reset a VPN gateway or connection
• About BGP and VPN Gateway
• Configure BGP for VPN Gateway
• Virtual network traffic routing
• az network vnet-gateway reference
• Windows ping reference
• Linux ping(8) manual

This article was originally published on 10 November 2026.