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 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:
|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.
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:
Azure Virtual Network Gateways are a traditional and proven way to deploy VPN solutions Azure, but they are not as flexible as other solutions.
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.
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.
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 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.
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.
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.
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.
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.
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.
Additional documentation is available here.
With Virtual WAN, you also have a bunch of great documentation which goes into more detail. You can find the necessary documentation linked below.
Additional configurations for Point-to-Site in Virtual WAN can be found here.
I would also encourage you to take an additional look at the guides already available here on the DOJO.
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.
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.
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.
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)
Another good NVA partner is FortiNet. You can find their docs below
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.
The other guide looks into the stability issues of a VPN tunnel.
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.
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.
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.
To learn more about Microsoft Azure ExpressRoute, you should also consult Microsoft Documentation on ExpressRoute.
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.
That chart should help, at least for the initial discussion and understanding, which solution is best for your situation.
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.
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.