Azure VPN Gateway Troubleshooting: Fix Connection Issues Fast

You can't fix what you can't see. The first real troubleshooting step is turning on diagnostic logging if it isn't already enabled, and surprisingly, many teams run Azure VPN Gateways in production without it.

In the Azure Portal, go to your Virtual Network Gateway → Monitoring → Diagnostic settings. Click Add diagnostic setting. Give it a name like vpn-diag-logs, then check all of the following log categories:

• GatewayDiagnosticLog, gateway operational events, IKE negotiation details
• TunnelDiagnosticLog, tunnel connect/disconnect events with reason codes
• RouteDiagnosticLog, BGP route advertisements and withdrawals
• IKEDiagnosticLog, raw IKE message exchanges (very verbose, essential for mismatch diagnosis)
• P2SDiagnosticLog, if you're also running point-to-site VPN

Send these to a Log Analytics Workspace. Then run this Kusto query to see what happened around your failure window:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where Category == "TunnelDiagnosticLog"
| where TimeGenerated between (datetime("2026-04-20 08:00:00") .. datetime("2026-04-20 09:00:00"))
| project TimeGenerated, operationName_s, status_s, subCategory_s, message_s
| order by TimeGenerated asc

Look for status_s == "Failed" entries. The message_s field will contain strings like "IKE authentication credentials are unacceptable" (shared key mismatch), "No proposal chosen" (algorithm mismatch), or "Dead Peer Detection timeout" (network path issue or idle timeout on on-premises device). Those strings tell you exactly which step below to focus on.

If you see the tunnel came up successfully and then dropped after exactly 28,800 seconds (8 hours), that's an IKE Phase 1 lifetime rekey failure, common when one side doesn't support rekey and the session simply expires.

This step resolves a massive proportion of Azure site-to-site VPN not connecting issues. Both sides of the tunnel must agree on the exact same cryptographic parameters. Azure is pickier than most people expect.

First, check the shared key. In the Portal, go to your connection resource (not the gateway, the Connection object) → Authentication type → Shared Key → click the eye icon to reveal it. Copy it. Now log into your on-premises VPN device and confirm it matches character for character. Watch for leading/trailing spaces, which get silently pasted in from documentation.

Next, check your IPsec policy. If you're using a custom policy (rather than the Azure default), navigate to your Connection → Configuration → IPsec/IKE policy. To view or set it via PowerShell:

$connection = Get-AzVirtualNetworkGatewayConnection `
  -Name "your-connection-name" `
  -ResourceGroupName "your-rg-name"

$connection.IpsecPolicies

The output shows your DH group, IKE encryption, IKE integrity, IPsec encryption, IPsec integrity, PFS group, and SA lifetime values. Take this list and compare it line-by-line against your on-premises device's Phase 1 and Phase 2 configuration. Every single value must match. Azure supports IKEv2 by default, if your on-premises device is configured for IKEv1 only, that's an immediate failure. Check your Connection's IKE Protocol setting and align it.

Common mismatches I see constantly: Azure configured for DHGroup2 while the on-premises Cisco ASA is set to group5. Or Azure using GCMAES256 for IPsec encryption while a Palo Alto is configured for AES-256-CBC. They're both AES-256, but they're not the same algorithm and the negotiation will silently fail.

If you set a matching custom policy on both sides and the tunnel comes up, you've found the problem. If you're unsure which algorithms your on-premises device supports, temporarily set the Azure connection to Default policy, this tells Azure to accept any algorithm the remote side proposes, which helps isolate whether a policy mismatch is the root cause.

The tunnel can be fully up, IKE negotiated, IPsec established, and still pass zero traffic. When that happens, the culprit is almost always routing. This is the scenario that makes people think Azure VPN is broken when the networking team has actually introduced an IP conflict.

In the Azure Portal, open your Virtual Network → Address space and note every CIDR block. Now open the Local Network Gateway associated with your connection and look at the Address space field there, this is supposed to represent your on-premises subnets. These two sets of address ranges must not overlap, even partially. A 10.0.0.0/8 in Azure and a 10.1.0.0/16 on-premises? That's a full overlap from Azure's routing perspective.

Run this to check effective routes on an Azure VM that should be routing through the tunnel:

Get-AzEffectiveRouteTable `
  -ResourceGroupName "your-rg-name" `
  -NetworkInterfaceName "your-vm-nic-name" `
  | Format-Table -AutoSize

Look for routes with NextHopType: VirtualNetworkGateway pointing to your on-premises subnets. If those routes are missing, Azure isn't sending traffic toward the tunnel at all. This happens when the Local Network Gateway address spaces aren't correctly defined, or when User Defined Routes (UDRs) on your subnet are overriding the gateway-propagated routes.

Check your subnet's route table: Virtual Network → Subnets → click the subnet → Route table. If a UDR sends 0.0.0.0/0 to a firewall NVA, you need an explicit route for your on-premises CIDR pointing to the VPN Gateway. Also verify that Gateway route propagation is set to Enabled on your subnet's route table, disabling it is a common accident that kills VPN routing.

On your on-premises device, also verify that static routes or BGP advertisements point your Azure Virtual Network address space toward the VPN tunnel interface, not the default internet route.

If you're running BGP over your Azure VPN Gateway, which you absolutely should be for production workloads, BGP peering failures are a distinct failure mode from tunnel failures. The IPsec tunnel can be up while BGP is down, meaning no routes are being exchanged and traffic still doesn't flow.

Check BGP status with PowerShell:

$gateway = Get-AzVirtualNetworkGateway `
  -Name "your-gateway-name" `
  -ResourceGroupName "your-rg-name"

# Check BGP peer status
Get-AzVirtualNetworkGatewayBGPPeerStatus `
  -VirtualNetworkGateway $gateway

The output shows each BGP peer's State (should be Connected), Neighbor IP, LocalAddress, and Routes Received. If State shows Idle or Active (rather than Connected), BGP peering is failing.

The most common BGP misconfiguration: wrong ASN. Azure VPN Gateway uses its configured BGP ASN (find it under your gateway's Configuration blade). Your on-premises device's BGP configuration must list this exact ASN as the remote peer ASN. I've seen teams configure 65515 on Azure and 65000 on-premises, expecting Azure to be the "remote" side, they're setting up the peer relationship backwards.

Also verify the BGP peer IP addresses. For a standard VPN gateway, Azure's BGP peer IP is visible in the gateway's Configuration tab as the BGP peer IP address, it's always within the GatewaySubnet. Your on-premises device must be configured to peer with exactly this IP. For active-active gateways, there are two BGP peer IPs (one per gateway instance) and you must configure both peers on your on-premises device.

Check the advertised routes to confirm Azure is actually sending your VNet prefixes:

Get-AzVirtualNetworkGatewayAdvertisedRoute `
  -VirtualNetworkGateway $gateway `
  -Peer "your-on-premises-bgp-ip"

If this returns nothing, Azure isn't advertising routes to your peer, investigate whether your VNet address space is properly associated with the gateway and whether BGP is enabled on the connection object itself.

When the tunnel shows "Connected" in the portal but actual application traffic isn't flowing, you need packet-level visibility. Azure Network Watcher provides a built-in packet capture that runs directly on your gateway, no agent installation needed.

Start a packet capture on the gateway using the Azure Network Watcher VPN diagnostic:

$storageAccount = Get-AzStorageAccount `
  -ResourceGroupName "your-rg-name" `
  -Name "yourstorageaccount"

$sasUrl = New-AzStorageAccountSASToken `
  -Service Blob `
  -ResourceType Container,Object `
  -Permission "racw" `
  -ExpiryTime (Get-Date).AddHours(2) `
  -Context $storageAccount.Context

# Start VPN troubleshoot (captures packets and analyzes)
Start-AzVirtualNetworkGatewayConnectionVpnDeviceConfigScript `
  -ResourceGroupName "your-rg-name" `
  -Name "your-connection-name" `
  -DeviceVendor "Cisco" `
  -DeviceFamily "ASA" `
  -FirmwareVersion "8.4"

For direct packet capture, use Network Watcher's Packet capture feature on a VM in the VNet. Send a ping from an on-premises host to the Azure VM's private IP, and simultaneously run a packet capture filtered to that IP. If you see ICMP echo requests arriving at the Azure VM but no replies, the issue is the Azure VM's OS firewall (Windows Firewall, or a Linux iptables rule) blocking ICMP, not the VPN tunnel.

Use the IP flow verify tool in Network Watcher to quickly test whether Azure's Network Security Groups (NSGs) are blocking traffic: Network Watcher → IP flow verify. Enter the VM, NIC, direction (Inbound), source IP (your on-premises host), destination port, and protocol. It'll tell you immediately if an NSG rule is dropping packets before they reach your application.

Also check your GatewaySubnet, it must not have an NSG attached. Applying an NSG to the GatewaySubnet is explicitly unsupported and will cause erratic VPN behavior. If you see an NSG on that subnet, remove it. This alone has unblocked dozens of troubled deployments I've worked on.