Azure site-to-site VPN with a branch firewall: setup and troubleshooting

To connect an office firewall to Azure over IPsec, create a route-based VPN gateway in a GatewaySubnet of the hub virtual network, create a local network gateway that holds the firewall's public IP and the office address ranges, then create a site-to-site connection with a shared key and IKEv2. On the firewall, build a route-based (VTI) tunnel to each Azure gateway public IP with matching phase 1 and phase 2 settings. When a tunnel won't come up, check the shared key, peer IPs, crypto proposals and the GatewaySubnet, in that order, and read the gateway's IKE diagnostic log.

Who this is for and what you will have

This guide is for network and cloud administrators connecting a branch or head office firewall to an Azure virtual network for the first time, or rescuing a tunnel that stopped working. It assumes one office and one Azure region; the same steps repeat for each additional site. At the end you will have:

• A route-based, zone-redundant VPN gateway, ideally in active-active mode.
• A site-to-site IPsec connection with known, documented crypto settings.
• Optional BGP so routes update without editing static prefixes.
• Verification commands and a troubleshooting path based on the gateway's own logs.

Plan before you deploy

Collect these values

Route-based or policy-based

Since October 1, 2023, the portal creates only route-based gateways. Route-based gateways support IKEv1 and IKEv2, BGP and custom IPsec/IKE policies. If your firewall only supports policy-based (crypto-map style) VPNs, keep the route-based gateway and enable Use policy based traffic selectors on the connection; you then have to define every on-premises-to-Azure prefix pair on the firewall instead of any-to-any.

Active-active or active-standby

A VPN gateway always has two instances. In active-active mode both are live, each with its own public IP, and Microsoft recommends it for availability. Your firewall must build a tunnel to both IPs: with only one tunnel, connectivity drops whenever Microsoft maintains that instance. Flows can also be asymmetric across the two tunnels, so a firewall that needs strict symmetry may be better served by active-standby. If your device doesn't support active-active, disable it.

Prerequisites

• A compatible VPN device. Microsoft keeps a list of validated devices with minimum OS versions and configuration guides, including FortiGate, Palo Alto Networks, Cisco ASA and ISR, Juniper SRX, SonicWall, Sophos XG, WatchGuard and others. Devices that aren't listed may still work.
• A static public IPv4 address on the firewall. IKEv2 uses UDP 500 and 4500 and IP protocol 50 (ESP). NAT traversal is supported; if the firewall is behind NAT, the firewall must initiate the tunnel.
• A hub virtual network, for example in the platform subscription of an Azure landing zone.
• Rights to create network resources in the hub resource group, and the Az PowerShell module.

Step 1: Create the GatewaySubnet

In the virtual network, select Subnets > + Subnet, set Subnet purpose to Virtual Network Gateway (the name fills in as GatewaySubnet) and give it a /27 or larger range. Don't associate a network security group: NSGs on the gateway subnet aren't supported and can stop the gateway working. Avoid route tables on it as well unless you know exactly why you need one.

Step 2: Create the VPN gateway

In the portal, create a Virtual network gateway with:

• Gateway type: VPN
• SKU: an AZ SKU such as VpnGw2AZ. Microsoft recommends AZ SKUs where available because they support availability zones. The Basic SKU isn't available in the portal and doesn't support BGP or custom IPsec/IKE policies.
• Generation: Generation2
• Public IP address: create new, Standard SKU, static, zone-redundant
• Enable active-active mode: Enabled, with a second public IP, if the firewall supports it
• Configure BGP: Enabled only if you'll use BGP; the default ASN is 65515 and you can change it

The gateway can take 45 minutes or more to deploy. The same gateway in PowerShell, active-standby and without BGP:

$rg   = 'rg-hub-network'
$loc  = 'westeurope'
$vnet = Get-AzVirtualNetwork -Name 'vnet-hub' -ResourceGroupName $rg
$gwSubnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
 
$pip = New-AzPublicIpAddress -Name 'pip-vpngw-1' -ResourceGroupName $rg -Location $loc `
    -AllocationMethod Static -Sku Standard
$ipconf = New-AzVirtualNetworkGatewayIpConfig -Name 'gwipconf1' -Subnet $gwSubnet -PublicIpAddress $pip
 
New-AzVirtualNetworkGateway -Name 'vpngw-hub' -ResourceGroupName $rg -Location $loc `
    -IpConfigurations $ipconf -GatewayType Vpn -VpnType RouteBased `
    -VpnGatewayGeneration 'Generation2' -GatewaySku VpnGw2AZ

When it's done, read the public IPs from the gateway's Properties page. In active-active mode there are two, and you'll need both on the firewall. The gateway keeps these IPs across resizes, resets and maintenance; they change only if the gateway is deleted and recreated.

Step 3: Create the local network gateway

The local network gateway represents the office. Create one per firewall:

• Endpoint: IP address with the firewall's public IP, or FQDN if the office has a dynamic IP behind dynamic DNS. The FQDN must resolve to a single IPv4 address; Azure caches DNS for 5 minutes and only re-resolves for disconnected tunnels.
• Address space: the office ranges Azure should route into the tunnel. Don't include the firewall's own public IP; that causes sporadic disconnections.
• Advanced: BGP settings, if used (Step 6).

New-AzLocalNetworkGateway -Name 'lng-office-london' -ResourceGroupName $rg -Location $loc `
    -GatewayIpAddress '203.0.113.10' -AddressPrefix '192.168.10.0/24','192.168.20.0/24'

Step 4: Create the connection

On the gateway, open Connections > + Add, choose Site-to-site (IPSec) and set:

• Local network gateway: the office
• Shared key: the same value you'll put on the firewall
• IKE Protocol: IKEv2
• IPsec/IKE policy: Default for now, or Custom (below)
• Use policy based traffic selector: Disable, unless the firewall is policy-based
• DPD timeout in seconds: 45
• Connection Mode: Default

To pin the crypto instead of relying on negotiation, create a custom policy. Once a custom policy is set, Azure only sends and accepts exactly that combination, so the firewall must match it. This example uses the algorithms Microsoft lists as recommended for validated devices, with DH group 14 instead of group 2:

$gw  = Get-AzVirtualNetworkGateway -Name 'vpngw-hub' -ResourceGroupName $rg
$lng = Get-AzLocalNetworkGateway -Name 'lng-office-london' -ResourceGroupName $rg
 
$policy = New-AzIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA256 -DhGroup DHGroup14 `
    -IpsecEncryption GCMAES256 -IpsecIntegrity GCMAES256 -PfsGroup None `
    -SALifeTimeSeconds 27000 -SADataSizeKilobytes 102400000
 
New-AzVirtualNetworkGatewayConnection -Name 'cn-hub-to-london' -ResourceGroupName $rg -Location $loc `
    -VirtualNetworkGateway1 $gw -LocalNetworkGateway2 $lng -ConnectionType IPsec `
    -IpsecPolicies $policy -SharedKey '<32+ character random key>'

When IPsec encryption is GCMAES, IPsec integrity must be the same GCMAES algorithm and key length. Custom policies are supported on the VpnGw1 to VpnGw5 SKUs and their AZ equivalents, not on Basic.

Step 5: Configure the branch firewall

Build a route-based (VTI) IPsec tunnel to each Azure gateway public IP. Use the device's configuration guide from Microsoft's validated device list where one exists; for some devices Microsoft also provides downloadable configuration scripts. The values that must line up:

Azure clamps TCP MSS in both directions on the gateway, to 1,360 bytes for IPv4 over the internet.

If you leave the Azure policy at Default, the firewall must offer something from Azure's default lists. For route-based gateways, phase 1 defaults use DH group 2 with AES256/SHA1, AES256/SHA256, AES128 or 3DES, and Azure as responder accepts a wide range of phase 2 offers. Pinning a custom policy is clearer and avoids weak combinations.

Step 6: Add BGP (optional)

BGP is worth it when you have several offices or redundant tunnels: routes are learned instead of typed into the local network gateway, and traffic fails over automatically when a tunnel drops.

1. Enable BGP on the gateway and set an ASN such as 65010. The on-premises ASN can't be one Azure reserves (public 8074, 8075 and 12076; private 65515 and 65517 to 65520) or one IANA reserves (23456, 64496 to 64511 and 65535 to 65551). The private ranges 64512 to 65514 and 65521 to 65534 are usable, and Azure also supports 32-bit ASNs.
2. Read the Azure BGP peer IP from the gateway's Configuration page or with (Get-AzVirtualNetworkGateway -Name 'vpngw-hub' -ResourceGroupName $rg).BgpSettingsText.
3. On the local network gateway's Advanced tab, enter the office ASN and the firewall's BGP peer IP, which can't be its public IP or inside the virtual network range; a loopback address works. You can leave the address space empty if the connection uses only BGP; Azure adds the host route to the peer itself.
4. Enable BGP on the connection.
5. On the firewall, peer with the Azure BGP IP and ASN, add a host route for the Azure BGP peer IP pointing at the tunnel interface, advertise the office prefixes, and enable eBGP multihop if the device needs it.

If the firewall uses an APIPA address (169.254.x.x) for BGP, configure a custom Azure APIPA BGP address between 169.254.21.0 and 169.254.22.255. Azure doesn't initiate BGP sessions to APIPA peers, so the firewall must.

Step 7: Let spokes use the tunnel

In a hub-and-spoke network, set Allow gateway transit on the hub side of each peering and Use the remote virtual network's gateway on the spoke side, and allow forwarded traffic. Without these, only the hub virtual network can reach the office.

Verification

• The connection's Status in the portal shows Succeeded and Connected.
• PowerShell shows the status and traffic counters:

Get-AzVirtualNetworkGatewayConnection -Name 'cn-hub-to-london' -ResourceGroupName $rg |
    Select-Object Name, ConnectionStatus, IngressBytesTransferred, EgressBytesTransferred

• With BGP, check the session and routes:

Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName $rg -VirtualNetworkGatewayName 'vpngw-hub'
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName $rg -VirtualNetworkGatewayName 'vpngw-hub'

• Test traffic from an office host to a VM in a spoke on an allowed port. The gateway itself doesn't answer ICMP on its local address, so ping a VM instead.

Troubleshooting

Turn on the gateway's diagnostic logs first

Create a diagnostic setting on the gateway that sends GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog and IKEDiagnosticLog to a Log Analytics workspace. A failing tunnel is retried every few seconds, so IKE failures show up immediately without waiting for a repro. Microsoft's query for the IKE log:

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

Find the first SA_INIT (the one with rCookie = 0) to see who initiated and which parameters were proposed. Use TunnelDiagnosticLog for history: a disconnect on one instance followed within seconds by a connect on the other instance is a gateway failover, usually maintenance; a disconnect and reconnect on the same instance points at a DPD timeout or a disconnect sent by the firewall.

Status stays at Connecting

Work through Microsoft's checklist in order:

1. Shared key. Compare both sides; on Azure use Get-AzVirtualNetworkGatewayConnectionSharedKey -Name 'cn-hub-to-london' -ResourceGroupName $rg.
2. Peer IPs. The local network gateway IP must be the firewall's actual public IP, and the firewall must point at the Azure gateway IPs, both of them in active-active mode.
3. Crypto. With a custom policy, the firewall must offer exactly those algorithms. Without one, it must offer something in Azure's default list.
4. Perfect forward secrecy. Microsoft notes PFS on the device can cause disconnection problems; disable it on the firewall, then update the gateway's IPsec policy so both sides match.
5. GatewaySubnet. Remove any NSG or route table and test again.
6. Gateway health. Browse to https://<gateway-public-IP>:8081/healthprobe (the second instance uses port 8083). A response means the gateway is healthy. Basic SKU gateways don't answer.

Tunnel connects but traffic doesn't flow

The office ranges in the local network gateway don't match reality, the firewall has no route for the Azure ranges into the tunnel, spoke peerings lack gateway transit settings, or an NSG in the spoke blocks the traffic. With policy-based traffic selectors, every prefix pair must exist on the firewall.

Tunnel drops every few hours or during maintenance

In active-active mode, check that the firewall has a tunnel to both gateway IPs. Look for the firewall's public IP inside the local network gateway address space. Keep DPD between 30 and 45 seconds; shorter timeouts cause aggressive rekeys that look like disconnects on lossy links.

BGP session doesn't establish

Confirm the ASNs differ and aren't reserved, the firewall has a host route to the Azure BGP peer IP via the tunnel, eBGP multihop is enabled if the device needs it, and with APIPA addresses the firewall initiates. More than 4,000 prefixes advertised to Azure drops the session.

Last resort: reset

If both sides are verified and the tunnel still won't establish, reset the connection (open the connection, then Support + troubleshooting > Reset), which doesn't reboot the gateway. Resetting the gateway (Help > Reset, or Reset-AzVirtualNetworkGateway) reboots an instance and briefly interrupts every tunnel on it, and can limit later root cause analysis.

Closing checklist

• Non-overlapping address plan; GatewaySubnet /27 or larger with no NSG.
• Route-based AZ gateway, active-active if the firewall supports it; both public IPs recorded.
• Local network gateway with the correct firewall IP and office ranges only.
• Connection with IKEv2, a 32+ character shared key and a documented custom IPsec/IKE policy.
• Firewall tunnels to every Azure gateway IP with matching phase 1 and phase 2 settings.
• Optional BGP with non-reserved ASNs and a host route to the Azure peer.
• Spoke peerings using the hub gateway; diagnostic logs flowing to Log Analytics.

References

• Tutorial: Create a site-to-site VPN connection in the Azure portal
• About VPN devices and IPsec/IKE parameters
• Configure custom IPsec/IKE connection policies (portal)
• Configure custom IPsec/IKE connection policies (PowerShell)
• About BGP with VPN Gateway
• Configure BGP for Azure VPN Gateway
• Azure VPN Gateway FAQ
• Verify a VPN gateway connection
• Monitor Azure VPN Gateway
• Reset a VPN gateway or connection
• Troubleshoot an Azure site-to-site VPN connection that can't connect
• Troubleshoot Azure VPN Gateway using diagnostic logs
• Hub-spoke network topology in Azure