--- cuppy_hub: azure cuppy_path: reference/networking/vpn-and-expressroute.md cuppy_section: docs cuppy_doc: 929A-WHFM cuppy_doc_uuid: 88044875-4115-4ee6-a1de-f2822f074d5f cuppy_permalink: https://cuppy.io/azure/d/929A-WHFM cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/azure/docs/reference/networking/vpn-and-expressroute cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: a909b82e732690efb294cbbe66aff6d39469ae7b58eae3e4a6b9bf73f895455b # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # VPN Gateway and ExpressRoute ## Gateways and their SKUs - Both gateway types live in a subnet named exactly **`GatewaySubnet`**, **/27 or larger** (more for VPN and ExpressRoute coexistence or migrations), with nothing else in it. Don't put an NSG that blocks UDP 500/4500 or a UDR that blackholes the on-premises peer on it. - **VPN Gateway:** since **November 1, 2025 new gateways must use an AZ SKU** (`VpnGw1AZ`–`VpnGw5AZ`) with a Standard public IP. Non-AZ `VpnGw1`–`VpnGw5` were scheduled for deprecation after **September 30, 2026**: check with `az network vnet-gateway show -g -n --query sku.name` and upgrade any name without `AZ` (no downtime expected). Legacy **Standard / HighPerformance** SKUs are retired (Microsoft's pages give both September 30, 2025 and June 2026). **Basic** is dev/test only: no IPv6, no RADIUS, CLI or PowerShell only; a Basic gateway with a Basic public IP needs only "Delete Basic Public Ip Reference" (the address stays). Standard-IP gateways move to Generation 2 automatically. - **ExpressRoute gateway:** `ErGw1Az`/`ErGw2Az`/`ErGw3Az` or the scalable `ErGwScale`; FastPath needs `ErGw3Az`, `UltraPerformance` or `ErGwScale` with 10+ scale units. Move a Standard, HighPerformance or UltraPerformance gateway to an AZ SKU with the **gateway migration** experience (a second gateway is created in the same subnet); other SKU changes may mean delete and recreate, with downtime. Microsoft manages the gateway's public IP. ## VPN design rules - **Active-active** gives each gateway instance its own public IP and tunnel; configure the on-premises device for **both** tunnels. Converting an existing gateway that uses non-APIPA BGP peer addresses causes downtime. - **BGP:** the on-premises ASN must differ from the gateway's; Azure reserves **8074, 8075, 12076, 65515 and 65517–65520**. The local network gateway carries the on-premises BGP peer IP; Azure adds its /32 route itself. - Point-to-site: the Azure VPN Client for Linux (preview) retired on August 31, 2026. ## Site-to-site errors Read the reason first: `az network vpn-connection show -g -n --query "{status:connectionStatus, egress:egressBytesTransferred, ingress:ingressBytesTransferred}"`, then the gateway's **`IKEDiagnosticLog`** in Log Analytics (add a diagnostic setting with `allLogs` if none exists, then retry the connection). | IKE error (code) | Cause → fix | |---|---| | `Negotiation timed out` (13805) | The on-premises device isn't answering IKE: check its public IP on the local network gateway (the external address if it's behind NAT), UDP 500/4500 reachability, and that the device is supported | | `IKE authentication credentials are unacceptable` (13801) | Pre-shared key mismatch: set the same key on the connection and the device | | `Policy match error` (13868) / `No policy configured` (13825) | IKE/IPsec policy (or PFS) mismatch: align the custom policy on the connection with the device | | `Traffic selectors unacceptable` (13999) | Address ranges differ: match the local network gateway prefixes and the device's selectors, or use `usePolicyBasedTrafficSelectors` for policy-based devices | | `Invalid header` (13824) / `Invalid payload received` (13843) / `Invalid cookie received` (13846) | Unsupported IKE messages from the device: use a validated device and configuration | | `The recipient cannot handle version of IKE specified in the header` (13880) | IKEv1 on one side, IKEv2 on the other | | `Failure in Diffie-Hellman computation` (13822) | DH group mismatch | | `The remote computer refused the network connection` (1225) | The Azure connection is **Initiator only**: set connection mode to Default or Responder only | | `Connected` but 0 bytes | Traffic selector or subnet mismatch, or routing on either side | | BGP peer not `Connected` | ASN or peer IP mismatch, BGP not enabled on the connection, or a reserved ASN | ## ExpressRoute - A circuit works only when **Circuit status is Enabled** (Microsoft side) **and Provider status is Provisioned** (`serviceProviderProvisioningState`). Stuck at *Not enabled*: Microsoft support. Stuck at *Not provisioned*: your connectivity provider. - Gateway migration errors: | Message | Fix | |---|---| | `Virtual network {vnetName} doesn't have sufficient space for deploying another gateway.` | Recreate `GatewaySubnet` as /27 or larger | | Connections created before 2017 (legacy mode) | Delete and recreate the connections first | | Gateway or a connected resource in a failed state | Bring everything to Succeeded (a GET then SET on the resource) | | Default-SKU gateway | Resize to Standard before migrating | | FastPath or route weight changed during migration | Not allowed: keep the original values | | `…already contains the maximum number of allowed gateways.` | A VNet holds at most two ExpressRoute gateways | | A dedicated HSM in the VNet | Deallocate it before migrating | --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.