Configure Azure Virtual Network Peering

Last week Microsoft announced public preview of VNet Peering feature. After some registration issues, I finally got through to try the feature today. Before diving into configuration, let’s take a look at what VNet Peering actually is, and what scenarios we can use it in.

Until now, when we wanted to connect multiple virtual networks to each other, we had to deploy a Virtual Network Gateway and configure VPN connections between the networks. These Gateways costs money, and we had to pay for outbound traffic between the networks. Depending on the size of the Gateway, we would be limited to either 100 or 200 Mbit between the networks. Add to that, the latency of going through a gateway.

Now that we have VNet Peering, we can ditch the Gateways and route traffic directly between networks. That’s a cost saving right there, Gateways cost at least 23€ per month in West Europe. Traffic between networks, are not limited by bandwidth like VPN Gateways are, and latency is also way better. It’s basically routed just like traffic between VMs on the same network. It’s a win/win/win 🙂 VM bandwidth limits are still enforced of course.
When using VNet Peering, both networks has to allow traffic to flow between them. You are still in full control of your own network, and networks are still managed separately, remember that!

VNet Peering also fully supports:

  • Network Security Groups
  • Network Virtual Appliances (NVA) like Cisco, Baracuda, etc
  • User Defined Routes
  • Internal Load Balancers

And probably more.. Let’s look at some use cases.

Peering between subscriptions

The cool thing about VNet Peering, is that it also works between subscriptions. So if your customers are Azure based, you can do shared environments, and let customers connect directly to your services. This should of course be controlled by Network Security Groups (NSG) or NVA firewalls. See next paragraph for an example configuration. The networks there could easily be in different subscriptions.

Gateway Transit

Another nice feature of VNet Peering, is Gateway Transit. This allows you to use the peer networks VPN Gateway, and route traffic through their VPN connections. The peer network has to allow this of course, and can still limit acces by using NSGs or NVAs. To use this feature, you will need to add your own subnet to the VPN route tables, otherwise it won’t work.

It is important to note that, the network which is using a remote VPN Gateway (in a peered network), cannot have a gateway configured on it’s own network. So if you are using another network VPN Gateway, you can’t have one in your own network.

Borrowed from

In the above scenario, the network is using UDR and is routed to a NVA. The network is using Gateway Transit and can also access resources through VPN connections configured on the network.

Classic to Azure Resource Manager

I’ve recently talked about migrating from Azure Service Management (also known as ASM and Classic), to Azure Resource Manager. VNet Peering is an easy way of doing just that, without doing a “big bang” migration and move everything at once. This could also be achieved by using VPN connections between networks, but you would have a bandwidth cap and higher latency.

A questions I’ve already been asked is, can we do ASM to ASM Peering? No, this is not possible. VNet Peering is only exposed in ARM. You can however peer multiple ASM networks to a single ARM network.


Yes, sorry to say, but there is a few limits to this feature:

  • Virtual Networks that are peered has to be in the same region
  • Peering is between 2 networks, you cannot do peering from A<->B<->C and route traffic between network A and C. If you want this, configure peering between A and C directly.
  • Subnets within each network, cannot overlap, so you still have to plan your networks
  • You can’t do peering between unlimited number of networks. The list haven’t been updated yet, but you should soon be able to see it here:

Because of the region limit, there is still a need to do VNet-to-VNet VPN connections, when you want network connectivity between regions. Within the same region I would however go with VNet Peering.

Configuration using Azure Portal

Let’s look at the configuration! Before starting, make sure you have at least 2 networks, in the same region, and with different subnets configured. In this scenario I have 2 networks – on the same subscription – where 1 of them has a VPN Gateway configured with connection to 1 other site.

Network 1: Cloudpuzzles
VPN site subnet:

Network 2: puzzlesmove

Just to show, there is no connection between the networks:


First I’ll configure Cloudpuzzles network. Go to and find your network:


Next, under Settings, select Peerings and then Add:


From there, fill out the fields:vnetpeering3

Make sure you select the correct subscription and deployment model, as the portal will pull networks from there. When done, click OK and wait for a few seconds for the peering to be added.



If you know the resource ID of the network you want to peer with, you can manually enter this instead of selecting the network. In case you want to find the ID, you can use this PowerShell cmdlet:

(Get-AzureRmVirtualNetwork -ResourceGroupName puzzlesmove-Migrated -Name puzzlesmove).id

Output should be like: /subscriptions/7bce381f-79b3-4521-b36e-000000000000/resourceGroups/puzzlesmove-Migrated/providers/Microsoft.Network/virtualNetworks/puzzlesmove


After configuring Peering, the connection will show up under Settings -> Peerings:


Do the same thing for the peered network, just select the opposite network of course:




Now, note that Status says Connected under Peerings now, instead of Initiated:

Peering Connected
Peering Connected


And you should now have connectivity between the networks 🙂


Configuration using PowerShell

The PowerShell way is also quite easy:

$peeringName = ‘test’
$vnet1Name = ‘Cloudpuzzles’
$vnet1RG = ‘Cloudpuzzles’
$vnet2Name = ‘puzzlesmove’
$vnet2RG = ‘puzzlesmove-Migrated’

$vnet1 = Get-AzureRmVirtualNetwork -Name $vnet1Name -ResourceGroupName $vnet1RG
$vnet2 = Get-AzureRmVirtualNetwork -Name $vnet2Name -ResourceGroupName $vnet2RG

Add-AzureRmVirtualNetworkPeering -Name $vnet2Name -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2.Id
Add-AzureRmVirtualNetworkPeering -Name $vnet1Name -VirtualNetwork $vnet2 -RemoteVirtualNetworkId $vnet1.Id


  1. I am currently trying to move VMs from ASM to ARM. I have vnetASM and vnetARM. I setup peering between them. I stood up a VM in the new vnetARM and I am able to ping a VM in the vnetASM. But I cannot ping from the VM on the vnetASM to the VM on the vnetARM. Is this doable or am I missing something?


  2. Thanks for the article – very useful. This is a great feature but has a major restriction for us. Being a service provider we would like to connect to customer VNets over a peering connection. However the documentation says users from both subscriptions (ours and customers) that setup the peering have to be within the same AD tenant. Can you think of anyway around this as we need our ADs to be separate.


    1. There is currently no other way than using vnet-to-vnet VPN connections in your scenario. I know it’s a topic within the team, to support cross-tenant peering though.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s