Cloud Computing

Connect Two Azure Resource Manager Virtual Networks Using VNet Peering


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).


Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts on our website.


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]
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:

  1. Open the settings of a virtual network and browse into Peerings.
  2. Click Add.
  3. Give the peering connection a name; I try to use the names of the two VNets with the first one being the origin.
  4. 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]
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]
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.

If virtual machines are failing to route with each other then check your network security groups to ensure that the traffic is allowed to and from the required virtual NICs/subnets.

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.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

Office 365 Coexistence for Mergers & Acquisitions: Don’t Panic! Make it SimpleLive Webinar on Tuesday, November 16, 2021 @ 1 pm ET

In this session, Microsoft MVPs Steve Goodman and Mike Weaver, and tenant migration expert Rich Dean, will cover the four most common steps toward Office 365 coexistence and explain the simplest route to project success.

  • Directory Sync/GAL Sync – How to prepare for access and awareness
  • Calendar Sharing – How to retrieve a user’s shared calendar, or a room’s free time
  • Email Routing – How to guarantee email is routed to the active mailbox before and after migration
  • Domain Sharing – How to accommodate both original and new SMTP domains at every stage

Aimed at IT Admins, Infrastructure Engineers and Project Managers, this session outlines both technical and project management considerations – giving you a great head start when faced with a tenant migration.the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

Sponsored by: