Azure: Asymmetrical routing: the most common error in Azure routing configuration.

Using advanced routing configuration in Azure can lead you to a strange position; Doing the opposite of what you wanted to achieve and having no clue about that.

Take a scenario where you have several vnets under the same IP prefix 10.0.0.0/20, vnet1 (10.0.0.0/24), vnet2 (10.0.1.0/24), …, they host client applications, and a VNET, VNETApp, hosting a server used by these applications with? 192.168.0.0/25 for address space.

All the VNETs, vnetX, need to communicate with VNETApp. A peering between vnetx and vnetApp is all you need.

To secure VMs in the vnetApp VNET, management asks for a Firewall between the server application and all client VNETs (actual and future VNET).

A new subnet, vnetNva, is created in vnetApp VNET, and an NVA with IP 192.168.0.135 is deployed in the new subnet.

A route table is created for each client VNET to change the default route. To access the AppSubnet (192.168.0.0/25), packets are routed to the virtual appliance 192.168.0.135 (Prefix 192.168.0.0/25, next Hope Type: virtual appliance, next Hope Address 192.168.0.135).

The route table is associated with each subnet in the vnetX virtual network.

For the VnetApp virtual network, a route table is created to route packets through the NVA. To avoid adding a route each time a new vnetx is created, the route will use the prefix reserved for the client VNETs, 10.0.0.0/20. (Prefix 10.0.0.0/20, next Hope Type: virtual appliance, next Hope Address 192.168.0.135).

Is it the right solution? No

Why? Because of how Azure makes routing decisions:

• Higher prefixes; the algorithm will choose the most specific. Here we have a route for 10.0.0.0/20 and a route for 10.0.0.0/24. The last one will be chosen and you have an asymmetrical route.
• For the same prefix, UDR is choosing before BGP routes and before default routes.

But how to spot the error?

There are two tools to see if there is a routing issue.

At the level of the virtual network interface, you can use the Effective Routes in the Help menu.

It will give a table like this.

The second tool is on the VM. In the Help menu choose “Connection Troubleshoot)

Choose the destination VM, the protocol ICMP, and the Next Hop test

For a client VM, you should have something

Next hop (from source),Success,Next hop type: VirtualAppliance Route table: UDR

For the server VM with a not functional route

Next hop (from source),Success,Next hop type: VirtualNetworkPeering Route table: System Route

You see that the packet are routed to the peering instead of the NVA.

?This is a very simple example if you add Express Route, Virtual Wan, and other services based on BGP, things can be far more intricate. Be sure to always have routing rules in my and do not hesitate to run diagnostic tests with a VM.