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.
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).
User defined routing will be used to fix the above problem. A route table will be created. A single route will be added:
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.
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:
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:
Open up routes and click Add. Enter the following information:
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.