Connectivity services

Site-to-site VPN

Building blocks

Gateway deployment takes roughly 30–45 minutes. Gateway SKU changes within the same family and generation can be done in place. Changing between non-compatible SKUs means recreating.

Policy-based vs route-based

Pick route-based unless a legacy device can only do policy-based tunnels. If an on-premises device is policy-based but you need route-based on Azure, use UsePolicyBasedTrafficSelectors on the connection and a custom IPsec/IKE policy so Azure matches the device’s selectors. The old Basic SKU is legacy and shouldn’t be your answer for new designs.

Gateway SKUs

SKUs are VpnGw1 to VpnGw5 and the zone-redundant AZ versions (VpnGw1AZ to VpnGw5AZ). Generation 1 and Generation 2 exist for some SKUs. The higher the SKU, the more aggregate throughput and more S2S tunnels and P2S connections.

Remember the order of magnitude (hundreds of Mbps up to 10 Gbps) and the S2S tunnel limit of 30 versus 100. AZ SKUs spread the two gateway instances across availability zones and need Standard zone-redundant public IPs. For resilience in a zone region, choose an AZ SKU. A VPN gateway never exceeds about 10 Gbps, so a requirement of “more than that” or “predictable latency, dedicated” points to ExpressRoute.

High availability designs

The on-premises device must support what you configure. Use BGP for dynamic routing, multiple sites and automatic failover. Azure’s default ASN is 65515. Use a different ASN for your on-premises device. BGP peer addresses on both sides must not overlap with VNet prefixes. For custom APIPA BGP addresses use 169.254.21.0/24 and 169.254.22.0/24.

IPsec/IKE policy

By default Azure negotiates from a list of supported proposals. A custom IPsec/IKE policy pins one combination for a connection, set on both ends (Azure and device). A policy contains:

• IKE phase 1 (main mode): encryption, integrity, DH group, SA lifetime
• IPsec phase 2 (quick mode): encryption, integrity, PFS group, SA lifetime (time and data size)
• Optional UsePolicyBasedTrafficSelectors and DPD timeout

Mismatched proposals are the most common cause of a tunnel stuck in “Connecting”.

Troubleshooting gateways

• Check the connection status (Connected, Connecting, NotConnected) and tunnel metrics (TunnelEgressBytes, TunnelIngressBytes, BGP peer status).
• VPN troubleshoot in Network Watcher runs diagnostics and writes logs to storage.
• Enable gateway diagnostic logs in Log Analytics: GatewayDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog, IKEDiagnosticLog (the last shows negotiation mismatches).
• Frequent causes: wrong pre-shared key; wrong peer public IP in the local network gateway; mismatched IKE/IPsec parameters; on-premises NAT hiding the device without NAT-T support; overlapping address spaces; UDP 500/4500 blocked; the on-premises prefixes missing from the local network gateway; a UDR on GatewaySubnet or an NSG on it.
• Resetting the gateway or resetting the connection helps after changes.

Azure Extended Network

Azure Extended Network stretches an on-premises subnet into an Azure VNet so VMs can move to Azure without changing IP addresses (a migration aid for lift-and-shift and Azure Stack HCI). Layer 2 traffic is bridged over an existing S2S VPN or ExpressRoute connection by a small appliance on-premises and a network virtual appliance in Azure, set up through Windows Admin Center. It’s temporary by design: finish by re-addressing or cutting over the subnet. Don’t use it for a permanent L2 design.

Point-to-site VPN

P2S connects individual clients (laptops) to a VNet. It uses the same route-based VPN gateway (needs GatewaySubnet), plus a client address pool (not overlapping with VNet or on-premises ranges).

SKU selection

P2S supports VpnGw1–5 (and AZ). Basic supports only SSTP/IKEv2 with small numbers and no RADIUS. Larger SKUs allow more concurrent connections: roughly 250 (VpnGw1), 500 (VpnGw2), 1,000 (VpnGw3), 5,000 (VpnGw4) and 10,000 (VpnGw5). SSTP is capped at 128 concurrent connections regardless of SKU. For thousands of remote users, pick VpnGw4/5 with OpenVPN or IKEv2, or use Virtual WAN, whose P2S scale units go higher.

Tunnel types

You can enable more than one tunnel type on the gateway. Combine IKEv2 + OpenVPN to cover Windows, macOS and mobile.

Authentication methods

Conditional Access, per-user MFA and group-based access point to Entra ID. Existing on-premises AD with NPS points to RADIUS. No identity system and a small team points to certificates. Use Entra ID for the best security posture for remote users.

Client configuration

After you set up the gateway, download the VPN client configuration package from the gateway. It contains profiles per client type, such as azurevpnconfig.xml for the Azure VPN Client and OpenVPN .ovpn data. The package must be regenerated and redistributed when you change the tunnel type, address pool, authentication, DNS or routes. Clients get routes to the VNet and peered VNets, so after peering changes, re-download the profile (or use the Azure VPN Client’s updated profile) to pick up new routes.

Troubleshooting P2S

• Client side: wrong or expired certificate, certificate not in the Current User store, old profile after a gateway change, the machine’s firewall blocking TCP 443 or UDP 500/4500, unsupported OS for the chosen tunnel type, client address pool overlapping the local LAN.
• Authentication: root certificate not uploaded, certificate chain missing, RADIUS server unreachable, shared secret mismatch, Entra app consent missing, wrong tenant in the Azure VPN client.
• Routing: the VNet or peered VNet isn’t reachable because the client profile has stale routes. Enable Use remote gateways and allow gateway transit for peered VNets, then re-download.
• Use the gateway’s P2S connection list, Log Analytics (P2SDiagnosticLog) and client logs.

Always On VPN and Azure Network Adapter

• Always On VPN is the Windows 10/11 feature that auto-connects and can run a device tunnel (before sign-in, machine certificate) and a user tunnel. Azure requirements: route-based gateway, IKEv2 (and for the device tunnel an IKEv2 machine certificate with the root uploaded), VpnGw1+ SKU, and client profiles deployed (Intune or PowerShell). It relies on certificates, not Entra OpenVPN.
• Azure Network Adapter adds a virtual network adapter to an on-premises Windows Server (2019+) through Windows Admin Center, connecting it to a VNet with a P2S VPN. WAC creates the gateway (route-based, P2S with certificate) and the certificate for you. Use it to connect a single server quickly, not a whole site.

ExpressRoute

ExpressRoute gives a private, dedicated connection to Microsoft that doesn’t cross the public internet. It’s chosen for predictable latency, consistent throughput, SLA and security. It isn’t encrypted by default.

Connectivity models

Provider circuits come in bandwidths from 50 Mbps to 10 Gbps. A circuit has a service key the provider uses. Each circuit has two connections (primary and secondary) to two Microsoft Enterprise Edge routers (MSEE) for redundancy, and you must use both to get the SLA.

SKUs and billing

Metered = pay per GB egress. Unlimited = flat monthly price. Local is the cheapest when the peering location is near the target region. Premium is needed for cross-geography connectivity, more than 10 VNets, or more than 4,000 routes. You can change the SKU and billing model upward without downtime. A Standard circuit in the same geopolitical area reaches all regions there, such as Europe.

Peering

Choose between private only, Microsoft only or both: private peering alone for IaaS in VNets. Add Microsoft peering only when you need Microsoft 365 or PaaS public endpoints privately. For Azure PaaS, private endpoints over private peering is the preferred modern answer. Microsoft peering carries more routing and NAT complexity. Public peering is deprecated. Don’t pick it.

Gateway and connecting VNets

• Create an ExpressRoute virtual network gateway in the VNet’s GatewaySubnet (/27 or larger).
• Then create a connection from the gateway to the circuit. Connect VNets in other subscriptions using an authorization key from the circuit owner.
• Gateway SKUs: Standard / ErGw1AZ, High Performance / ErGw2AZ, Ultra Performance / ErGw3AZ, and ErGwScale (scale units, up to the highest throughput). Choose the AZ SKUs for zone resilience. Throughput roughly 1 Gbps (ErGw1Az), 2 Gbps (ErGw2Az), 10 Gbps (ErGw3Az).
• ER and VPN gateways can coexist in the same VNet (one GatewaySubnet).

Route advertisement

• Azure advertises the VNet address space (and peered VNets using gateway transit) to on-premises over BGP. On-premises advertises its prefixes to Azure.
• Private peering limits: 4,000 prefixes from on-premises to Azure (10,000 with Premium). Exceed it and the BGP session drops, so summarize routes.
• Control the preferred path with AS-path prepending and local preference (communities). When both ER and VPN advertise the same prefix, ER wins. When prefixes differ, longest prefix match wins.
• To make traffic symmetric, advertise the same prefix with consistent attributes on both circuits.
• Microsoft peering advertisement requires prefixes you own, or from the provider.

Resilience, cross-region and disaster recovery

• Maximum resiliency: two circuits at different peering locations (with different providers if possible), each with two connections, connected to the same VNet (or via two ER gateways to different regions).
• Cross-region: Premium (or Standard in one geopolitical region) connecting to multiple VNets and regions, or Global Reach. Route to a secondary region through a second circuit or via VNet peering/hub.
• VPN as a backup for ER is a standard cost-conscious DR answer.
• Use zone-redundant gateways (ErGw AZ) and keep a second circuit for provider or location failure. A single circuit has two links but is still a single provider and location.

ExpressRoute options

Global Reach isn’t for Azure-to-Azure. It’s for on-premises-to-on-premises through Azure. FastPath doesn’t bypass the circuit, only the gateway.

Encryption over ExpressRoute

ExpressRoute isn’t encrypted by default. Options:

If a question says “encrypt at the physical link on ER Direct”, answer MACsec. “Encrypt end to end between site and VNet” is IPsec over ER.

BFD

Bidirectional Forwarding Detection detects a failed link quickly so BGP converges in about a second instead of waiting for the BGP hold timer (default keepalive 60 s, hold 180 s). On ExpressRoute, BFD is enabled on the Microsoft side by default for private peering circuits. You must configure it on your router. Without BFD on the customer edge, a silent failure can take minutes to detect.

Diagnosing ExpressRoute

• Check the circuit provisioning state (provider status must be Provisioned) and the circuit state (Enabled).
• Inspect BGP session state, ARP tables and route tables per peering (Get-AzExpressRouteCircuitRouteTable, ARP table).
• Use Network insights and Connection Monitor for end-to-end latency and drops, and Network Watcher next hop for effective paths.
• Common causes: wrong VLAN, ASN or /30 subnets; MD5 mismatch; gateway not linked to the circuit; route limit exceeded; missing route filter on Microsoft peering; provider hasn’t provisioned.

Azure Virtual WAN

Virtual WAN is a managed hub-and-spoke service that gives automated, transitive connectivity between branches, remote users, VNets and ExpressRoute circuits. It replaces hand-built hubs with gateways, Route Server and firewalls.

SKUs

Standard is the answer for almost every real design. Basic suits only simple, single-hub, VPN-only sites.

Hubs and components

• A virtual hub is a Microsoft-managed VNet in one region with a hub address prefix (/24 or larger; /23 recommended for scale). You deploy gateways into it: S2S VPN, P2S VPN and ExpressRoute. Hubs can also hold Azure Firewall, NVAs and Route Server-style hub router features.
• Hub-to-hub connectivity is automatic between hubs in the same Virtual WAN (Standard), giving global transit.
• Spokes connect with VNet connections to the hub. Sites connect as VPN sites (a site with links to the hub’s gateways, using IKEv2/BGP or static routes). ExpressRoute circuits connect with a circuit connection.
• The hub router offers up to ~50 Gbps aggregate and BGP peers for NVAs.

Scale units

Capacity is bought in scale units:

Choose scale units from the aggregate throughput you need, rounding up. Scale units can be changed later and cost by the unit. The hub infrastructure units (routing capacity) are separate and are the minimum 2 (3 Gbps) up to higher counts for more VMs and throughput.

Virtual hub routing

• Every hub has a Default route table (and a None table). Connections are associated with a route table (which table decides their routes) and propagate to one or more route tables or labels (what they advertise).
• Custom route tables isolate spokes (for example shared services vs isolated VNets), using associations and propagations instead of UDRs.
• Static routes in a table or on a VNet connection steer traffic (for example 0.0.0.0/0 to a firewall or NVA).
• Labels group route tables to propagate across hubs.
• Routing intent and routing policies send Internet traffic and/or private traffic through a security solution in the hub (Azure Firewall, NVA or SaaS) without UDRs. This is the simplest way to build a secured hub.
• Virtual WAN routing for spokes avoids UDRs, with the exception of the indirect spoke pattern: a VNet peered to a connected spoke, reached with a static route to the NVA.

Third-party NVA integration

• NVA in the hub: deploy a partner NVA from the Marketplace (for example SD-WAN or next-generation firewall, from Cisco, Fortinet, Barracuda, VMware and others) as a managed application into the hub. The hub handles the branch connectivity with an integrated SD-WAN, and routing is automated.
• NVA in a spoke with BGP peering: the hub router BGP-peers with an NVA in a connected VNet to exchange routes (for example SD-WAN NVA in a “shared services” VNet).
• Azure Firewall in the hub creates a secured hub, managed through Azure Firewall Manager and routing intent.

Virtual WAN vs hub-and-spoke you build

VPN vs ExpressRoute vs Virtual WAN