When you deploy virtual machines in Microsoft Azure, you connect them to each other and to external sources, such as the Internet, using Virtual Networks (VNet). Architects have sought ways to connect virtual machines in different vNets to enable applications to span data centers in different regions.
Microsoft announced at TechEd North America that this functionality was added in Microsoft Azure. In this article, I will explain what a VNet-to-VNet Virtual Private Network (VPN) is, why you’d consider using one, and what you should consider before you start designing one.
What is a Virtual Network?
A VNet is the mechanism that is used by Microsoft Azure to network virtual machines. Instead of opening a helpdesk ticket to get Microsoft network engineers to create VLANs for you, Microsoft Azure uses software-defined networking (SDN) that lets you create your own networks that are made up of multiple subnets. These subnets are automatically routed to each other using the first IP address in their range. And by default, virtual networks are isolated.
A VNet and subnets in Microsoft Azure (Image: Aidan Finn)
How does this isolation work? Let’s learn with an example. A virtual network called VNet1 is created. It has 3 subnets: 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24. A virtual machine called VNet1VM01 is deployed in the first subnet with an IP address of 10.0.1.1.
A second virtual machine called VNet1VM02 is created in the second subnet with an IP address of 10.0.2.1. Both virtual machines are able to communicate with each other, assuming that the guest OS firewall permits it. There is free flow of traffic between subnets within a VNet.
Now, we create a second virtual network called VNet2. This VNet has a subnet with an IP address of 10.0.4.0/24. We deploy a virtual machine called Net2VM01 onto this VNet and it gets an IP address of 10.0.4.1. There is no communication path between the virtual machines in VNet1 and VNet2. There is no routing and no connection between the VNets. But maybe we need a connection and this is why Microsoft gave us the ability to deploy VNet-to-VNet VPN connections.
VPN-to-VPN Connectivity: A Common Requirement
According to Microsoft, VPN-to-VPN connectivity was one “of the two most requested features for Azure Virtual Network.” There are a two ways that we might use this functionality:
- Connect VNets in the same Microsoft Azure region
- Enable communications between VNets in different Microsoft Azure regions
With this feature, Microsoft has provided us with the ability to create a site-to-site VPN between two VNets, no matter whether they are in the same Microsoft Azure region or not. This enables open routing between the two connected VNets with no filters via an encrypted tunnel. If you need additional filters, then you need to use the same mechanisms that you would use within a VNet, namely using a guest OS Firewall or IPsec.
The option of connecting VNets within a region might be useful if you have deployed two cloud services, possibly even in different subscriptions, and you need to enable communications between two different VNets in the same data center region.
The multi-region option is more interesting. Imagine that you deploy VNets in different regions. Maybe you sell product online in North America. And maybe you also sell product to customers in Asia. You can create instances of your application in both of those regions and join them together to have a single service with a geo-distributed presence.
Maybe you work in an international corporation that requires application servers to be relatively local. No problem, just deploy virtual machines into a VNet in a local Microsoft Azure region. Corporations require connectivity to enable collaboration. You create a WAN-like experience between your regionalized VNets to enable modern working methods between your offices.
Imagine that you are deploying your entire service into Microsoft Azure. That service is your business. If you lose that service, then your company goes out of business. If you have downtime, then your company loses revenue. You can potentially protect yourself by enabling replication into another region.
For example, you might replicate services from north Europe west Europe, or from west United States to east United States. Although your services are still in Azure, then you have the ability to use a VNet-to-VNet VPN to replicate data from VMs in one region to another.
Spanning regions using VNet-to-VNet VPN (Source: Microsoft)
VNet-to-VNet Restrictions and Guidelines
There are several different considerations to think about when using VNet-to-VNet VPNs:
VNet-to-VNet VPNs are pretty much the same as site-to-site VPNs in Azure, as their sole purpose is to enable VPN connectivity into virtual machines that are connected to the VNet. If you want to enable access to other services, such as Online Backup then you need to consider using ExpressRoute, a partner driven MPLS WAN solution, instead.
A VNet uses a gateway as a connection for inbound VPN connections. You can choose between static and dynamic routing when creating a gateway. You must choose the dynamic routing option.
On-Premises Network Not Required
You do not need anything outside of Microsoft Azure to connect two VNets together via a VPN. You do not need to configure a site-to-site VPN from your on-premises network.
Simultaneous VPN Connections
A single VNet can support up to 10 VPN tunnels. This means that a VNet can simultaneously connect to multiple VNets and your on-premises network.
Networks Address Spaces
You must ensure that each network, be it a VNet or your on-premises network, do not have overlapping IP addresses for a VPN connection to succeed. Think about it: You need to be able to route from one network to another, and this would not be possible with overlapping address ranges.
Subscriptions and Regions
The VNets that are being connected by VPN tunnels can be in different regions or even in different Microsoft Azure subscriptions. This enables a single company to have complex transcontinental or international architectures. It also allows companies or divisions with separate budgets to merge their services into one or to interact more closely over a private network.
For those of you with multiple MSDN accounts, now you have a way to merge your small monthly Microsoft Azure benefits!
And if you’d like to experiment with or demonstrate multi-site clustering, now you have the means to do so.
Spanning Virtual Networks
Cloud services and load balanced endpoints must reside in a single virtual network.
A virtual network can have a single gateway for VPN connections. All bandwidth is shared and the SLA is shared.