Azure VPN Gateway Not Working, Connectivity, Rules, and Routing Fixes

You can't fix what you can't see. If you're running into Azure VPN Gateway connectivity issues and you don't have diagnostic logs enabled, you're essentially flying blind. This step is non-negotiable, and it takes about 3 minutes to set up.

First, you need a Log Analytics workspace. If you don't have one already:

1. In the Azure portal, search for Log Analytics workspaces.
2. Click + Create, choose your subscription and resource group, and give it a name like vpn-diagnostics-workspace.
3. Select the same region as your VPN gateway, this matters for latency and data residency.
4. Click Review + Create, then Create.

Now attach the workspace to your VPN gateway:

1. Navigate to your Virtual Network Gateway in the portal.
2. In the left blade, under Monitoring, click Diagnostic settings.
3. Click + Add diagnostic setting.
4. Give it a name. Then check all five log categories: GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, IKEDiagnosticLog, and P2SDiagnosticLog.
5. Under Destination details, check Send to Log Analytics workspace and select the workspace you just created.
6. Click Save.

One important caveat: if you're using a policy-based VPN gateway (as opposed to route-based), only the GatewayDiagnosticLog and RouteDiagnosticLog will be available to you. The IKE and Tunnel logs are route-based gateway features.

New log data starts flowing within a few minutes of the first event. Historical data before you enabled the setting is not available retroactively, another reason to set this up before you have a crisis, not during one.

When it's working correctly, you'll see data appearing in your workspace under Logs. Run AzureDiagnostics | take 10 in the query editor to confirm data is flowing.

The GatewayDiagnosticLog is your audit trail. Every time someone modifies the VPN gateway configuration, or Azure performs a maintenance update, an entry lands here. I've seen more than one outage traced back to a teammate who made a "quick change" to the Local Network Gateway address space at the worst possible time.

Open your Log Analytics workspace, click Logs, and run this query:

AzureDiagnostics
| where Category == "GatewayDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
| sort by TimeGenerated asc

The columns you care about most:

• TimeGenerated: UTC timestamp of the event. Always convert to your local timezone when correlating with user-reported issues.
• OperationName: This tells you what actually happened. The key values to watch for are SetGatewayConfiguration (the gateway itself was modified), SetConnectionConfiguration (a connection or Local Network Gateway was changed), HostMaintenanceEvent (Azure did planned maintenance), and GatewayResourceMove (the gateway was moved, which is rare but disruptive).
• Message: The detailed result, whether the operation succeeded or failed, and any specifics.

Here's the diagnostic move that saves a ton of time: cross-reference your GatewayDiagnosticLog timestamps with your TunnelDiagnosticLog. If you see a SetGatewayConfiguration event at 14:32 UTC and a TunnelDisconnected event at 14:33 UTC, that's not a coincidence, the configuration change caused the drop. This correlation is exactly what Microsoft's documentation recommends as the first step when investigating tunnel failures during change windows.

Keep in mind: there can be a few minutes of delay between when a change is made and when it appears in the log. If you're looking for a change that happened "just now," give it 5–10 minutes before concluding nothing was changed.

If the GatewayDiagnosticLog shows no configuration changes around the time of the outage, move to the TunnelDiagnosticLog, the issue is likely infrastructure-side or IPsec-related.

The TunnelDiagnosticLog is the most useful table for understanding Azure VPN tunnel disconnection problems. It's lightweight, meaning you can query across days or even weeks of data quickly, and it tells you exactly when tunnels went up and down, from which gateway instance, and to which remote IP.

Run this query to see your tunnel history:

AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc

If you have multiple tunnels (multiple on-premises sites), filter by the specific remote IP to reduce noise:

AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
| where remoteIP_s == "203.0.113.45"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc

Here's how to interpret what you see in the instance_s column. Your VPN gateway has two instances: GatewayTenantWorker_IN_0 and GatewayTenantWorker_IN_1. These are the two redundant gateway instances that Azure runs for you automatically.

Three patterns to recognize:

• Disconnect on IN_0, reconnect on IN_1 within a few seconds: Gateway failover. Azure was doing maintenance on one instance and traffic moved to the other. This is normal and expected, but if your on-premises VPN device takes too long to detect the failover and reconnect, you get an extended outage. The fix here is tuning your DPD settings on the on-premises device.
• Disconnect and reconnect on the same instance within a few seconds: Network glitch or a DPD timeout triggered by the on-premises device. Check whether the on-premises device sent a delete notification or if the tunnel just timed out.
• Disconnect with no reconnection: The tunnel came down and never came back up. This points to an IKE negotiation failure on reconnect, move to the IKEDiagnosticLog next.

When you find the timestamps of disconnection events here, note them down. You'll use them to query the IKEDiagnosticLog at exactly those moments for the detailed root cause.

This is where the real diagnostic horsepower lives. The IKEDiagnosticLog captures detailed IPsec logging, Phase 1 and Phase 2 IKE negotiations, proposed and accepted cipher suites, SA lifetimes, and failure reasons. If your Azure VPN Gateway tunnel keeps dropping or won't connect at all, this log will tell you exactly why.

Query the IKE log around the timestamp you found in TunnelDiagnosticLog:

AzureDiagnostics
| where Category == "IKEDiagnosticLog"
| where TimeGenerated between (datetime("2026-04-20T14:30:00Z") .. datetime("2026-04-20T14:45:00Z"))
| project TimeGenerated, OperationName, Message, Resource
| sort by TimeGenerated asc

The most common failure messages you'll encounter and what they mean:

• "No proposal chosen", This is the #1 cause of persistent Azure site-to-site VPN connection failures. Your on-premises device and Azure are proposing incompatible encryption algorithms. Azure's default IKEv2 policy supports AES-256, SHA-256, DH Group 2 for Phase 1, and AES-256, SHA-256, PFS Group 2 for Phase 2. If your firewall is proposing something different, say 3DES or MD5, the negotiation fails here, every time.
• "Authentication failed", In certificate-based setups, this usually means a cert mismatch. In PSK (pre-shared key) setups, it means the keys on both sides don't match. Go back to your Local Network Gateway in Azure and verify the shared key under Connections > [your connection] > Shared key, then compare it byte-for-byte with what's configured on the on-premises device.
• "IKE SA deleted" followed quickly by a new negotiation attempt, This is normal rekey behavior. If you see it happening every few minutes, it suggests an SA lifetime mismatch. Azure defaults to 27,000 seconds for Phase 1 and 27,000 seconds for Phase 2. If your on-premises device is set to a much shorter value, you'll see constant renegotiation.

To fix an IKE policy mismatch, navigate in the portal to your VPN connection, then under Settings find Configuration. You can enable a custom IPsec/IKE policy here and specify exact values to match your on-premises device. This is far more reliable than trying to get your firewall vendor to match Azure's defaults.

After any IKE policy change, reset the VPN connection (not the whole gateway) by going to the connection and clicking Reset in the connection overview blade. Give it 2–3 minutes to re-establish.

If your tunnel is up, you can confirm this in TunnelDiagnosticLog, but traffic still isn't flowing between specific subnets, the problem is almost always routing. Either Azure isn't learning your on-premises routes, or your on-premises device isn't learning Azure's address space, or there's a route conflict somewhere in the middle.

The RouteDiagnosticLog traces all routing activity: static route additions and removals, BGP session events, and route updates. Run this query:

AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
| sort by TimeGenerated asc

The OperationName values tell you what's happening:

• BgpConnectedEvent / BgpDisconnectedEvent: Your BGP peer session is coming up and going down. Frequent flapping here points to a BGP timer mismatch or an unreachable BGP peer IP.
• BgpRouteUpdate: Routes are being advertised or withdrawn. Check the Message field for which prefixes are being exchanged, if your on-premises 192.168.10.0/24 isn't showing up here, Azure won't know how to route to it.
• StaticRouteUpdate: A static route was added or removed on the gateway. If you're using BGP, unexpected StaticRouteUpdate events can indicate someone manually added a static route that's conflicting with your BGP-learned routes.

Three routing fixes that resolve the majority of Azure VPN routing problems:

1. Verify the Local Network Gateway address space: Navigate to Local Network Gateways, select yours, and check Address space. Every on-premises subnet you want to reach must be listed here. Missing a subnet? Add it and save, the tunnel will briefly renegotiate, then traffic to that subnet will start flowing.
2. Check for overlapping address spaces: Azure Virtual Networks cannot overlap with each other or with your on-premises ranges. If your Azure VNet uses 10.1.0.0/16 and your on-premises network also uses 10.1.0.0/16, routing will be completely broken and Azure won't tell you why in any obvious error. Use the Effective Routes blade on a VM's network interface to see what routes Azure is actually using.
3. BGP peer IP reachability: If you're running BGP (which I strongly recommend over static routes for any production Azure VPN setup), the BGP peer IPs on both sides must be reachable through the tunnel. Azure's BGP peer IP for a VPN gateway is visible in the gateway's Configuration blade under BGP settings. Make sure your on-premises BGP session is targeting that IP, not the gateway's public IP.

After any Local Network Gateway change or BGP configuration adjustment, allow 5–10 minutes for routes to propagate before testing again. Use the Effective Routes feature on a test VM in Azure to confirm the on-premises routes are visible before you do any ping testing.