Azure VPN (Azure Virtual Private Network): Azure VPN Gateway Architecture, Types, and Best Practices
Azure VPN (Azure Virtual Private Network) is typically implemented using Azure VPN Gateway to encrypt traffic over the public internet between an Azure virtual network (VNet) and (1) on-premises networks, (2) remote users, or (3) other VNets. In this guide, you’ll learn how Azure VPN works, which connection type to choose (S2S, P2S, VNet-to-VNet, and ExpressRoute coexistence), what protocols are supported, how SKUs impact throughput, and a practical troubleshooting checklist.
What is Azure VPN (Azure Virtual Private Network)?
In Azure, “Azure VPN” usually refers to using VPN Gateway (a type of virtual network gateway) to create encrypted tunnels (IPsec/IKE) for hybrid connectivity and secure remote access. You can use it to:
Connect on-premises ↔ Azure VNet (Site-to-Site)
Connect remote users/devices ↔ Azure VNet (Point-to-Site)
Connect Azure VNet ↔ Azure VNet (VNet-to-VNet)
Azure VPN Architecture (how it works)
A basic Azure VPN (VPN Gateway) deployment includes:
Local Area Network (LAN)
The foundation of this architecture is your company’s private local area network (LAN), which forms the internal backbone of your network infrastructure.
Virtual Private Network (VPN) device
A crucial component, the VPN device, offers external connectivity to the LAN. This can be a hardware-based solution or a software service like the Routing and Remote Access Service (RRAS) in Windows Server 2012.
Virtual network
In Azure, the cloud application and Azure VPN Gateway components reside within the same virtual network, ensuring streamlined connectivity and security.
Azure VPN Gateway
The VPN Gateway service allows you to connect the virtual network to the local area network using a VPN device. This service includes the following elements:
Virtual Network Gateway: Acts as a virtual VPN device for the virtual network, routing traffic from the LAN to the virtual network.
Local Network Gateway: Represents the on-premises VPN device abstraction, routing cloud application traffic to the LAN.
Connection: Holds properties specifying the connection type (e.g., IPSec) and the shared key for encrypting traffic.
Gateway Subnet: A dedicated subnet for maintaining the virtual network gateway.
Internal Load Balancer: Routes VPN Gateway network traffic to the cloud application through an internal load balancer located in the application’s front-end subnet.
Traffic flow + encryption overview
Traffic is encrypted between endpoints (Azure VPN Gateway and the other VPN endpoint) using IPsec/IKE. For P2S, the tunnel is initiated by the client device to the gateway. For S2S and VNet-to-VNet, tunnels are established between gateways/devices as configured.
Azure VPN Connection Types (Choose the Right One)
Conceptually there are 2 types of connections between possible environments using Networks and Azure Gateway.
Site to Site (S2S)
This connection uses IPsec (IKE v1 and IKE v2) to establish a secure link between a virtual network and a local site. Once established, resources behind the local gateway can securely communicate with Azure resources. This option is ideal for allowing entire local networks to access Azure resources without individual device connections.
In comparison with the next option (Point to Site), each team in our local network doesn’t need to make a connection to the Azure virtual network to access its resources.
Point-to-Site (P2S)
Leveraging SSTP (Secure Sockets Tunnel Protocol), P2S allows individual client devices to connect to the Azure network. It requires a VPN client on each device, making it suitable for scenarios where only specific devices need access to Azure resources.
Point-to-Site connections do not need a VPN dial-up device but work with a VPN client installed on the Device. However, only such equipment can connect to Azure resources. In the case that several teams need access to these resources, each of them must mark a Point-to-Site VPN.
Multi-Site
A variation of the S2S type, Multi-Site VPN enables linking multiple external locations to the same Azure virtual network. It’s particularly useful for organizations with several branches or remote sites needing access to shared Azure resources.
Azure VPN offers a versatile and secure way to extend your on-premises networks into the cloud. Whether it’s a single remote user needing access to Azure resources (P2S), an entire local network (S2S), or multiple external sites (Multi-Site), Azure VPN provides tailored solutions for various business requirements. By harnessing these capabilities, businesses can achieve greater operational agility, enhanced security, and seamless integration between their on-premises and cloud environments.
Azure VPN protocols and authentication (what’s supported)
IKEv2 and IPsec/IKE (S2S)
S2S VPN in Azure uses IPsec/IKE tunnels. Ensure encryption/auth settings and NAT/traversal requirements match your on-prem device capabilities and Azure configuration.
P2S protocols: IKEv2 / OpenVPN (and SSTP migration notes)
For P2S, Azure supports options including IKEv2 and OpenVPN. Microsoft also provides guidance for moving off SSTP, including a noted 128 concurrent connection limit for SSTP and migration paths to OpenVPN or IKEv2.
Practical takeaway: If you still have SSTP-based clients, plan a migration (profiles, client rollout, and a cutover window), because SSTP and OpenVPN can’t coexist on the same gateway due to both being TLS-based.
Gateway SKUs, throughput, and scalability
How to pick a SKU (the sane way)
Choose a VPN Gateway SKU based on:
Required features (including availability/zone support)
Expected throughput and number of tunnels/users
SLA/architecture requirements
Microsoft notes the VPN Gateway SKU portfolio is being consolidated, including transitions from non-AZ to AZ-supported SKUs—so avoid designing around legacy/non-preferred SKUs when launching something new.
Throughput expectations (and why tests matter)
Published throughput is guidance, but real throughput depends on:
Gateway SKU limits
Crypto overhead + packet sizes
VM NIC throughput + OS settings
ISP bandwidth and latency
Microsoft provides a practical workflow for validating throughput end-to-end—use it before committing to a design.
Azure VPN vs VNet peering vs ExpressRoute
Choose Azure VPN (Azure Virtual Private Network / VPN Gateway) when…
You need encrypted tunnels over the internet for hybrid connectivity or remote access
You need a backup path to ExpressRoute
You need connectivity where ExpressRoute is not available or not justified
Choose VNet peering when…
You’re connecting Azure ↔ Azure VNets and want a simpler, high-performance approach without putting a gateway in the data path (common case)
Choose ExpressRoute when…
You want a private connection that doesn’t traverse the public internet and typically offers higher reliability/lower latency characteristics than internet VPN
Important nuance: Microsoft explicitly calls out that for VNet-to-VNet connectivity, VNet peering is generally recommended compared to connecting VNets through ExpressRoute gateways due to gateway bandwidth/performance constraints in the data path.
Common pitfalls + troubleshooting checklist
Use this as your “first 15 minutes” checklist when Azure VPN is flaky:
Addressing & routing
Overlapping CIDRs between on-prem and VNet (or between VNets) → breaks routing and is painful to fix later.
Confirm effective routes on NICs (Azure portal “Effective routes” / route tables). For peering scenarios, effective routes also help confirm peering propagation.
If using BGP, ensure ASN + BGP peer IPs + route propagation expectations match what Azure supports (see VPN Gateway docs/FAQ).
P2S client issues
Wrong client profile (cert/auth mismatch or stale config)
Protocol mismatch (IKEv2 vs OpenVPN vs SSTP legacy)
SSTP scale limit symptoms (if still used) and planned migration steps
S2S tunnel problems
IPsec/IKE policy mismatch (encryption/integrity/DH/PFS)
On-prem device NAT-T/firewall rules blocking IKE/IPsec
Public IP changes on the on-prem device side without updates in Azure
Multiple tunnels/paths causing asymmetric routing
DNS and name resolution
“VPN is up but apps fail” often = DNS. Confirm the client or on-prem resolvers can resolve private zones/records reachable through the tunnel.
Performance complaints
Confirm the gateway SKU is appropriate and not saturated
Validate end-to-end throughput using Microsoft’s recommended approach (gateway + VM + ISP).
FAQ About Azure Virtual Private Network
What is Azure VPN (Azure Virtual Private Network)? Azure VPN refers to encrypted connectivity in Azure, typically delivered through Azure VPN Gateway to connect VNets to on-premises networks, remote users, or other VNets over the public internet.
What’s the difference between S2S and P2S in Azure VPN? S2S connects a whole on-premises network to an Azure VNet over IPsec/IKE. P2S connects individual client devices (like laptops) into a VNet, commonly for remote access.
Can I use Azure VPN to connect two VNets? Yes. You can create VNet-to-VNet connections using VPN Gateway (useful across regions or specific constraints), though VNet peering can be a simpler option depending on requirements.
Which protocols does Azure VPN Gateway support for P2S? Microsoft provides options such as IKEv2 and OpenVPN, and also publishes guidance for transitioning off SSTP in applicable scenarios.
How do I choose the right Azure VPN Gateway SKU? Choose based on required features, availability needs, and throughput expectations. Microsoft documents SKU guidance and notes ongoing SKU portfolio changes/migrations.
What throughput can I expect from Azure VPN? Throughput varies by SKU and real-world conditions (crypto overhead, latency, ISP bandwidth). Microsoft recommends validating throughput and treating estimates as guidance.
