Edit

Troubleshoot Azure Site-to-Site VPN disconnections

Summary

Azure Site-to-Site VPN disconnections can disrupt connectivity for new or existing connections. This article helps you identify common configuration causes and restore a stable VPN connection.

Troubleshooting steps

Prerequisites

Check the type of Azure virtual network gateway:

  1. Go to Azure portal.
  2. Check the Overview page of the virtual network gateway to verify the Type. For example: Route-based.

Step 1: Check whether the on-premises VPN device is validated

  1. Check whether you are using a validated VPN device and operating system version. If the VPN device is not validated, you may have to contact the device manufacturer to see if there is any compatibility issue.
  2. Make sure that the VPN device is correctly configured. For more information, see Editing device configuration samples.

Step 2: Check the Security Association settings (for policy-based Azure virtual network gateways)

  1. Make sure that the virtual network, subnets and, ranges in the Local network gateway definition in Microsoft Azure are same as the configuration on the on-premises VPN device.
  2. Verify that the Security Association settings match.

Step 3: Check for user-defined routes or network security groups on gateway subnet

A user-defined route on the gateway subnet might restrict some traffic while allowing other traffic. This condition makes the VPN connection seem unreliable for some traffic but good for other traffic.

Step 4: Check the one VPN tunnel per subnet pair setting (for policy-based virtual network gateways)

Ensure that the on-premises VPN device is set to use one VPN tunnel per subnet pair for policy-based virtual network gateways.

Step 5: Check for security association limitations

The virtual network gateway has a limit of 200 subnet Security Association pairs. If the number of Azure virtual network subnets multiplied by the number of local subnets exceeds 200, you might see sporadic subnet disconnections.

Step 6: Check the on-premises VPN device external interface address

If you include the internet-facing IP address of the VPN device in the Local network gateway address space definition in Azure, you might experience sporadic disconnections.

Step 7: Check whether the on-premises VPN device has Perfect Forward Secrecy enabled

The PFS group is the Diffie-Hellman group used for IPsec Quick Mode (Phase 2). When you use a custom IPsec/IKE policy, the on-premises VPN device configuration must match or contain the PFS group configured on the Azure connection.

  1. Check the PFS group configured on the Azure connection.

    Azure CLI

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

    Azure PowerShell

    $connection = Get-AzVirtualNetworkGatewayConnection -ResourceGroupName "<resource-group>" -Name "<connection-name>"
$connection.IpsecPolicies | Select-Object PfsGroup

  2. Check the PFS or Phase 2 Diffie-Hellman group configured on the on-premises VPN device. Use the device vendor's documentation for the exact command or interface.

  3. If the settings differ, update one peer so the PFS groups match. An Azure custom policy must specify all IKE and IPsec algorithms and parameters, so use the Azure portal procedure or the Azure PowerShell procedure to apply the complete policy. If PFS is disabled on the peer, select None for the Azure PFS group; otherwise, select the corresponding supported group. Updating a custom policy can briefly restart the tunnel, so plan the change for a maintenance window or other low-traffic period.

  4. To correlate a disconnect with configuration activity, review TunnelDiagnosticLog for tunnel state changes and GatewayDiagnosticLog for configuration events. Compare the TimeGenerated values, which are in UTC, around the same time. For setup and query examples, see Troubleshoot Azure VPN Gateway using diagnostic logs.

  5. After both peers use matching settings, verify the connection state:

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

Step 8: Check for overlapping address spaces across connections

If traffic to specific prefixes drops intermittently, compare the address prefixes configured on each associated local network gateway. Overlapping prefixes on different connections can cause traffic to use an unintended route. If you don't configure NAT on the VPN gateway, the overlapping prefixes can disrupt traffic.

  1. List the VPN connections and the address prefixes on each associated local network gateway.

    Azure PowerShell

    $gateway = Get-AzVirtualNetworkGateway `
    -ResourceGroupName "<resource-group>" `
    -Name "<virtual-network-gateway-name>"
$connections = Get-AzVirtualNetworkGatewayConnection -ResourceGroupName "<resource-group>" |
    Where-Object {
        $_.VirtualNetworkGateway1.Id -eq $gateway.Id -and $_.LocalNetworkGateway2
    }

$connections | ForEach-Object {
    $localGatewayId = $_.LocalNetworkGateway2.Id -split "/"
    $localGateway = Get-AzLocalNetworkGateway `
        -ResourceGroupName $localGatewayId[4] `
        -Name $localGatewayId[-1]

    [PSCustomObject]@{
        Connection          = $_.Name
        LocalNetworkGateway = $localGateway.Name
        AddressPrefixes     = $localGateway.LocalNetworkAddressSpace.AddressPrefixes -join ", "
    }
} | Format-Table

  2. Compare the AddressPrefixes values in the output. Look for identical or overlapping CIDR ranges on different connections.

  3. In the Azure portal, open the virtual network gateway, and then select Connections. Open each connection and identify its associated local network gateway. Open each local network gateway, select Configuration, and then compare the prefixes under Address space.

  4. Resolve each overlapping prefix based on its configuration:

    • If the prefix is assigned to the wrong site, remove it from that site's local network gateway. Configure all prefixes for a site on the local network gateway resource that represents the site's VPN device. For instructions, see Modify IP address prefixes.
    • For separate sites, use a distinct local network gateway and connection for each site. If the sites intentionally use overlapping address spaces, configure NAT on each connection so that the external mappings don't overlap. Azure VPN Gateway supports NAT for IPsec/IKE cross-premises connections on route-based VpnGw2 to VpnGw5 and VpnGw2AZ to VpnGw5AZ gateway SKUs. Policy-based VPNs and connections that have Use Policy Based Traffic Selectors enabled don't support NAT rules. For more information, see About NAT on Azure VPN Gateway.
    • If multiple connections intentionally provide redundant paths to the same on-premises network, don't remove matching prefixes. This topology uses a distinct local network gateway for each VPN device and requires Border Gateway Protocol (BGP) and equal-cost multipath (ECMP) routing. For more information, see Multiple on-premises VPN devices.

Correlate disconnects with Azure Service Health

After you identify the disconnect time in TunnelDiagnosticLog, check Azure Service Health for service issues or planned maintenance in your subscription and region at that time. A related Service Health notification provides context for your investigation, but timing alone doesn't confirm the cause. For guidance on identifying disconnect and failover events, see Troubleshoot Azure VPN Gateway using diagnostic logs.

Next steps

  • Last updated on