Azure VPN Gateway

About Azure VPN Gateway

Azure VPN Gateway is Microsoft's managed virtual network gateway service for encrypted connectivity between Azure virtual networks, on-premises networks, remote users, and other Azure virtual networks. It supports site-to-site VPN, point-to-site VPN, and VNet-to-VNet connections using IPsec, IKE, OpenVPN, and SSTP in supported scenarios. The service fits organizations that need encrypted hybrid connectivity without running their own VPN appliance in Azure. Buyers should choose the gateway SKU, availability design, routing model, authentication method, and migration path around expected throughput, tunnel counts, remote-user scale, resilience, and lifecycle requirements.

What is Azure VPN Gateway used for?

Azure VPN Gateway is commonly used to connect an on-premises or branch network to an Azure virtual network through a site-to-site IPsec VPN. It can also connect individual remote users through point-to-site VPN and connect Azure virtual networks through VNet-to-VNet tunnels.

A managed gateway removes the need to deploy, patch, and operate a customer-managed VPN appliance inside an Azure virtual machine, but it does not remove network engineering. Address spaces, GatewaySubnet sizing, routing, on-premises device configuration, authentication, monitoring, and high-availability design remain customer responsibilities.

Which VPN Gateway SKUs should new deployments use?

Microsoft's current documentation recommends zone-capable gateway SKUs for new production deployments. The main current production range is VpnGw1AZ through VpnGw5AZ, while Basic remains available for limited scenarios. Microsoft requires a Standard SKU public IP for new VPN gateways.

Current Microsoft benchmark tables list VpnGw1AZ at 650 Mbps, VpnGw2AZ at either 1 Gbps or 1.25 Gbps depending on gateway generation, VpnGw3AZ at up to 2.5 Gbps for Generation 2, VpnGw4AZ at 5 Gbps, and VpnGw5AZ at 10 Gbps. These are aggregate benchmarks, not guaranteed application throughput, and one individual S2S or P2S connection can perform substantially below the aggregate figure.

What is Advanced Connectivity and the 20 Gbps high-bandwidth option?

Microsoft now documents an Advanced Connectivity option for newly deployed VpnGw5AZ gateways. Its high-bandwidth site-to-site design can use up to four IPsec tunnels, organized as two VPN connections with two tunnels each. Microsoft states that each tunnel can provide up to 5 Gbps of encrypted throughput, for a combined maximum of 20 Gbps.

This is not a general 20 Gbps internet VPN upgrade. The current design requires an ExpressRoute circuit with private peering, an ExpressRoute virtual network gateway, FastPath on the ExpressRoute connection, and a new VpnGw5AZ gateway with Advanced Connectivity enabled. The IPsec tunnels use private IP addresses and transit ExpressRoute private peering. Microsoft also lists important current limitations, including no internet-based VPN for this mode, no IKEv1, no point-to-site, no NAT, no IPv6, no APIPA for BGP, no migration path from existing gateways, and no Virtual WAN interoperability. Regional availability must also be checked before designing around it.

How do site-to-site, point-to-site, and VNet-to-VNet differ?

Site-to-site connections link an Azure virtual network to an on-premises or branch network through a compatible VPN device. Point-to-site is designed for individual client computers that need secure remote access to Azure resources. VNet-to-VNet uses VPN Gateway to create encrypted connectivity between Azure virtual networks.

For Azure-to-Azure connectivity, buyers should compare VNet-to-VNet tunnels with native virtual network peering. Peering is often simpler for direct Azure network connectivity, while gateway-based tunnels can be useful when encrypted IPsec paths or a consistent gateway-based topology are design requirements.

How do high availability and active-active mode work?

Azure VPN Gateway can be deployed using zone-capable gateway SKUs. In Azure regions with Availability Zones, these SKUs support zone-resilient deployment. In regions without Availability Zones, Microsoft can still deploy the AZ-named SKU regionally, but the environment does not gain zone redundancy until the region supports it.

Active-active mode uses both gateway instances with separate public IP addresses for supported S2S and VNet-to-VNet designs. The remote VPN device and routing design must also support the topology. Enabling active-active mode in Azure does not make a single unsupported on-premises appliance highly available.

What routing and authentication options matter?

VPN Gateway supports static routing and BGP depending on VPN type and gateway SKU. Route-based gateways are the normal choice for current deployments. Microsoft documents IKEv1 and IKEv2 support on current route-based VpnGw1AZ through VpnGw5AZ gateways, while Basic has more limited capabilities.

Point-to-site supports certificate authentication, Microsoft Entra ID in supported OpenVPN scenarios, and RADIUS in supported configurations. Basic does not support RADIUS and has other capability limits. Authentication should be treated as an operational lifecycle concern because certificates, VPN client profiles, identity configuration, and client software all change over time.

What changed for the Azure VPN Client on Linux?

The Azure VPN Client for Linux preview retired on August 31, 2026. Microsoft now states that it is no longer supported after that date. Existing installations may continue to work for a period, but Microsoft no longer provides fixes, security patches, or support, and the package is being removed from Microsoft's Linux repository.

Organizations that used the retired preview client for point-to-site access should move to a supported replacement instead of treating an existing installation as a production-supported endpoint. This retirement affects the client software, not Azure VPN Gateway as a managed service.

What should existing non-AZ VpnGw1 through VpnGw5 customers do?

Microsoft is consolidating the older non-AZ VpnGw1 through VpnGw5 portfolio into availability-zone capable SKUs. New creation of those older non-AZ SKUs was blocked from November 1, 2025. Microsoft's current migration documentation describes a transition period through September 2026 and states that gateways already using a Standard public IP can be migrated automatically as part of service updates.

Customers should verify their current SKU rather than assuming the gateway name means it is zone capable. If the SKU name ends in AZ, such as VpnGw2AZ, it is already on the newer family. Existing older gateways should follow Microsoft's current migration guidance and avoid unnecessary delete-and-recreate work unless a documented architecture change requires it.

How is Azure VPN Gateway priced?

Pricing was checked on September 5, 2026. Microsoft charges for the VPN gateway while it is provisioned and available. The selected SKU affects the base gateway cost, throughput benchmark, S2S tunnel limits, and P2S connection limits.

For the zone-capable gateway range, Microsoft lists the first 10 S2S tunnels and first 128 P2S connections as included, with additional per-hour charges above those included quantities up to the SKU limits. Data transfer can also be billed separately. Microsoft lists VpnGw1AZ through VpnGw5AZ with increasing tunnel and P2S limits. The Advanced Connectivity 20 Gbps option carries its own deployment-hour meter and is only available for newly deployed VpnGw5AZ gateways. Buyers should model gateway hours, tunnel counts, P2S connections, inter-VNet transfer, P2S egress, and any Advanced Connectivity usage together.

What are the main scale and performance limits?

Microsoft's current SKU tables separate SSTP and IKEv2 or OpenVPN point-to-site connection limits. VpnGw1AZ supports up to 30 S2S or VNet-to-VNet tunnels and up to 250 IKEv2 or OpenVPN P2S connections. VpnGw2AZ supports up to 30 S2S tunnels and 500 IKEv2 or OpenVPN P2S connections. VpnGw3AZ supports up to 30 S2S tunnels and 1,000 IKEv2 or OpenVPN P2S connections. VpnGw4AZ and VpnGw5AZ support up to 100 S2S tunnels and up to 5,000 and 10,000 IKEv2 or OpenVPN P2S connections respectively.

Microsoft recommends Azure Virtual WAN if more than 100 S2S VPN tunnels are required. Large P2S populations can also reduce effective S2S performance because aggregate gateway resources are shared. Benchmark numbers should therefore be treated as planning ceilings rather than guaranteed throughput for each tunnel.

Azure VPN Gateway vs ExpressRoute and Virtual WAN

VPN Gateway is a good fit when encrypted connectivity over the public internet meets the organization's requirements. ExpressRoute uses private connectivity through a connectivity provider and is usually considered when private WAN connectivity, predictable provider-based circuits, or larger enterprise network architectures are required.

Azure Virtual WAN provides a broader managed architecture for branch, site, remote-user, and hub connectivity at scale. Organizations with many branches, more than 100 S2S tunnels, complex transitive routing, or centralized global network operations should compare Virtual WAN before standardizing on many independent VPN gateways. Advanced Connectivity also combines VPN Gateway with ExpressRoute rather than replacing ExpressRoute.

What are the main limitations and operational tradeoffs?

VPN Gateway performance depends on more than the advertised SKU. Packet size, encryption, internet path quality, remote VPN device performance, routing, tunnel count, and concurrent P2S use can all reduce real throughput. Site-to-site availability also depends on the resilience of the on-premises VPN devices and internet circuits.

Provisioning and some gateway changes can take substantial time. Address-space overlaps can complicate hybrid routing. Point-to-site requires client and authentication lifecycle management. Advanced Connectivity has major current limitations and is unsuitable where P2S, internet-based VPN, NAT, IPv6, Virtual WAN interoperability, or migration from an existing gateway are required.

Who should choose something else?

Organizations that require private connectivity rather than encrypted traffic over the public internet should evaluate ExpressRoute. Companies building a large branch network with many sites, centralized routing, or more than 100 S2S tunnels should compare Azure Virtual WAN.

Teams that only need Azure-to-Azure connectivity may find virtual network peering simpler than routing traffic through VPN gateways. Users who only need secure RDP or SSH administration to Azure virtual machines may be better served by Azure Bastion. Organizations considering the 20 Gbps Advanced Connectivity mode should choose something else if they need a normal internet VPN, point-to-site access, NAT, IPv6, or compatibility with an existing VPN Gateway deployment.