Chapter 3
Azure VPN gateway
Overview
A virtual private network (VPN) gateway is a device that you can use to connect different networks over the internet for secure communications. These can include on-premises networks connected to Azure virtual networks (vNETs) or one Azure vNET connected to another Azure vNET. IPSec/IKEv2 is used to encrypt traffic between networks. In Azure, the service to create VPN gateways is known as the virtual network gateway service.
Azure VPN gateway features
Following are some key concepts and benefits of using a VPN gateway in your Azure design:
Managed gateway When a VPN gateway is deployed in an Azure vNET, the Azure service provisions two or more VMs in an associated subnet called the gateway subnet. These VMs are set up with gateway routing services, route tables based on the configuration of the VPN tunnel, and the Azure vNET in which the gateway is provisioned. The Azure service itself sets up and manages these VMs; you cannot modify or otherwise manage them yourself.
High availability Each Azure vNET supports the use of only one VPN gateway. For high-availability, you can set up the gateway in an active-active architecture and connect it to multiple remote gateways at the same time. The total bandwidth available for use on the VPN gateway depends on its SKU and is shared across all active connections.
Coexistence with ExpressRoute gateway Azure supports two types of gateways: VPN gateways and ExpressRoute gateways. An ExpressRoute gateway enables secure connectivity to on-premises networks over a private connection; in contrast, the VPN gateway uses the public internet to connect networks. After you use the VPN gateway to establish an IPsec/IKE VPN tunnel between two sites, Azure creates routes in the route table based on the subnets defined in the VPN configuration or propagated automatically when the connection is established.
Support for remote work scenarios using a point-to-site VPN connection In addition to a site-to-site (S2S) VPN connection, a VPN gateway also allows you to create a point-to-site (P2S) VPN connection, using OpenVPN, IKEv2, or SSTP. This allows you to connect to the vNET directly over your home or remote network to access resources using their private internal IPs.
Support for availability zones Azure VPN gateway supports deployment in availability zones, bringing the scalability, resiliency, and redundancy features associated with availability zones to the VPN gateway. When a VPN gateway is deployed in an availability zone, it is physically and logically separated within a region, thereby protecting the service against zonal failures.
Support for Azure PowerShell, Azure CLI, and ARM templates In addition to using the Azure Portal to manage the VPN gateway, you can use Azure PowerShell, Azure CLI, and ARM templates.
Design concepts and deployment considerations
Before setting up a VPN gateway, it is important to identify all your requirements for connectivity. This includes the end clients in scope, throughput required, protocols supported, on-premises firewall or VPN devices available, and support, resiliency, redundancy, and authentication mechanisms required.
After you’ve identified these requirements, you can use the following table to identify what will be the best solution, including the type of VPN connection (P2S or S2S), the gateway SKU, deployment models, protocols, and so on.
| Point-to-Site | Site-to-Site |
Azure-Supported Services | Cloud services and virtual machines (VMs) | Cloud services and VMs |
Typical Bandwidths | Based on the gateway SKU | Typically < 1 Gbps aggregate |
Protocols Supported | Secure Sockets Tunneling Protocol (SSTP), OpenVPN, and Internet Protocol Security (IPsec) | IPsec |
Routing | Route-based (dynamic routing) | Policy-based (static routing) and route-based (dynamic routing) |
Connection Resiliency | Active-passive | Active-passive and active-active |
Typical Use Case | Secure access to Azure vNETs for remote users | Dev, test, and lab scenarios and small- to medium-scale production workloads for cloud services and VMs |
The following sections discuss in more detail the various components and design elements to consider in order to design and deploy the most appropriate VPN solution for your environment.
VPN types
Azure supports two types of VPNs: route-based and policy-based. The type of VPN you select will depend on your VPN connection requirements. P2S connections support only route-based VPNs, whereas S2S connections support both route-based and policy-based VPNs.
Policy-based VPNs support only one VPN tunnel and require the use of the Basic SKU, so it has fewer use cases. In contrast, route-based VPNs support both P2S and S2S connections simultaneously, although other available features and tunnels depend on the gateway SKU.
There’s one more important difference between these VPN types: In a policy-based VPN, static routing is defined using an access list, whereas in a route-based VPN, routes are dynamically added (or removed) from the route table when a connection is established (or shut down).
Gateway SKUs
There are different SKUs available for VPN gateways. The one you choose will be based on your organization’s throughput, features, and SLA requirements.
The Basic SKU is recommended for test and dev workloads. Other SKUs, starting with VPNGw1, are recommended for production environments. Which of these SKUs you choose will depend on the feature set you require. For example, the VpnGw1AZ SKU supports availability zones, whereas the VpnGw2 SKU does not. However, the VpnGw2 SKU allows for greater throughput (1 Gbps compared to 650 Mbps).
You can switch between SKUs in the same generation. For example, you can switch from a VpnGw1 gateway to a VpnGw2 gateway. However, you cannot switch from a VpnGw1 gateway to a VpnGw2AZ gateway.
Connection types
VPN gateway devices support four connection types, as follows:
IPsec Use this to establish an S2S connection with an on-premises gateway device.
Vnet2Vnet Use this to interconnect two Azure vNETs using a VPN gateway.
ExpressRoute Use this when the gateway type is set to ExpressRoute to establish connections between secure private networks and Azure.
VPNClient Use this to establish a P2S connection between a client device and the VPN gateway device.
Gateway subnet
Before you provision a VPN gateway, you need to create a special subnet, called a gateway subnet, to host it. The gateway subnet is set up as part of the Azure vNET address space. It can be a subnet as small as /29, but it is generally recommended to size it to /26 or /27 to handle active-active configuration scenarios that require the deployment of additional VMs to handle redundancy.
Border Gateway Protocol (BGP)
Border Gateway Protocol (BGP) is a standard routing protocol that supports route exchange between connected networks called BGP peers or neighbors. This requires both ends of the connection to support BGP; its use with Azure VPN gateways is optional.
The primary advantages of using BGP are as follows:
Dynamic routing BGP enables the Azure VPN gateway to support dynamic routing. Route exchange can then occur to update either end of the connection, in the event modifications to the routing paths occur due to network changes or outages.
Better control over network access BGP allows you to declare only the IP address prefixes to which you want to give access instead of opening access to the entire IP address prefix in the on-premises or Azure network. This allows you to better control traffic between both sites.
Support for multiple active tunnels After you set up BGP on the on-premises network, you can set up multiple active-active or active-standby connections to the on-premises network or Azure network to increase redundancy and resiliency in both environments. Traffic is automatically routed via the active tunnels on either end.
Support for transit routing Regardless of whether networks are connected to each other directly or indirectly, BGP enables gateways to automatically learn and propagate IP address prefixes across all networks. This enables you to set up transit routing between the Azure VPN and on-premises networks and other interconnected networks.
Local network gateways
Local network gateways are gateways set up in Azure that represent your on-premises gateway device and corresponding networks. It is referenced in the gateway configuration when you set up the VPN tunnel. Generally, you need only define the public IP address of the on-premises VPN gateway, the shared secret to use for the connection, and the IP address prefixes to allow from the on-premises network.
However, if you use BGP, additional configuration is required. Specifically, you must define a BGP peer IP address and an autonomous system number (ASN). You need not, however, define the IP address prefixes located in the on-premises network; BGP allows these IP ranges to be added to the route table in Azure automatically.
VPN gateway redundancy
Even when you deploy Azure VPN gateway without the active-active configuration, the service deploys two VPN instances in an active-standby configuration to facilitate any planned or unplanned events that might hamper the functioning of the active instance.
While the switchover to the standby instance is automatic, it does cause a brief interruption in service as all the S2S VPN tunnels are re-established. In a planned maintenance scenario, this can take up to 15 seconds, but might be longer if the outage is unplanned. In that scenario, it can take up to 3 minutes to bring the VPN services back online.
Be aware that any active P2S connections are dropped during such an event, and they are not reestablished automatically. Rather, the end client must initiate the reestablishment of the connection.
Deployment models
VPN gateway connections support different deployment models. You select a deployment model based on your organization’s security, redundancy, and connectivity requirements. To help you make a more-informed decision, the following sections review these deployment models.
Site-to-site VPN gateway connections
You set up a site-to-site (S2S) VPN gateway connection over IPsec/IKE to connect on-premises gateway devices to Azure VPN gateway devices. Both the on-premises gateway device and the Azure gateway device must be associated with a public IP address. You can configure an Azure VPN gateway in active-standby mode or active-active mode, depending on your redundancy requirements and cost limitations.
Single-site active-standby mode
In an active-standby configuration, both tunnels are configured as online, but only one tunnel is active; the other is in standby mode. (See Figure 3-1.) If the active tunnel goes down, the standby tunnel becomes active and is then used to route traffic.
FIGURE 3-1 Single-site active-standby mode.
Multi-site active-Active mode
A variation on the S2S VPN gateway connection is a multi-site VPN connection in which a single active VPN gateway in Azure is connected to multiple on-premises devices in different sites. (See Figure 3-2.) This requires the use of a route-based VPN type, so it does not work with the Basic VPN gateway SKU. The overall throughput available to the gateway device (which is based on its SKU) is shared across all the established connections.
FIGURE 3-2 S2S VPN with multiple on-premises sites.
High Availability (HA) in active-standby mode
In this scenario, the Azure VPN gateway is simultaneously connected to two VPN devices in the same on-premises location. (See Figure 3-3.) The same routes are propagated over both connections, and traffic is routed to the on-premises network using both connections to increase the throughput to the on-premises network. (Note that both on-premises devices must support the use of BGP.) Throughput on the Azure end is restricted based on the gateway SKU selected.
FIGURE 3-3 HA in active-standby mode.
active-active mode
To set up active-active mode, you set the Azure VPN gateway to active-active mode. This results in multiple active connections to the Azure VPN gateway from each on-premises location, and traffic is routed through all of them. (See Figure 3-4.) If any tunnel goes offline, traffic is automatically switched to a tunnel that is still active. This must be set up on both the Azure end and on the on-premises end to ensure that routes involving the inactive tunnel are diverted and removed automatically. (Note that BGP is required for both the Azure gateways and the on-premises ones for route propagation.) This mode increases redundancy and resiliency on the Azure end and ensures there is no disruption in services during planned or unplanned maintenance activities in Azure.
FIGURE 3-4 Azure VPN Gateway in active-active mode.
HA in active-active mode
With this “full mesh” mode, two Azure gateways are connected to two on-premises gateways. Any failure in any device on either end will automatically result in the routing of traffic via devices that are still active. (Note that BGP is required for route propagation.) In the scenario shown in Figure 3-5, four S2S tunnels are used. It is important to take this into consideration when choosing gateway SKUs and the limits associated with each.
FIGURE 3-5 On-premises to Azure VPN gateway connectivity in HA.
Point-to-site VPN gateway connections
P2S VPN gateway connections help organizations address work-from-home or remote-work scenarios in which employees must be able to securely connect and access internal resources hosted in Azure or on interconnected on-premises networks. With P2S connections, devices need not be directly connected over a public IP. Client devices simply require an active internet connection and the ability to connect to the Azure endpoint over SSL.
Supported protocols
The following protocols are supported for P2S connections:
OpenVPN Protocol The OpenVPN protocol is an SSL/TLS-based VPN protocol that works over most firewalls because it requires only port 443 (which most firewalls leave open). You can use the OpenVPN protocol to connect from Android, iOS (versions 11.0 and above), Windows, Linux, and Mac devices (macOS versions 10.13 and above).
Secure Socket Tunneling Protocol (SSTP) SSTP is a proprietary TLS-based VPN protocol. Like the OpenVPN protocol, SSTP works over most firewalls because it requires only port 443. The difference: Only Windows devices use SSTP. Azure supports all versions of Windows that have SSTP and support TLS 1.2 (Windows 8.1 and later).
IKEv2 VPN IKEv2 VPN is a standards-based IPsec VPN protocol that can be used to connect from Windows, Android, iOS, and Mac devices (macOS versions 10.11 and above).
Authentication
P2S VPN gateway connections (see Figure 3-6) support three types of authentication mechanisms:
Remote Authentication Dial-In User Service (RADIUS) authentication This requires integration with a RADIUS server for successful authentication.
Native Azure certificate authentication This involves the generation of an enterprise certificate or a self-signed certificate, deployed to the Azure device and to the various end clients to use as part of their connection request.
Native Azure AD authentication This requires the use of the OpenVPN protocol, Windows 10– and Windows 11–based clients, and the Azure VPN client.
FIGURE 3-6 P2S VPN Gateway tunnels.
vNET-to-vNET connections (IPsec/IKE VPN tunnel)
Connecting two Azure vNETs using a VPN gateway on either end establishes a vNET-to-vNET connection. This is similar to connecting an Azure VPN gateway to an on-premises network gateway device but enables you to connect Azure vNETs in the same or different regions, in the same or different subscriptions, and in the same or different deployment models (classic and ARM). (See Figure 3-7.)
FIGURE 3-7 Azure vNET-to-vNET connections using VPN gateway.
Highly Available vNET-to-vNET
Similar to the full-mesh S2S HA in active-active mode, the vNET-to-vNET design supports an active-active gateway between two vNETs. (See Figure 3-8.) This allows for the establishment of four tunnels between the two VPN gateways connected to two vNETs to provide higher availability and resiliency. (Note that BGP is optional in this setup unless transit routing is required.)
FIGURE 3-8 Highly available Azure vNET-to-vNET connections using VPN gateways.
ExpressRoute
This book does not discuss ExpressRoute in detail. Still, it is important to know that ExpressRoute is a connectivity option available for your environment, based on your use case. ExpressRoute allows you to extend your on-premises networks with the help of a connectivity provider directly into the Microsoft cloud over a private connection.
With ExpressRoute, all connectivity occurs over a private network with the most stringent possible SLAs. This makes ExpressRoute connections more secure and reliable than S2S VPN connections. ExpressRoute also provides higher throughputs and lower latency, making it ideal for large organizations and for organizations whose security and compliance requirements call for its use.
ExpressRoute and site-to-site VPN gateways can co-exist on the same Azure vNET and can be implemented with an active-failover design, such that issues with ExpressRoute will result in an automated failback to the S2S VPN. The other option is to leverage S2S VPNs for sites that are not covered by ExpressRoute connections. It is important to be aware of this compatibility so that you can take it into account when designing for larger environments in which reliability and redundancy are critical for business.
Zonal and zone-redundant VPN gateways
Azure VPN gateway devices support deployment in Azure availability zones. This extends all the redundancy, scalability, and availability features of availability zones to the vNET gateway devices. When gateway devices are deployed in Azure availability zones, they are separated physically and logically within an Azure region to protect against zone-level failures.
There are two options for availability zones:
Zonal gateways When a VPN gateway is deployed in an availability zone and the availability zone configuration is specified, all instances of the gateway are deployed in that same availability zone. These are called zonal gateways.
Zone-redundant gateways If the availability zone configuration is set to automatic, the VPN gateway is deployed across availability zones, making them zone-redundant to provide higher resiliency.
Azure VPN gateway walkthrough
The following sections walk you through the process of creating an Azure VPN gateway using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including a unique Azure VPN gateway name for each of your deployments. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources.
Using the Azure Portal
To create an Azure VPN gateway using the Azure Portal, follow these steps:
Log into the Azure Portal, type virtual network gateway in the search box to locate the service, and select it from the list that appears. (See Figure 3-9.)
FIGURE 3-9 Selecting the virtual network gateway in the Azure Portal.
Click Create or Create Virtual Network Gateway to start the Create Virtual Network Gateway wizard. (See Figure 3-10.)
FIGURE 3-10 Creating the virtual network gateway.
In the Basics tab of the Create Virtual Network Gateway wizard (see Figure 3-11), enter the following information and click Next:
Subscription Select the subscription to host the vNET gateway.
Name Type a name for the vNET gateway. If the name you type is already in use, the wizard will prompt you to enter a different name.
Region Select the Azure region in which you want to create the VPN gateway.
Gateway Type Select the VPN option button.
VPN Type Select the Route-Based option button.
SKU Choose the VpnGw1 SKU. Alternatively, for higher throughput, choose a higher SKU.
Generation Select the SKU’s generation. (The options available will depend on the SKU you choose.)
Virtual Network Select the virtual network you want to use to host the VPN gateway. Alternatively, click the Create New link and follow the prompts to create a new vNET.
Gateway Subnet Address Range Enter an address range for the gateway subnet. This will be used to assign a private IP address to your VPN gateway.
Public IP Address Select whether to create a new public IP address or use an existing one. If you want to select an existing IP, you will have to ensure that it is a static public IP on the Standard SKU.
Enable Active-Active Mode Select the Disabled option button.
Configure BGP Select the Disabled option button (unless BGP is required for the on-premises firewall that you will integrate).
FIGURE 3-11 The Basics tab of the Create Virtual Network Gateway wizard.
In the Tags tab (see Figure 3-12), enter any tags required for the vNET gateway or leave the fields blank. Then click Next: Review + Create.
FIGURE 3-12 The Tags tab of the Create Virtual Network Gateway wizard.
On the Review + Create tab (see Figure 3-13), review your settings and click Create.
FIGURE 3-13 The Review + Create tab of the Create Virtual Network Gateway wizard in the Azure Portal.
Azure builds the new vNET gateway. Be aware that this can take 30 to 45 minutes.
After Azure builds the new vNET gateway, click Go to Resource.
In the left pane of the vNET gateway’s configuration blade, click Connections. (See Figure 3-14.)
FIGURE 3-14 Creating connections in the vNET gateway.
Click Add to create a new site-to-site VPN tunnel.
The Add Connection options open. (See Figure 3-15.)
FIGURE 3-15 The Add Connection options.
In the Name box, enter a unique name for the connection. If the name you type is already in use, the dialog box will prompt you to enter a different name.
Open the Connection Type drop-down list and select Site-to-Site (IPsec).
The Azure service automatically adds the vNET gateway. Now you need to create a new local network gateway to contain the details of your on-premises firewall.
In the Add Connection options, click Local Network Gateway.
Under Choose Local Network Gateway, click Create New. (See Figure 3-16.)
FIGURE 3-16 Creating a new local network gateway.
In the Create Local Network Gateway options (see Figure 3-17), enter the following information. Then click OK:
Name Enter a unique name for the local network gateway. If the name you type is already in use, you will be prompted to enter a different name.
Endpoint Choose IP Address or FQDN, depending on your on-premises firewall requirements.
IP Address Enter the IP address for the on-premises firewall that you will integrate with.
FIGURE 3-17 Creating a local network gateway.
Address Space Enter the address space for the on-premises networks that should be allowed to connect to Azure resources via this VPN connection.
Back in the Add Connection options, enter the following information and click OK:
Shared Key (PSK) Enter the shared key that will be used to connect with the on-premises firewall.
Use Azure Private IP Address Leave this unchecked.
Enable BGP Leave this unchecked unless your on-premises firewall supports BGP.
IKE Protocol Select the IKE protocol that is suitable for your on-premises firewall.
Ingress NAT Rules Leave this at the default setting.
Egress NAT Rules Leave this at the default setting.
After Azure creates the connection, click the Download Configuration button in the connection’s blade. (See Figure 3-18.) This downloads the instructions for setting up your on-premises firewall with the VPN gateway in Azure.
FIGURE 3-18 Downloading the instructions to set up the on-premises firewall with the VPN gateway in Azure.
Follow the instructions you just downloaded to configure the on-premises firewall.
After you configure the on-premises firewall, Azure changes the status of the connection to Connected. (See Figure 3-19.)
FIGURE 3-19 The status of the connection is Connected.
Using Azure PowerShell
You can create a vNET gateway and connection using Azure PowerShell with the New-AzVirtualNetworkGateway and New-AzVirtualNetworkGatewayConnection commands and various switches. The following code shows you how. Use this snippet to create the same VPN gateway and connection as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous vNET gateway or give this new vNET gateway a different name:
#Define variables $rg = "RG01" $location = "East US" $vpngwname = "TTL_MA-GW" $vnet = "vNET01" #Create GatewaySubnet Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.1.0/24 -VirtualNetwork $vnet #Create public IP for VPNGW $gwpip= New-AzPublicIpAddress -Name TTL-MA-GW-PIP -ResourceGroupName $rg -Location $location -AllocationMethod Dynamic #Create VPNGW configuration $subnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet $vpngwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name vpngwipconfig1 -SubnetId $subnet.Id -PublicIpAddressId $gwpip.Id #Create the VPN GW New-AzVirtualNetworkGateway -Name $vpngwname -ResourceGroupName $rg -Location $location -IpConfigurations $gwipconfig -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 #Create Local Network Gateway $local = New-AzLocalNetworkGateway -Name DC1 -ResourceGroupName $rg -Location $location -GatewayIpAddress 104.42.18.130 -AddressPrefix "10.104.0.0/24" #Create site-to-site connection New-AzVirtualNetworkGatewayConnection -Name MA-DC1 -ResourceGroupName $rg -Location $location -VirtualNetworkGateway1 $vpngwname -LocalNetworkGateway2 $local -ConnectionType Ipsec -RoutingWeight 10 -SharedKey 'abcde12345'
Using the Azure CLI
You can create a vNET gateway using the Azure CLI with the az network vnet-gateway create command and various switches to set the VPN gateway’s parameters. The following Bash script shows you how. Use this snippet to create the same VPN gateway as you did in the previous sections. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous vNET gateway or give this new vNET gateway a different name:
#Define variables $rg = "RG01" $location = "East US" $vpngwname = "TTL_MA-GW" $vnet = "vNET01" #Create GatewaySubnet az network vnet subnet create --vnet-name $vnet -n GatewaySubnet -g $rg --address-prefix 10.0.1.0/24 #Create public IP for VPNGW az network public-ip create -n TTL-MA-GW-PIP -g $rg --allocation-method Dynamic #Create VPNGW gateway az network vnet-gateway create -n $vpngwname -l $location --public-ip-address TTL-MA-GW-PIP -g $rg --vnet $vnet --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased --no-wait #Create Local Network Gateway az network local-gateway create -g $rg -n DC1 --gateway-ip-address 104.42.18.130 --local- address-prefixes 10.104.0.0/24 #Create site-to-site connection az network vpn-connection create --name MA-DC1 --resource-group $rg --vnet-gateway1 $vpngwname -l $location --shared-key abcde12345 --local-gateway2 DC1
Best practices
Following are some best practices for maintaining and managing Azure VPN gateways:
Enable logging for VPN gateway routing activities VPN gateway logs all network traffic that it processes for customers. However, you should also activate NSG flow logging to capture and monitor this traffic for better visibility and management.
Set up resource logging Use Azure Security Center and Azure Monitor to capture all activity logs for the VPN gateway to assist in investigations when required.
Standardize with Azure Policy Azure Policy helps in standardizing the Azure environment to match company policies and standards for workload deployment and maintenance. Use Azure Policy to ensure that VPN gateways are deployed in line with those standards.
Perform penetration testing Conduct regular penetration-testing attacks against the VPN gateway to identify weaknesses or possible loopholes. These controlled simulations can help you proactively identify and address weaknesses and defend the company from breaches and attacks.
Integrate with Log Analytics for long-term log retention Integrate Azure VPN gateway devices with Azure Log Analytics workspaces to store VPN gateway logs for an extended duration to facilitate historical analysis of network patterns, trends, and planning.
Integrate with SIEM for security monitoring Azure VPN gateway has no built-in features to monitor or manage security. To monitor VPN gateway traffic logs for security breaches and threats, you need to forward those logs to a security information and event management (SIEM) solution, such as Azure Sentinel or a third-party provider.