In this post I will show you how to link two virtual networks using VNet Peering, a new feature in Microsoft Azure.
What Is VNet Peering?
VNet Peering is the easiest and best performing way to connect two virtual networks (VNets). The alternative, VNet-to-VNet VPN, requires that you deploy gateways in each of the connected VNets. Then you must create a VNet tunnel between the two VNets. Because you must use a gateway, the VPN option limits network speeds between the VNets to the bandwidth capabilities of the gateway — 80 Mbps in the case of a Basic gateway (not 100 Mbps as often documented).
VNet peering links VNets using the underlying software-defined network, tunnelling packets across the physical data center networks using NVGRE. This means that you don’t need a gateway, and that two virtual machines in different VNets can communicate at the speed of their NICs (that’s going to be around 25 Gbps for some machines once a current hardware offload preview goes generally available).
Limitations of VNet Peering
My approach to linking VNets is that I always want to use VNet Peerng, but there are times that I must fall back to using VNet-to-VNet VPN. Here are some of the requirements and limitations of VNet Peering:
- VNets in different regions: VNet Peering requires that both VNets must be in the same Azure region.
- Network addresses: The IP address spaces of both VNets must not overlap.
- No A-B-C links: There is no implied transitive linking of VNets. If you link VNet A to VNet B, and VNet B to VNet C, there is no implied routing from VNet A to VNet C. This would require the usage of network virtualization appliances to act as routers, or that you peer VNet A with VNet C.
- Across-subscriptions: You can link two VNets that are in different Azure subscriptions. This can be useful in situations in which a single organisation has multiple Azure subscriptions for budgetary or logistical reasons. Note that the VNets must still be in the same Azure region, and that the user must have administrative rights in both subscriptions.
- ASM and ARM: You can link a classic or Azure Service Management (ASM) VNet with an Azure Resource Manager (ARM) VNet, as long as they are in the same subscription.
- No ASM-ASM links: You cannot peer a classic/ASM VNet with another classic/ASM VNet.
- Charges: There is a micro data transfer charge for traffic that passes between VNets using VNet Peering.
Implementing VNet Peering
One of the reasons that I like VNet Peering is that, once you understand the limitations, deploying VNet Peering is both quick and easy (deploying a VPN gateway can take up to 1 hour). I have deployed two VNets in my lab, one for sales and one for accounting, both in the same region. Their applications were isolated, but now they wish to have some level of integration, and a network connection is required.A peering must be created from each VNet to link it to the other VNet, so you will create two connections:
- Open the settings of a virtual network and browse into Peerings.
- Click Add.
- Give the peering connection a name; I try to use the names of the two VNets with the first one being the origin.
- You have two ways that you can select the other (remote) VNet. If you know the resource ID of the other VNet, you can paste the resource ID of the other VNet in after checking the box for I Know My Resource ID. You can select a subscription that you have administrative access to, and select a VNet from that subscription.
There are four options to note. The first of these disables the VNet peering (and cross-VNet communications) until you are ready to enable it. The other options, used for complex hub/spoke architectures, are as follows:
- Allow Forwarded Traffic: Allow traffic from a location other than the remote VNet to transit the peering into this VNet.
- Allow Gateway Transit: All traffic from a VPN/ExpressRoute gateway into this VNet.
- Use Remote Gateways: Allow virtual machines on this VNet to route via a VPN/ExpressRoute gateway in the other VNet.