You dont have javascript enabled! Please enable it! Use Azure VPN Gateway To Route Traffic Between Spoke Networks - CHARBEL NEMNOM - MVP | MCT | CCSP | CISM - Cloud & CyberSecurity

Use Azure VPN Gateway To Route Traffic Between Spoke Networks

6 Min. Read

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, we 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.

Introduction

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.

Azure VPN Gateway Transitive Routing Between Spokes

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.

Azure peering connection between spokes

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

Prerequisites

To follow this article, you need to have the following:

1) Azure subscription(s) – If you don’t have an active subscription, you can create a free one here.

2) Azure Resource Group obviously.

3) Three virtual networks were 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.

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

5) Virtual network peering between the spoke networks to the hub network. Please check the following guide to add peering and enable transit.

6) At least one Azure virtual machine is deployed in the spoke virtual networks. It’s not required to have a VM running in the Hub VNet.

Assuming you have all the prerequisites in place, take now the following steps:

The Process

To facilitate the transitive routing configuration between spokes, we will go through the following process:

1) Verify the peering relationship.

2) Configure user-defined routes (UDRs).

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

Traffic forwarded from remote virtual network

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.

Use this virtual network's gateway or Route Server

 

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

Add a route table spoke1

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.

Create a route table

Once you have created the routing table, you can add the routes by clicking on ‘Routes’ under the ‘Settings‘ section, and then clicking ‘+ Add’ as shown in the figure below.

Add a route table

In this example, we’ll 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 the 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.

Add route to virtual network gateway

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.

Assign the route table to the default subnet

Last but not least, you want to repeat the same steps described above for the “Spoke2” virtual network as well.

Add a route table spoke2

Test Connectivity

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.

Test-NetConnection Perform route diagnostics to connect to a remote host

That’s it there you have it. Happy Azure Routing!

Summary

In this article, we 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 compared to direct network peering between spokes.

In this scenario, we have tested the latency with explicit peering between spokes in the same Azure region, and the average latency is 1 ms. And then we tested the latency through the Hub VNet using Azure VPN gateway, and the latency was around 4 ms. We would expect a higher latency for sure 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 resources:

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 21+ years of IT experience. As a Swiss Certified Information Security Manager (ISM), CCSP, CISM, Microsoft MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.
Previous

Create Azure Backup Protection Policy with PowerShell

Update Rollup 3 for System Center 2019 is Now Available

Next

10 thoughts on “Use Azure VPN Gateway To Route Traffic Between Spoke Networks”

Leave a comment...

  1. Hi Charbel,

    Thanks for the explanation. We did the same use case, but it doesn’t work.
    We don’t see the VirtualNetworkGateway in the effective routes of our spoke’s VM.
    We have a difference compared to your case: we have 2 VPN network gateways in the hub and one ExpressRoute gateway.
    Is it the reason for our issue?

    Regards
    Ay

  2. Hello Ay, thanks for the comment and for sharing your use case.
    Yes, this could be the reason since you have 2 VPN network gateways in the Hub VNet and one ExpressRoute gateway.
    What I would suggest for you to do and try is to select and set the Propagate gateway route to Yes when you create the routing table.
    Could you please verify that?
    Let me know if it works for you.
    Thanks!

  3. Hi,
    Thanks for the prompt response.
    The route propagation settings are already activated as you suggested but don’t help us.
    We tested the use case on a different environment with only one VNG (like yours) in the hub, and it works.
    So, we plan to use an NVA.
    Regards

  4. Thank you Ay for the update!
    Yes, with NVA, you can point to the right IP address of the appliance.
    If you are planning to use NVA, then I would suggest looking at Azure Route Server to easily manage to route between your network virtual appliance (NVA) and your virtual network.
    In this case, you no longer need to update User-Defined Routes (UDRs) manually whenever your NVA announces new routes or withdraws old ones.
    Cheers,

  5. Hi Charbel, nice article! Much appreciated and Thanks.
    I assume when we replace the Express route gateway in place of the VPN gateway in this topology, the ER gateway would have advertised the routes to the connected networks.
    In that case, we need not have the user-defined route table to direct the packets intended for the second spoke via the ER gateway.
    Honestly, I have not tried this in my lab yet, I have seen it working in a customer’s setup.

  6. Hello Sriram, thanks for the comment and feedback!
    Yes, your understanding is correct.
    When you replace the ExpressRoute gateway in place of the VPN gateway in this topology, the ER gateway would have advertised the routes to the connected networks via BGP.
    But you still need to have the user-defined route table configured to direct the packets intended for the ‘desired’ spoke via the ER gateway.
    Hope it helps!

  7. Hi Charbel, thank you for responding to my question. My question was based on this specific reference to MS documentation (https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview)

    When we have the ER gateway propagating routes to the connected networks (disconnected spokes in this topology), the next hop should be automatically the private IP of the ER gateway.
    I have seen this in the route table built from hybrid connections i.e. with on-premises. The behavior seems to be the same for azure networks too I suppose.

    “Virtual network gateway: Specify when you want traffic destined for specific address prefixes routed to a virtual network gateway. The virtual network gateway must be created with type VPN. You can’t specify a virtual network gateway created as type ExpressRoute in a user-defined route because with ExpressRoute, you must use BGP for custom routes. You can’t specify Virtual Network Gateways if you have VPN and ExpressRoute coexisting connections either”.

  8. Hello Sriram, thanks for clarifying the question!
    As documented clearly by Microsoft, yes you cannot specify a virtual network gateway created as type ExpressRoute in a user-defined route because with ExpressRoute, you must use BGP for custom routes. And you cannot specify Virtual Network Gateways if you have VPN and ExpressRoute coexisting connections either.
    In your case, I assume that you have enabled Private IP configuration for your virtual network gateway because this is not enabled by default.
    Your assumption is correct, you don’t need to have the user-defined route table to direct the packets intended for the second spoke via the ER gateway.
    Hope it helps!

  9. Hello Charbel, Thank you for the detailed explanation in your article, appreciate your efforts.
    I wanted to understand what if we have two Azure subscriptions in the same tenant and each of them has hub-spoke topology and we want to connect the spokes from both subscriptions together. In one subscription we have Azure Route Server and the NVA, but in the second subscription due to cost we want to avoid NVA with ARS multi region design with ARS+NVA in both hubs would work properly as NVA could advertise the routes to each other. But in case if we don’t want to use NVA in second hub-spoke subscription do we have any alternative for it so that spokes between both the subscriptions can communicate? UDRs came to my mind but that’s too much of manual entries and maintenance so want to avoid that route. Any suggestion?

    Thank you
    R

  10. Hello Robby, thank you for the feedback and comment, much appreciated!
    Please note that based on the scenario that you described, the only option you have, is to use UDR in the second subscription and leverage the NVA/Azure Route Server which is deployed in the first subscription.
    In order to route between both subscriptions and between two hub-spoke topologies, you need a gateway deployed somewhere. You already have that deployed, thus you can avoid the cost of deploying a second NVA with ARS multi region design, you can use UDR and set the next hop your existing NVA.
    Last, if you just want to connect the Spokes to communicate between both subscriptions, then you can Peer them directly using (Virtual Network Peering) without using any UDR nor NVAs.
    Hope it helps!

Let us know what you think, or ask a question...