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.

Two Azure virtual networks in the same region [Image Credit: Aidan Finn]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.

Create the first VNet peering connection [Image Credit: Aidan Finn]You can wrap things up there and click OK to create the peering. You will then go to the other VNet and repeat the configuration.

Create the second VNet peering connection [Image Credit: Aidan Finn]You should see the peering status of the two VNets switch to Connected after a few minutes. Now virtual machines on each VNet can talk at NIC speeds to virtual machines on the other VNet.

Advanced Configuration

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.

Subscribe to Petri NewslettersOffice 365 Insider

Our Petri Office 365 Insider is dedicated to sharing detailed knowledge from top Office 365 experts. Delivered once a month to your inbox.

Petri.com may use your contact information to provide updates, offers and resources that may be of interest to you. You can unsubscribe at any time. To learn more about how we manage your data, you can read our Privacy Policy and Terms of Service.

Subscribe to Petri NewslettersOffice 365 Insider

Petri.com may use your contact information to provide updates, offers and resources that may be of interest to you. You can unsubscribe at any time. To learn more about how we manage your data, you can read our Privacy Policy and Terms of Service.