How Can I Connect 2 Azure Virtual Networks?

In this post I will show you how to connect two Azure virtual networks (VNets) together, extending one to another, therefore enabling you to route from virtual machines on one VNet to virtual machines that are connect to another VNet, whether they are in the same region or in different regions.
 

 

Design Considerations

Not all Azure deployments are simple; there can be reasons to deploy Azure solutions into different VNets. A virtual network is isolated from all other virtual networks by default, therefore making it a security boundary. So maybe a customer will decide the segregate applications, not with softer network security groups (NSGs), but with the harder wall provided by a VNet.
A VNet cannot span across Azure regions. So if a business needs to deploy an application across multiple regions for disaster recovery or scale-out reasons, then they must deploy one VNet per region.
Many mid-large customers have non-technical issues to deal with. Maybe different divisions have different IT budgets, and they each get their own Azure subscriptions, each with different spending caps and billing/invoice details. Or maybe company politics are at play; Mary & Bob just don’t get along, so they each instruct their departments to use their own Azure subscriptions. A VNet cannot span a subscription, so any deployments within those subscriptions will be isolated by default.
A time will come when virtual machines in different VNets must be connected. Maybe Mary and Bob or those different divisions must share data? Maybe the database servers in different regions need to replicate? Or maybe the secure applications need to share resources, such as a VPN/ExpressRoute gateway?
There are many reasons to split virtual machine deployments across different VNets, but there probably will come a time when they need to be connected. And this is why I always advise customers to treat each new VNet as a new branch office on a WAN; even if you don’t connect that VNet to the rest of the network today, you probably will tomorrow, even in the smallest of deployments. There are two pieces of advice that I share when planning a single VNet or multiple VNets:

• Every VNet should have a unique network address: Make sure that you use a unique network address for each VNet in Azure, and make sure that there is no overlap with the on-premises networks, either. If the customer is using 10.0.0.0 for on-premises networks, then use 172.16.0.0 in Azure, or vice versa. The customer might not want to have a site-to-site network connection from their LAN to Azure today but things change. And the customer might have no plans to connect two VNets today, but that might change, too. You cannot connect two networks if they use overlapping address ranges; there is no NAT for secure network connections in Azure. Don’t paint yourself into a corner!
• Don’t waste IP addresses: Don’t be the idiot that creates a 10.0.0.0/8 VNet with a single virtual network of 10.0.0.0/8; this will waste more than 16 million IP addresses on a single subnet and waste the entire 10.0.0.0 range on a single VNet. You might need to add subnets (for site-to-site networking or for different NSG security boundaries) and you might want more than one VNet at a later point (it happens).

There are three ways that you can connect applications in two different Azure VNets:

• Route via the Internet
• VNet peering
• Site-to-site VPN

Route via the Internet

This is the least secure option of the three that I am presenting in this post. Each VNet will use the Azure load balancer to share services from one (NAT rules) or more (load balancing rules) virtual machines to the Internet. DNS records will map a name to the public IP address of the load balancer, and virtual machines from other VNets can access these services via the Internet. You can wrap the application traffic using SSL (and optionally offload SSL using the Application Gateway) for some level of security.
The benefits of this solution are:

• It’s pretty simple.
• The virtual networks are isolated from each other.

There are some downsides:

• This is not a private connection; HTTPS traffic might be suitable for this style of connection, but other traffic (e.g., file services, Active Directory) cannot be route in this means. And even if they could; would you want to?
• You have restricted the amount of infrastructure and application integration that can be achieved.
• Virtual machines cannot share data at their full NIC potential.

There is a cost with this solution; any data sent over the Internet (from one VNet to another) will be subject to outbound data transfer charges (a small charge).

VNet Peering

The ability to peer virtual networks is relatively new, and only became generally available at the Microsoft Ignite 2016 conference in September. Peering is a very simple way to just plug two VNets into each other. Once you peer two VNets, virtual machines in those two VNets (even in different subscriptions if you have shared admin rights) can route to each other over the Azure backbone, secure from all other traffic, and probably encapsulated using NVGRE – the protocol that Azure uses for software-defined networking (virtual network isolation) on the physical fabric.
VNet peering allows you to create some interesting designs. For example, you can create a hub-and-spoke, where one VNet uses a gateway to connect to on-premises networks using either a VPN or ExpressRoute; this is the hub VNet. Other VNets (spokes) will connect to the hub using VNet peering, and you can enable them to route via the hub’s gateway; this means that all of your VNets can route to on-premises networks via a single gateway, which results in a simpler site-to-site networking design and reduced gateway charges.

You can still retain levels of isolation using NSGs; while this might not be a default security tool, the rules of an NSG are still hard, under your total control, and can be monitored using logs and the Azure Security Center.
There are lots of benefits to VNet peering:

• It is relatively simple to set up — just create a connection in each direction.
• Cross-VNet traffic is secure, as if it never left the VNet.
• You can get deep infrastructure and application integration.
• Virtual machines can communicate across the peering at the speed of their full NIC potential.

On the negative side:

• VNet peering cannot be used between VNets in different regions.
• There must be shared administration between the subscriptions of both VNets.
• At least one of the peering pair VNets must be deployed using Azure Resource Manager (ARM).

There is a micro-charge for data transfer between peered VNets (inbound and outbound). It is a tiny charge, and probably won’t be a deal breaker for anyone.

VNet-to-VNet VPN

This is the option that was used the most in the past. Quite honestly, past iterations of this solution were very difficult for newcomers to understand. Fortunately, Microsoft recently updated the Azure Portal and made configuring this solution fairly easy to get going.
The concept of a VNet-to-VNet VPN is that you create a gateway in each VNet and create a secure tunnel between each VNet. The technology is well known and trusted: VPN. This encrypted tunnel will allow virtual machines in each VNet to talk to each other.

By default, there are no restrictions on what traffic can flow between the two connected VNets, but you can use NSGs to enforce security policies.
The solution has some benefits:

• VPN is well known and trusted.
• You can connect VNets in different Azure regions and subscriptions.
• You do not need shared administration credentials when dealing with different subscriptions, but there must be some cooperation between the administrators.

On the negative side:

• Communications between the VNets will be limited by the VPN speed of the gateway, which is relatively slow compared to a 1 Gbps NIC.
• You must deploy a gateway in each VNet which incurs more charges (fairly small and predictable)
• You can get a good amount of infrastructure and application integration, but it’s not as good as VNet peering.
• You must use a dynamic/route-based gateway, which would be an issue if you have older on-premises VPN devices that only support static/rule-based VPN connections. Your Azure requirements might force you into replacing your on-premises firewalls if you need VNet-to-VNet VPN and site-to-site VPN connections. Make sure to put pressure on your firewall’s manufacturer!

There are two charges to consider. First there is the gateway, which can be a fairly small charge per month. Data transfer within the same region is free, but traffic moving over the VPN between regions incurs outbound data transfer charges.

My Recommendation

I would use the following ordering when choosing a solution:

1. VNet peering
2. VNet-to-VNet VPN
3. Internet-based routing

My preference would be for simple, fast, and deep integration. But if there are some conflicts, such as the VNets been in different regions, then I have no choice but to go for VNet-to-VNet peering. I have yet to encounter a scenario in which a design has been forced to go to with Internet-based routing, but that might happen one day, and the option is there.