This interactive article is Part Two of a two-part series on facilitating transitive routing over Azure virtual network peering connections. In Part One, I discussed the need for transitive routing, some advantages and disadvantages of the architecture, and alternatives to transitive routing. In this article, I will demonstrate the process of establishing transitive routing in a hub-and-spoke network topology.

The Architecture

The architecture, shown below, presents a simplified hub-and-spoke topology with no on-premises component.

In this topology, there are three virtual networks, each with a Windows Server 2016 virtual machine. The Hub virtual network also hosts a pfSense network virtual appliance that will act as the router for this topology.

Peering relationships are established between the Hub virtual network and both the Spoke A and Spoke B virtual networks. There is no direct peering relationship between Spoke A and Spoke B.

The subnets have network security groups with rules that allow traffic from the Internet to ports 3389, 22, and 80. Only port 3389 will be used for this example.

If you would like to follow along with the example, you can download a deployment template for this topology.

The Process

To facilitate transitive routing, we will go through the following steps:

1. Verify the peering relationships
2. Configure the router
3. Implement custom routing
4. 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. This can be set through the portal.

Configure the Router

Configuration of the router will be dependent on the router you choose to implement. For this example, I am using the Marketplace pfSense network virtual appliance (NVA) by Netgate. In a real world scenario, you would likely configure the NVA with multiple NICs on different subnets, but in this example it's configured with a single NIC for simplicity. For most NVAs you will likely need to configure the following:

• Basic setup
• Routing
• Firewall
• Network Interface (NIC)

The default routing settings for the Netgate pfSense NVA are sufficient for this example, but the firewall rules need to be adjusted. I need to allow RDP traffic to traverse the NVA, which means I need to add a firewall rule allowing port 3389.

Depending on your communication needs, you may need to configure additional ports. Also, in case of the pfSense NVA, the firewall rules allow connection to the WAN, but not the LAN for ports 80, 443, and 22. These may need to be adjusted depending on the requirements of the topology. For this example, I only need port 3389, so I will leave the other rules as is.

To configure the pfSense NVA (for this example):

1.) Connect to the hub VM via RDP. You can download the RDP file from the Azure portal blade.

2.) Turn off IE Enhanced Security Configuration for the hub VM through Server Manager.

 

3.) Connect to the web UI of the pfSense NVA

4.) Walk through the configuration wizard accepting the defaults. Enter an administrative password.

5.) Once the pfSense software is setup, add a firewall rule to allow traffic on port 3389 between any source and any destination. (In a production environment you would limit access through the firewall to the relevant IP address ranges).

6.) Be sure to apply changes after you add the firewall rule.

That should be all you need to do for the pfSense NVA.

Verify IP Forwarding on the Router NIC

In addition to the software configuration for the router NVA, the Azure network interface card (NIC) need to be configured to allow forwarded IP traffic. This is set through the IP configurations page of the network interface blade in the Azure portal.

Note: The pfSense marketplace image sets this when the resource is provisioned.

Implement Custom Routing

The final step in establishing routing is to add custom routes to the spoke virtual networks so they route inter-spoke traffic through the router NVA. For this example, I am going to use a white list approach. I will add a routing rule for each spoke that routes traffic specifically for the other spoke.

To configure routing for Spoke A:

Create a route table.

Add a routing rule that routes all traffic to the IP address prefix for the Spoke B virtual network to the router NVA private IP address.

Assign the route table to the default subnet of the Spoke A virtual network.

Repeat the process for the Spoke B virtual network.

Test Connectivity

At this point, the infrastructure is set up for transitive peer-to-peer routing. The only thing left is to verify connectivity. To do this in our example, I am going to connect to the public IP endpoint for the server in Spoke A. From there, I'll establish an RDP session to the private IP endpoint for the server in the Spoke B virtual network. If successful, this will verify the transitive connection through the hub virtual network.

Check out the video below for a complete demonstration of the process.

 

 

To continue utilizing Azure, use your All Access Pass to work through the Microsoft Azure Learning Path. 

{{cta('0aeb8e9d-8cca-4219-8ed6-4f16dfbf7074')}}