VNet peering (or virtual network peering) enables you to connect virtual networks. A VNet peering connection between virtual networks enables you to route traffic between them privately through IPv4 addresses. Virtual machines in the peered VNets can communicate with each other as if they are within the same network.
In this article, I will share with you how to use Azure VPN Gateway To route traffic between spoke networks. This is also referred to as Peer-to-Peer transitive routing.
Contents of this Article
Virtual network peering is a non-transitive relationship between two virtual networks. In Azure, peer-to-peer transitive routing describes network traffic between two virtual networks that are routed through an intermediate virtual network with a router. For example, assume you have three virtual networks called VNet1, VNet2, and VNet3.
VNet1 has peered with the VNet2 network, and VNet2 has peered with VNet3, but VNet1 and VNet3 are NOT connected. For network traffic to get from VNet1 to VNet3, it would have to go through the VNet2 network. This action is known as transitive routing.
A common topology in Azure is the “hub and spoke” networking architecture. This topology contains a central “hub” virtual network connected to an on-premises network, via either a VPN gateway or an ExpressRoute circuit as shown in the diagram below. Additional “spoke” virtual networks that support specific workloads, are connected to the “hub” virtual network via peering connections. This topology supports on-premises networking while providing network segmentation and delegated administration.
As you can see in the diagram above, the “hub” virtual network is connected to the on-premises network via a VPN gateway or ExpressRoute gateway, while all “spoke” virtual networks have peering relationships with the “hub” virtual network only. This topology does not directly support communication between the “spoke” virtual networks. In many network design architectures, it is necessary for some or even all of the “spoke” networks to communicate together. For example, an organization may host an application server in a “Spoke1” virtual network and a central database server in another “Spoke2” virtual network.
If the application needs to communicate with the database, how would they facilitate it?
According to Microsoft’s official documentation, if you require spokes to connect to each other, then one option is to consider adding an explicit peering connection between “Spoke” VNET1 and “Spoke” VNET2 as shown in the diagram below.
However, suppose you have several spokes that need to connect with each other. In that case, you will run out of possible peering connections very quickly due to the limitation on the number of virtual network peerings per virtual network. (For more information, see Networking limits).
In this scenario and as a second option, Microsoft recommends considering using user-defined routes (UDRs) to force traffic destined to a spoke to be sent to Azure Firewall or a network virtual appliance acting as a router at the hub. This will allow the spokes to connect to each other.
What about if you don’t want to use an Azure Firewall or a network virtual appliance due to additional cost and complexity?
Again according to Microsoft’s official documentation (Spoke connectivity), they said that you can also use a VPN gateway as a third option to route traffic between spokes instead of using an Azure Firewall or other network virtual appliance such as pfSense NVA, but they don’t tell us how to do it!
Well, in this article, and after digging deeper, I will share with you how to create spoke-to-spoke communication with the help of the Azure VPN gateway and routing table without the need for an Azure Firewall or a network virtual appliance (NVA).
To follow this article, you need to have the following:
- Azure subscription(s) – If you don’t have an active subscription, you can create a free one here.
- Azure Resource Group obviously.
- Three virtual networks deployed with their appropriate IP subnets. These virtual networks can be in the same region or in different regions (also known as Global VNet Peering). VNet peering connections can also be created across Azure subscriptions. Please check the following quickstart guide to create a virtual network.
- Azure VPN Gateway deployed in the Hub virtual network. There is nothing special to set on the Azure VPN gateway besides its provisioned and configured correctly. Please check the following guide to create a VPN gateway for your Hub VNet.
- Virtual network peering between the spoke networks to the hub network. Please check the following guide to add peering and enable transit.
- At least one Azure virtual machine deployed in the spoke virtual networks. It’s not required to have a VM running in the Hub VNet.
Assuming you have the prerequisites in place, take now the following steps:
To facilitate the transitive routing configuration between spokes, we will go through the following steps:
- Verify the peering relationship
- Configure user-defined routes (UDRs)
- Test connectivity
Verify the Peering Relationship
Each peering relationship consists of two peering connections; one from the hub to the spoke and one from the spoke to the hub. The peering connections from the spokes to the hub must allow forwarded traffic as shown in the figure below. This can be set through the Azure portal, PowerShell, or the Azure CLI.
On the Hub VNet side, you want to make sure that the peering connections from the hub to the spokes must allow forwarded traffic and gateway transit (Use this virtual network’s gateway or Route Server) as shown in the figure below. This can be set through the Azure portal, PowerShell, or the Azure CLI.
Configure user-defined routes (UDRs)
At this point, we are ready to create the custom routing table and user-defined routes (UDRs).
Before we start, you need to get the IP address space for each spoke virtual network that you want to configure. In my example, the “Spoke1” VNet is 10.71.24.0/21 and the “Spoke2” VNet is 10.71.8.0/21.
In the Azure Portal, search for “Route Tables” and then click on “+ Add”.
Provide a name, select a subscription, a resource group, and a region where you want the routing table to be created as shown in the figure below.
Please note that routes to the gateway-connected virtual networks or on-premises networks will propagate to the routing tables for the peered virtual networks using gateway transit. If you don’t want to propagate gateway routes, then select ‘No‘, to prevent the propagation of on-premises routes to the network interfaces in associated subnets.
Click ‘Review + Create‘ and then the ‘Create‘ button to create the Route Table.
Once you have created the routing table, you can add the routes by clicking on ‘Routes’ under the ‘Settings‘ section, and then click ‘+ Add’ as shown in the figure below.
In this example, I will add one route, because traffic from network “Spoke1” VNet to “Spoke2” is to go through the Azure VPN Gateway which is deployed in the Hub virtual network.
Provide a route name, select the destination IP address prefix for the “Spoke2” virtual network, and most importantly, is to select Virtual network gateway as the ‘Next hop type’ as shown in the figure below. The next-hop handles the matching packets for this route. It can be the virtual network, the virtual network gateway, the Internet, a virtual appliance, or none. Please note that Virtual network gateways can’t be used if the address prefix is IPv6. Click OK to continue.
The final step is to assign the routing table to the default subnet of the “Spoke1” virtual network. You can assign the subnet by clicking on ‘Subnets’ under the ‘Settings‘ section, and then click ‘+ Associate’ as shown in the figure below. You need to select your virtual network and the subnet where your virtual machine(s) is deployed.
Last but not least, you want to repeat the same steps described above for the “Spoke2” virtual network as well.
This is the end, now we can log into the virtual machine in the “Spoke1” virtual network and see if we can connect to the VM in the “Spoke2” virtual network.
At first, I checked the pings if the machine was responding, and then run the “Test-NetConnection” command with the “-DiagnoseRouting” parameter to see where the path to each virtual machine is.
That’s it there you have it. Happy Azure Routing!
In this article, I showed you how to configure peer-to-Peer transitive routing between spokes using Azure VPN gateway without using Azure Firewall or network virtual appliance. Although this solution will have an impact on latency and throughput compare to direct network peering between spokes. In my scenario, I have tested the latency with explicit peering between spokes in the same Azure region, and the average latency is 1ms. And then I have tested the latency through the Hub VNet using Azure VPN gateway, and the latency was around 4ms. I would expect for sure a higher latency when you go between different Azure regions (E.g. East Asia <==> North Europe, etc.).
Please do your benchmark and check your performance before you put it in production.
For more information, please check the following documentation:
- Virtual Network Peering Requirements and Constraints.
- Virtual Network Peering frequently asked questions (FAQ).
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.