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.

In the above scenario, the 10.1.0.0/16 network is using UDR and is routed to a NVA. The 10.2.0.0/16 network is using Gateway Transit and can also access resources through VPN connections configured on the 10.3.0.0/16 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.

Limitations

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: https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#networking-limits

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
Subnet: 10.87.40.0/23
VPN site subnet: 192.168.183.0/24

Network 2: puzzlesmove
Subnet: 10.0.0.0/24

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

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

Next, under Settings, select Peerings and then Add:

From there, fill out the fields:

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:

[powershell]
(Get-AzureRmVirtualNetwork -ResourceGroupName puzzlesmove-Migrated -Name puzzlesmove).id
[/powershell]

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:

And you should now have connectivity between the networks 🙂

Configuration using PowerShell

The PowerShell way is also quite easy:

[powershell]
$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
[/powershell]