Implementing Azure User Defined Routing

In a previous post, How Do You Customize Routing in Azure?, I explained why we might use user defined routing in Azure. In this post I will show you how to create a route table and routes, and associate that route table to virtual subnets.

The Task

I will start with a simple example based on a scenario that one of my customers faced recently. The customer was dealing with a site that had invested heavily in a software-based edge network solution that was not on Microsoft’s listed set of supported VPN devices. The customer wanted to deploy a site-to-site VPN connection, but didn’t want to purchase new edge firewalls. So the solution that was created was to deploy a virtual appliance in Azure that would act as the VPN gateway instead of using a gateway on the virtual network.
If you use an Azure gateway for VPN connectivity, the local network setting will provide your subnets with a route to your on-premises network. However, when you deploy your own VPN solution in a virtual machine (that’s what a virtual appliance is) then there is nothing, by default, to tell Azure how to route subnet traffic to the on-premises network(s).

The Desired Solution

User defined routing will be used to fix the above problem. A route table will be created. A single route will be added:

• Address Prefix: The network address (192.168.1.0/24) of the on-premises network will be used as the destination address.
• Next Hop Type: Virtual Appliance will be used because the next hop is a virtual machine.
• Next Hop IP Address: The IP address of the virtual appliance on the Azure subnet (10.1.0.10) will be defined as the IP gateway address for this route.

When a packet is being sent from a virtual machine in the subnet to anywhere on 192.168.1.0/24, then the user defined rule will match and override the system route for routing the traffic to the Internet.

Implementing the Solution

We will use the Azure Portal (https://portal.azure.com) to deploy this solution. A later post will show you the PowerShell alternative.
Open the Azure Portal, and click New > Networking > Route Table. Enter the required details for the new route table:

• A name that will identify the route table, and ideally identify the subnet(s) that it will be associated with.
• Select the subscription (if necessary)
• Select the resource group that you want to add the route table to – it makes sense to add it to a resource group that contains the virtual network.
• Select the Azure region that you want to deploy this route table to.

Click Create when you are ready.

It will take a few minutes for the new route table to be prepared for you. When it is, browse to the resource group that the route table was created in and open the route table. There are two groups of settings that we need to edit:

• Routes: This is where you create the user defined routes to override the system routes.
• Subnets: Here is where you can associate the route table with one or more subnets.

Open up routes and click Add. Enter the following information:

• A name for the route.
• The CIDR address of the network you are routing to.
• The type of device that is acting as a router or gateway to the destination network.
• The address of the route or gateway device – which itself must be routable from the Azure virtual network subnet.

My example is a pretty simple one; a single route is being created to use a virtual appliance (machine) as a third-party site-to-site VPN solution.
Now browse to Subnets in the settings of the route table. Click Associate, choose a virtual network, and then select the subnet that you want to link this route table to. You should end up with something like the following example, where the routes and subnets can be seen summarized in the Essentials view of the route table.
It would be a mistake to attempt to test your routing now; the Azure fabric is not going to allow IP forwarding by the NIC(s) of a virtual machine (appliance) unless you allow it. This must be done using PowerShell. The following code will work with an Azure v2 (Azure Resource Manager or ARM) virtual machine. Make sure you update your version of the Azure PowerShell module, and then log into ARM using Login-AzureRMAccount. First we need to select a NIC in the virtual machine:

$RgName = “DemoPetriAF1”
$VMName = “DemoPetriAFGW1”
$NicName = ((Get-AzureRmVM -ResourceGroupName $RgName -Name $VmName).NetworkInterfaceIDs).Split("/")[-1] | Out-GridView -Title "Select a NIC to configure forwarding ..." –PassThru

Then you’ll get the configuration of that NIC using the following line:

$NicConfig = Get-AzureRmNetworkInterface -ResourceGroupName $RgName -Name $NicName

And finally you will enable IP forwarding:

$NicConfig.EnableIPForwarding = $true
$NicConfig | Set-AzureRmNetworkInterface

Be sure to repeat this for every virtual appliance NIC that will be used to route traffic on an Azure subnet. And now you can test your routing.