Azure Virtual Network Peering - What is it and how to use it

Virtual network peering is a new mechanism in Azure Resource Manager that allows two virtual networks from the same region to be connected through the Azure backbone network. From a connectivity standpoint, this mechanism allows virtual machines in separate virtual networks to communicate with each other using private IP addresses. In this post, I will talk about what Virtual Network Peering is and how we can use it.

Before this mechanism existed the method we had to connect two virtual networks was by using a VPN connection and that a lot of complexity to existing deployments and caused headaches on an architectural standpoint. A discussion I had once with a customer was exactly on this problem. The customer wanted hub and spoke type environment where in the hub he could keep core infrastructure resources, and the spokes were the application(s) specific resources. Now you may think this is not a very complicated job, you spin up gateways and connect them with each other, and you’re done. This would have been a solution to the problem, but the cost was enormous and cumbersome from a management standpoint. In the end, the customer accepted the costs of having a VPN gateway in each VNET, and we created the hub and spoke environment that he wanted with the limitations that were present at the time.
If you want to know more about the hub&spoke solution with VPN gateways, you can read this excellent blog post: https://blogs.msdn.microsoft.com/igorpag/2015/10/01/hubspoke-daisy-chain-and-full-mesh-vnet-topologies-in-azure-arm-using-vpn-v1/

So now we have the possibility of peering two virtual networks with each other which opens up the Hub & Spoke scenario to be easily implemented with lower costs than having a VPN gateway in each VNET. Using VNET Peering paired with User Defined Routes opens up the scenario where we have the core infrastructure in the hub and segregated applications in the spokes. The hub can contain NVAs (Network Virtual Appliances), a Site-2-Site VPN to your on-premise environment and other management related resources and the spokes can contain different applications that require a web tier, middle tier, and data tier. The spokes traffic is managed by User Defined routes that direct the traffic towards and back to the NVAs for security purposes. This one type of scenario that can be achieved with VNET peering but there are more options out there ?

VNET Peering is not flawless; it has its limitations, and there are some requirements to fulfill for it to work. Here are the requirements and aspects of VNET Peering:

1. The two virtual networks that are peered should be in the same Azure Region -You cannot peer a VNET from North Europe with one in West Europe, you still need a VPN for that.
2. Virtual networks should not have overlapping IP address spaces which mean that you cannot peer two VNETS that have 10.0.0.0/8 address space. That won’t work.
3. Peering is between two virtual networks and only two virtual networks. You cannot achieve a transitive relationship so if you connect VNET A with VNET B and VNET B with VNET C using VNET peering will not mean that VNET A can directly communicate with VNET C just because it’s peered VNET B.
4. You can peer two VNETS that are in different subscriptions as long as you have the privileges to do that operation on both subscriptions.
5. VNET peering works for ASM deployments and ARM deployments as long as those VNETS are in the same subscription. ASM VNETS cannot peer with each other.
6. Traffic between VNETS is not free (https://azure.microsoft.com/en-us/pricing/details/virtual-network/), but there are no additional limitations.

Now that we understand what are the key aspects and requirements of Virtual Network Peering let’s see how we can peer two VNET’S with each other.

One of the options of peering two virtual networks is via the Azure Portal, but I’m not going to show that because it’s quite easy, I’m going to the other options and that is PowerShell ?

First of all, you need to have the latest Azure PowerShell commandlets so always remember to run Update-Module -Verbose -Confirm:$false and if you don’t have the cmdlets installed then run Install-Module AzureRM

While being logged into run the following PowerShell script and let’s go over it one by one:

#Create a RG for Demo
$RG = New-AzureRmResourceGroup -Name AzurePeeringDemo -Location westeurope

#Create the first VNET
$FirstVNET = New-AzureRmVirtualNetwork -ResourceGroupName AzurePeeringDemo -Name FirstVnet -AddressPrefix 10.10.0.0/16 -Location $RG.Location
Add-AzureRmVirtualNetworkSubnetConfig -Name SubnetDefault -VirtualNetwork $FirstVNET -AddressPrefix 10.10.1.0/24
Set-AzureRmVirtualNetwork -VirtualNetwork $FirstVNET

#Create the second VNET
$SecondVNET = New-AzureRmVirtualNetwork -ResourceGroupName AzurePeeringDemo -Name SecondVnet -AddressPrefix 10.11.0.0/16 -Location $RG.Location
Add-AzureRmVirtualNetworkSubnetConfig -Name SubnetDefault -VirtualNetwork $SecondVNET -AddressPrefix 10.11.1.0/24 
Set-AzureRmVirtualNetwork -VirtualNetwork $SecondVNET

#Enable VNET peering on both VNETS
$FirstVnet = Get-AzureRmVirtualNetwork -ResourceGroupName AzurePeeringDemo -Name FirstVnet 
$SecondVnet = Get-AzureRmVirtualNetwork -ResourceGroupName AzurePeeringDemo -Name SecondVnet
Add-AzureRmVirtualNetworkPeering -Name PeeringWithVNET2 -VirtualNetwork $FirstVnet -RemoteVirtualNetworkId $SecondVnet.Id 
Add-AzureRmVirtualNetworkPeering -Name PeeringWithVnet1 -VirtualNetwork $SecondVnet -RemoteVirtualNetworkId $FirstVnet.Id

As with all operations, we first need to create a Resource Group where we can start adding virtual networks. In the second and third block, we create the virtual networks. Observe that I created the virtual networks with non-overlapping address spaces.

In the forth block we create the peering between the two virtual networks, and that’s all that’s needed to peer two virtual networks by using PowerShell.

Now a peering connection has some options that are disabled by default:
AllowForwardedTraffic – This setting allows the peers forwarded traffic to enter the virtual network. So this means that traffic that was forwarded to VNET 2 is allowed to go to VNET 1.
AllowGatewayTransit – This option enables the peer virtual network to access the virtual network gateway present. This means that if VNET 1 has a VPN gateway, this option allows VNET2 to communicate with that VPN using VNET peering.
UseRemoteGateways – This option allows the peering connection to use a remote gateway present in a peered network which means that if VNET 1 has a VPN gateway and set the AllowGatewayTransit option to True, this option is needed for the traffic to flow toward the gateway.

Enabling any of the options is simple via PowerShell:

#Enable forwarded traffic on VNET 1
$PeeringWithVNET2 = Get-AzureRmVirtualNetworkPeering -VirtualNetworkName $FirstVNET.Name -ResourceGroupName $RG.ResourceGroupName -Name PeeringWithVNET2 
$PeeringWithVNET2.AllowForwardedTraffic = $true 
Set-AzureRmVirtualNetworkPeering -VirtualNetworkPeering $PeeringWithVNET2

#Enable gateway transit on VNET 1
$PeeringWithVNET2 = Get-AzureRmVirtualNetworkPeering -VirtualNetworkName $FirstVNET.Name -ResourceGroupName $RG.ResourceGroupName -Name PeeringWithVNET2 
$PeeringWithVNET2.AllowGatewayTransit = $true 
Set-AzureRmVirtualNetworkPeering -VirtualNetworkPeering $PeeringWithVNET2

#Enable remote gateway on VNET 2
$PeeringWithVNET1 = Get-AzureRmVirtualNetworkPeering -VirtualNetworkName $SecondVNET.Name -ResourceGroupName $RG.ResourceGroupName -Name PeeringWithVNET21
$PeeringWithVNET1.RemoteGateways = $true 
Set-AzureRmVirtualNetworkPeering -VirtualNetworkPeering $PeeringWithVNET2

And in the end, if you want to remove the peering connection, you simply run one of these two PowerShell cmdlets:

Remove-AzureRmVirtualNetworkPeering -ResourceGroupName $RG.ResourceGroupName -VirtualNetworkName $FirstVNET.Name -Name $PeeringWithVNET2.Name 
Remove-AzureRmVirtualNetworkPeering -ResourceGroupName $RG.ResourceGroupName -VirtualNetworkName $SecondVNET.Name -Name $PeeringWithVNET1.Name

That’s all folks.
Have a good one!