As you know Azure Network is based on Hyper-V networking (you can check my last post on this point). To be short, networking is based on Hyper-V Network Virtualization, virtual switch, and VXLAN encapsulation. It means that networking in Azure does not fully follow the same rules as your on-premises network. When a network packet leaves the guest OS in a VM, it is encapsulated by the virtual network interface and sent directly to its destination via the Azure Fabric.
In a normal situation, no problem, you don’t have to think about this point. Azure is taking charge of everything. But things become more complex when you need to modify the default routing settings to add an NVA and this is where you can start to see mistakes and misconfiguration.
When you add an NVA to filter traffic between two parts of your network in Azure you will have to add User Defined Route to overwrite the default routing in Azure. Let’s take an example. You have created in Azure several VNETs and you want to get access to these resources from your on-premises network. You create another VNET add a VPN gateway and configure an IPSec tunnel with BGP to your office network. Then you peer the other VNETs to this last VNET.
You have a VNET (Hub VNET 172.24.0.0/24) that hosts the Virtual Network Gateway. Client VNETs (clientVnet01 & clientVnet02) are peered to the first VNET, these peering are configured to use the gateway in the peered VNET.
Everything works fine, you get access to your resources in Azure and your resources in Azure can communicate to the workload on-premises. But something is missing, you do not inspect packets to or from Azure. So, you decide to add an NVA in the same VNET hosting the VPN gateway (in a separate subnet).
You add a new subnet in the Hub VNET and add an NVA with a private IP.
But adding the NVA is not enough, you need to alter the default routes. You need to make sure that each subnet in the client VNET uses the NVA as the next hop instead of the gateway. Azure allows you to alter default routes with User Defined Routes. So, you can create a route to 192.168.0.0/24 going to the virtual appliance, 172.24.10.4, and you add it to all subnets.
But it is only half the work, if packets from Client Vnets go to onPrem via the NVA it is not true for onPrem to Client VNETs. By default, packets go directly to VNETs via the peering. So, you decide to add a User Defined Route to Client VNETs via the NVA. But to avoid adding a route to the subnet each time a client VNET is added with 10.0.0.0/8 for the prefix.
Will it work? No, because it is an example of asymmetrical routing, packets are routed from Client VNET through the NVA, but packets from on-premises are routed directly by the VNET peering. Why? Because doesn’t follow the rules of routing in Azure.
The rules:
- The Longest prefix always wins. If a destination is included in prefixes of several rules, the biggest one. In the previous example, 10.0.0.0/24 (the peering) is longer than the UDR (10.0.0.0/8) so the peering is used. conclusion, in this case of situations for each VNET you should have a route (and potentially automate it) for each VNET instead of a general one.
- For the same prefix in a route table, UDR wins over BGP and BGP wins over the Default route. The rule is simple here, if there is, for the same prefix, a modified route, this route must be chosen.
It is very easy to create asymmetrical routing, and most of the time it goes unnoticed at least until someone has the idea to open the NVA logs and sees no traffic from one side to another. To avoid that, every time you create an UDR you need to ask yourself a question, is it the largest prefix for the destination? You can verify routes by using an online VM and check the effective routes.
Top comments (0)