Last Update: Sep 04, 2024 | Published: Oct 19, 2016
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.
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:
There are three ways that you can connect applications in two different Azure VNets:
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:
There are some downsides:
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).
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:
On the negative side:
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.
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:
On the negative side:
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.
I would use the following ordering when choosing a solution:
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.