How to Use Virtual Private Networks (VPNs) on Azure

Save to My DOJO

How to Use Virtual Private Networks (VPNs) on Azure

In this article, we’re going to look at Virtual Private Networks in Azure and how you can use them. As you may know, a Virtual Private Network or VPN is an encrypted tunnel over the Internet or other shared networks, for example, a telco provider network.

VPNs use different technologies to encrypt the traffic, the most common ones are IPSec and OpenVPN SSL.

VPNs can connect branches (“sites”), and/or clients devices to a corporate network. Branch and Site VPN connections are most called Site-to-Site or S2S VPNs and are generally permanently connected. User and Device VPN tunnels are called Point-to-Site or P2S VPNs and are normally initiated by the user or automatically by an application but are disconnected after they’re no longer in use.

In Azure, you can have and use both types of VPNs but depending on the solution of choice it can be a different setup.

Let us first explore the VPN Service and Device Options you have in Azure.

VPN Services and Devices

In Azure there are three different options to build VPNs:

    • Using Virtual Network Gateways
    • Using Azure Virtual WAN
    • Using Network Virtual Appliances

All of them are capable of both Point-to-Site and Site-to-Site connections but they have different infrastructures underneath each of them.

Virtual Network Gateway

Virtual Network Gateways are a classic approach, that many network architects are familiar with. You deploy one VPN Virtual Network Gateway Service within a Virtual Network. That service combines Point-to-Site and Site-to-Site Gateways and can be deployed in different sizes.

Here’s a list of different VPN Gateway SKUs:

VPN
Gateway
Generation
SKU S2S/VNet-to-VNet
Tunnels
P2S
SSTP Connections
P2S
IKEv2/OpenVPN Connections
Aggregate
Throughput Benchmark
BGP Zone-redundant
Generation1 Basic Max. 10 Max. 128 Not Supported 100 Mbps Not Supported No
Generation1 VpnGw1 Max. 30* Max. 128 Max. 250 650 Mbps Supported No
Generation1 VpnGw2 Max. 30* Max. 128 Max. 500 1 Gbps Supported No
Generation1 VpnGw3 Max. 30* Max. 128 Max. 1000 1.25 Gbps Supported No
Generation1 VpnGw1AZ Max. 30* Max. 128 Max. 250 650 Mbps Supported Yes
Generation1 VpnGw2AZ Max. 30* Max. 128 Max. 500 1 Gbps Supported Yes
Generation1 VpnGw3AZ Max. 30* Max. 128 Max. 1000 1.25 Gbps Supported Yes
Generation2 VpnGw2 Max. 30* Max. 128 Max. 500 1.25 Gbps Supported No
Generation2 VpnGw3 Max. 30* Max. 128 Max. 1000 2.5 Gbps Supported No
Generation2 VpnGw4 Max. 30* Max. 128 Max. 5000 5 Gbps Supported No
Generation2 VpnGw5 Max. 30* Max. 128 Max. 10000 10 Gbps Supported No
Generation2 VpnGw2AZ Max. 30* Max. 128 Max. 500 1.25 Gbps Supported Yes
Generation2 VpnGw3AZ Max. 30* Max. 128 Max. 1000 2.5 Gbps Supported Yes
Generation2 VpnGw4AZ Max. 30* Max. 128 Max. 5000 5 Gbps Supported Yes
Generation2 VpnGw5AZ Max. 30* Max. 128 Max. 10000 10 Gbps Supported Yes

As you can see, picking the right size depends on several factors, including the expected number of connected users/sites as well as your aggregate bandwidth internet connections.

Depending on the SKU, gateways are deployed with different sets of features. Normally Virtual Network Gateways are deployed in a pair, in an active/standby configuration without using Availability Zones in Azure. To use Availability Zones, you need to use a SKU with AZ at the end. If you want to switch from one SKU to another, that will require a 45-minute downtime. A switch from non-Availability Zone to Availability Zone will require a complete redeployment of the Virtual Network Gateway, which can take up to 2 hours.

Azure Virtual Network Gateway supports the following encryption standards for Site-to-Site tunnels.

IPsec/IKE policy for S2S VPN & VNet-to-VNet connections: PowerShell – Azure VPN Gateway | Microsoft Docs

If you want to use Point-to-Site it supports OpenVPN (SSL/TLS-based), Secure Sockets Tunneling Protocol (SSTP) or IKEv2 VPN, more information is available here:

About Azure Point-to-Site VPN connections – Azure VPN Gateway | Microsoft Docs

Azure Virtual Network Gateways are a traditional and proven way to deploy VPN solutions Azure, but they are not as flexible as other solutions.

Virtual WAN

In comparison to Azure Virtual Network Gateways, Virtual WAN Gateways work differently. The first major difference is that Virtual WAN makes a distinction between Point-to-Site Gateways and Site-to-Site Gateways. While in Azure Virtual Network Gateways both Gateways are one service, in Virtual WAN you have different Gateways for each use case.

Virtual WAN

Another major difference is that Azure Virtual WAN Gateways are deployed in scale units. These units can be scaled up and down on-demand, without any service interruption.

Edit VPN Gateway

 

Edit VPN Gateway

Another great feature is, that Virtual WAN Network Gateways are always deployed as highly available as possible. These Gateways are deployed in Virtual Machine Scale Sets and are by default deployed in Availability Zones if the Azure Region supports them. If an Azure Region does not yet support Azure Availability Zones, the Virtual Network Gateways are deployed in Availability Sets and as soon as the region supports Availability Zones, the backend is updated automatically.

Azure Virtual WAN Site-to-Site Gateways supports the following IPSec encryption standards.

Virtual WAN Site-to-site IPsec policies – Azure Virtual WAN | Microsoft Docs

Virtual WAN Site-to-Site Gateway can scale up to 20 Gbps throughput and 1.25 Gbps encryption capacity per VPN tunnel.

Point-to-Site Virtual WAN Gateways support IPSec and OpenVPN as listed below.

Virtual WAN Point-to-site IPsec policies – Azure Virtual WAN | Microsoft Docs

You can have up to 200 Scale units supporting 100,000 clients. The payment model for Virtual WAN Point-to-Site Clients is by connected users per minute. So, it’s completely paid as you go per connected user plus the amount of Gateway Scale Units.

With Virtual WAN, there is another very important point, routing between Site-to-Site VPN, Point-to-Site VPN and ExpressRoute Gateways is enabled by default without any additional efforts by the customer. You can get more details via the link below.

Architecture: Global transit network architecture – Azure Virtual WAN | Microsoft Docs

Network Virtual Appliances

Network Virtual Appliances are Virtual Machines running in a classical Virtual Network or Azure Virtual WAN. Those Appliances are third party and are available via the Microsoft Azure Marketplace.

Azure Virtual WAN: About Network Virtual Appliance in the hub | Microsoft Docs

Deploy highly available NVAs – Azure Architecture Center | Microsoft Docs

Those appliances are harder to integrate and make highly available. The configuration is completely the responsibility of the customer, but for certain scenarios, they can offer major benefits for customers. One major selling point is if your organization has already standardized on a particular vendor/appliance, using the same one in Azure will ensure consistency and lower the learning curve for your network engineers.

Those appliances are mostly supporting additional features like Quality of Service, special encryption protocols or VPN Client tunnel optimization. For example, Barracuda Networks uses its own VPN Tunnel and encryption protocol TINA between their appliances and devices.

TINA VPN Tunnels | Barracuda Campus

Then there are appliance partners who offer great VPN clients with additional features like filtering, split tunnelling by service or traffic optimization. Examples are Palo Alto Global Protect or FortiGate FortiClient.

GlobalProtect App for Windows (paloaltonetworks.com)

Product Downloads | Fortinet Product Downloads | Support

Those appliances are much harder to integrate into a classic hub and spoke environment, with Virtual WAN the process of deployment is more automated. If you use those NVAs, you also have additional license costs for the appliances, which must be paid to the OEM.

As already mentioned, feature sets of those Network Virtual Appliances are often much richer than with bare Azure Virtual Network Gateways and Virtual WAN Gateways.

How to Deploy a VPN

Let me guide you on how to deploy a VPN Tunnel with the different service offerings. As the nature of the three solutions is completely different, I will split them up into three separate parts.

Virtual Network Gateway

As there is already a lot of deployment documentation out there, I will not create a new one. Let me just point you to the right resources, so that you can start and deploy according to Microsoft best practices.

Tutorial – Create and manage a VPN gateway: Azure portal – Azure VPN Gateway | Microsoft Docs

Tutorial – Connect on-premises network to virtual network: Azure portal – Azure VPN Gateway | Microsoft Docs

Configure an Always-On VPN user tunnel – Azure VPN Gateway | Microsoft Docs

Configure an Always-On VPN tunnel – Azure VPN Gateway | Microsoft Docs

Additional documentation is available here.

VPN Gateway documentation | Microsoft Docs

Virtual WAN

With Virtual WAN, you also have a bunch of great documentation which goes into more detail. You can find the necessary documentation linked below.

Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections | Microsoft Docs

Tutorial: Use Azure Virtual WAN to create a Point-to-Site connection to Azure | Microsoft Docs

Additional configurations for Point-to-Site in Virtual WAN can be found here.

Configure a P2S User VPN connection using Azure Active Directory authentication – Azure Virtual WAN | Microsoft Docs

Azure AD tenant for User VPN connections: Azure AD authentication – Azure Virtual WAN | Microsoft Docs

Configure an Always-On VPN user tunnel – Azure Virtual WAN | Microsoft Docs

Configure an Always-On VPN tunnel – Azure Virtual WAN | Microsoft Docs

I would also encourage you to take an additional look at the guides already available here on the DOJO.

What is Azure Virtual WAN? (altaro.com)

Azure Virtual WAN vs. Azure Route Server (altaro.com)

Deploy Azure virtual WAN in 2,5 Hours (altaro.com)

How to configure Azure virtual WAN VPN Site-2-Site with unmanaged VPN device (altaro.com)

As an additional option, you can pick a Network Virtual Appliance, if the Appliance of your choice is available in Virtual WAN. I would encourage you to make use of the more PaaS like the approach of Azure Virtual WAN.

Azure Virtual WAN: Create a Network Virtual Appliance (NVA) in the hub | Microsoft Docs

The SysAdmin's Guide to Azure IaaS SE ebook - download your free copy

 

Network Virtual Appliance

The deployment of VPN Connections with Network Virtual Appliances is pretty diverse and depends on the vendor itself. Before I can point you to some example documentation, start with the documentation on how to deploy NVAs.

This documentation describes how to deploy an NVA in Azure.

Deploy highly available NVAs – Azure Architecture Center | Microsoft Docs

You should follow that guide to ensure that the NVA is deployed according to supported standards. As there are a lot of partners out there, please contact the vendor of your choice to get additional guidance.

Palo Alto

The first vendor with very good documentation on the deployment is Palo Alto. You can find their guides below.

Site-to-Site VPN – Set Up Site-to-Site VPN (paloaltonetworks.com)

Point-to-Site VPN – GlobalProtect (paloaltonetworks.com)

FortiNet

Another good NVA partner is FortiNet. You can find their docs below

Site-to-Site VPN – Administration Guide | FortiGate / FortiOS 7.0.1 | Fortinet Documentation Library

Point-to-Site VPN – Administration Guide | FortiGate / FortiOS 7.0.1 | Fortinet Documentation Library

Barracuda Networks

Barracuda is not that common among enterprise customers in Europe but offers a great portfolio of features including their own tunnelling protocol. Please find their docs below.

Site-to-Site VPN – Site-to-Site VPN | Barracuda Campus

Point-to-Site VPN – Client-to-Site VPN | Barracuda Campus

Troubleshooting Azure VPN

Within the Troubleshooting part, I will only concentrate on the troubleshooting guides for Azure Services, as the troubleshooting on NVA is extremely specific to the vendor.

For Azure Virtual Network Gateways, there are two good troubleshooting guides available in Microsoft’s Documentation.

One focuses on connections to Azure Virtual Network Gateways dropping or being unable to connect.

Troubleshoot an Azure site-to-site VPN connection that cannot connect – Azure VPN Gateway | Microsoft Docs

The other guide looks into the stability issues of a VPN tunnel.

Troubleshoot Azure Site-to-Site VPN disconnects intermittently – Azure VPN Gateway | Microsoft Docs

When looking into Azure Virtual WAN is more difficult, as you may not have access to the Monitoring and Troubleshooting logs. So, if you have the need for deeper troubleshooting, it makes sense to engage with Microsoft Support. In any case, you should have good monitoring in place according to documentation.

Monitoring Azure Virtual WAN | Microsoft Docs

Monitoring Virtual WAN using Azure Monitor Insights | Microsoft Docs

VPN Compared to other Microsoft Solutions

Sometimes Customers can confuse Azure VPN with other services available. Most commonly customers confuse Virtual Network Peering and Azure ExpressRoute with VPN Solutions.

Virtual Network Peering

Azure Virtual Network Peering is “only” a peering connection via the Microsoft Global Network between two Virtual Networks in Azure. It uses Software Defined Network technologies to connect the two networks and there is no Virtual Gateway necessary to do so. Virtual Network Peering is only used for interconnecting Virtual Networks within Azure and there is no option to use Virtual Network Peering to connect to the world outside of Microsoft Azure.

To learn more about peering, please visit the documentation below.

Azure Virtual Network peering | Microsoft Docs

Azure ExpressRoute

Microsoft Azure ExpressRoute is like VPN a connection to networks outside of the Microsoft Global Network. Its build to connect Customer Networks with the Microsoft PaaS Network via Peering or the Customer Private IaaS infrastructure using peering and private gateways.

The difference between Azure ExpressRoute and VPN is the fact that ExpressRoute is not leveraging internet connections or shared networks. With ExpressRoute you get a private end to end connection from your on-premises location to the Microsoft Global Network.

Those connections are more expensive but can offer more bandwidth or better Service Level Agreements, depending on your location and network service provider. ExpressRoute is not always better than VPN, always check your use case and your needs.

To be honest, Network Providers like to sell ExpressRoute due to better margins than with premium Internet connections. If you are interested in more information about that topic, you can visit some other articles here on the DOJO.

Microsoft Azure Peering Services Explained (altaro.com)

How to Use Azure ExpressRoute Global Reach to Interconnect Datacenters (altaro.com)

How to use Microsoft Global Network with Oracle, Google or AWS (altaro.com)

To learn more about Microsoft Azure ExpressRoute, you should also consult Microsoft Documentation on ExpressRoute.

ExpressRoute documentation | Microsoft Docs

Decision Tree

As is often the case with Microsoft’s service offerings there are several ways to achieve the same goal, here’s a flowchart I use when talking to customers about this.

Microsoft customer flowchart

That chart should help, at least for the initial discussion and understanding, which solution is best for your situation.

Conclusion

The “right” solution depends on what you want to achieve with your architecture. Often, it’s a decision driven by costs and features. Please also take complexity and maybe newer security requirements and approaches into account.

For example, if you’re searching for RADIUS integration, and the only solution might be costly, maybe it’s better to reconsider the requirement and check if you can achieve the same security requirements with Azure Active Directory Authentication instead.

Enable MFA for VPN users: Azure AD authentication – Azure VPN Gateway | Microsoft Docs

Try to stay open-minded and don’t do things because that’s how it’s been done for years. Always prove requirements against our changing IT world.

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.

cyber security roundtable