Azure VPN Gateway: All you should know
Imagine your organization has migrated much of its infrastructure to Azure. The datacenter is connected to Azure using ExpressRoute. However, you would like to connect smaller regional facilities to Azure. You need secure connectivity so that sensitive information is protected while it’s crossing the network. You don’t currently have the bandwidth requirements for a dedicated circuit, and you’re looking for a way to integrate these networks in a cost-effective way.
The virtual private network (VPN) gateway options in Azure can help your company meet these connectivity requirements. A virtual private network (VPN) is a type of private interconnected network. VPNs use an encrypted tunnel within another network. They’re typically deployed to connect two or more trusted private networks to one another over an untrusted network (typically the public Internet). Traffic is encrypted while traveling over the untrusted network to prevent eavesdropping or other attacks.
VPN gateways are deployed in Azure virtual networks and enable the following connectivity:
- Connect on-premises datacenters to Azure virtual networks through a site-to-site connection.
- Connect individual devices to Azure virtual networks through a point-to-site connection.
- Connect Azure virtual networks to other Azure virtual networks through a network-to-network connection.
When you deploy a VPN gateway, you specify the VPN type: either policy-based or route-based. Policy-based VPN gateways specify statically the IP address of packets that should be encrypted through each tunnel. This type of device evaluates every data packet against those sets of IP addresses to choose the tunnel where that packet is going to be sent through. If defining which IP addresses are behind each tunnel is too cumbersome, route-based gateways can be used. With route-based gateways, IPSec tunnels are modeled as a network interface or VTI (virtual tunnel interface). IP routing (static routes or dynamic routing protocols) decide across which one of these tunnel interfaces to send each packet. Use a route-based VPN gateway if you need any of the following types of connectivity:
- Connections between virtual networks
- Point-to-site connections
- Multisite connections
- Coexistence with an Azure ExpressRoute gateway
Both types of VPN gateways (route-based and policy-based) in Azure use pre-shared key as the only method of authentication. Both types also rely on Internet Key Exchange (IKE) in either version 1 or version 2 and Internet Protocol Security (IPSec).
With Azure VPN Gateway you will get the following additional benefits:
- VPN Gateway setup can be configured quickly (within an hours) and has no external dependency while configuring connection.
- You can create multiple connections to the same VPN gateway. When you create multiple connections to the same VPN gateway, all VPN tunnels share the available gateway bandwidth.
- VPN gateways can be deployed in Azure Availability Zones. This brings resiliency, scalability, and higher availability to virtual network gateways.
- Guaranteed 99.95% availability for all Gateway for VPN SKUs excluding Basic.
- You can use various tools such as Azure Portal, PowerShell, and Azure CLI to configure Azure VPN Gateway.
- You can use the VPN troubleshoot tool in Azure Network Watcher to diagnose problems with virtual network gateway connections
It is also important to consider the following limitations while using Azure VPN Gateway:
- Each virtual network can have only one VPN gateway.
- The VPN Gateway connectivity is dependent on your Internet connection and hence failure or latency in your internet connection will impact your VPN Gateway connection.
The capabilities of your VPN gateway are determined by the SKU or size that you deploy. Basic VPN Gateway SKU should only be used for Dev/Test workloads as it supports maximum 10 tunnels and 100 Mbps throughput. Other SKU supports maximum 30 S2S/VNet-to-VNet connections and throughput ranging from 650 Mbps to 10 Gbps maximum.
You’ll need these Azure resources before you can deploy an operational VPN gateway:
- Virtual network. Deploy an Azure virtual network with enough address space for the additional subnet that you’ll need for the VPN gateway. The address space for this virtual network must not overlap with the on-premises network that you’ll be connecting to.
- GatewaySubnet. Deploy a subnet called GatewaySubnet for the VPN gateway. Use at least a /27 address mask to make sure you have enough IP addresses in the subnet for future growth. You can’t use this subnet for any other services.
- Public IP address. Create a Basic-SKU dynamic public IP address if using a non-zone-aware gateway. This address provides a public-routable IP address as the target for your on-premises VPN device. This IP address is dynamic, but it won’t change unless you delete and re-create the VPN gateway.
- Local network gateway. Create a local network gateway to define the on-premises network’s configuration: where the VPN gateway will connect and what it will connect to. This configuration includes the on-premises VPN device’s public IPv4 address and the on-premises routable networks. This information is used by the VPN gateway to route packets that are destined for on-premises networks through the IPSec tunnel.
- Virtual network gateway. Create the virtual network gateway to route traffic between the virtual network and the on-premises datacenter or other virtual networks.
- Connection. Create a Connection resource to create a logical connection between the VPN gateway and the local network gateway. The connection is made to the on-premises VPN device’s IPv4 address as defined by the local network gateway. The connection is made from the virtual network gateway and its associated public IP address.
To connect your datacenter to a VPN gateway, you’ll need these on-premises resources:
- A VPN device that supports policy-based or route-based VPN gateways
- A public-facing (internet-routable) IPv4 address
There are several ways to ensure you have a fault-tolerant configuration.
- Active/standby — By default, VPN gateways are deployed as two instances in an active/standby configuration, even if you only see one VPN gateway resource in Azure. When planned maintenance or unplanned disruption affects the active instance, the standby instance automatically assumes responsibility for connections without any user intervention.
- Active/active — With the introduction of support for the BGP routing protocol, you can also deploy VPN gateways in an active/active configuration.
- ExpressRoute failover — Another high availability option is to configure a VPN gateway as a secure failover path for ExpressRoute connections. If you would like to know more about ExpressRoute then please read my article “Azure ExpressRoute — All you should know”
- Zone-redundant gateways — In regions that support availability zones, VPN and ExpressRoute gateways can be deployed in a zone-redundant configuration.
You pay for two things: the hourly compute costs for the virtual network gateway, and the egress data transfer from the virtual network gateway.
Virtual network gateway compute costs
Each virtual network gateway has an hourly compute cost. The price is based on the gateway SKU that you specify when you create a virtual network gateway.
Data transfer costs
Data transfer costs are calculated based on egress traffic from the source virtual network gateway.
- If you are sending traffic to your on-premises VPN device, it will be charged with the Internet egress data transfer rate.
- If you are sending traffic between virtual networks in different regions, the pricing is based on the region.
- If you are sending traffic only between virtual networks that are in the same region, there are no data costs. Traffic between VNets in the same region is free.
For more information on Azure VPN Gateway, see the following articles on Microsoft Docs:
