Demystifying System and User Define Routes of Azure

As Virtual Network is created, Azure automatically create its own route tables for that Virtual Network, so that all the packets which enters the virtual network can traverse within its address prefix and leave the subnet for its destination. These are known as the Default Routes. We can’t modify these routes; however, we can add our custom routes on top of default routes for the traffic leaving the subnet. These custome route is known as User Define Routes. In this case, we are modifying the default behaviour of packets routing but still the internal and external routing of packet is done by virtual network to ensure that our packets are never hijacked. 

In another word, we are adding routes and requesting virtual network to routes traffic in the way we want. So far its not possible to route the traffic independently bypassing the Azure Virtual Network routing mechanism and for security reason I do not think this will ever be possible.

Common Use Case of UDR: 

Every business has unique use case, and some business requires inspection of every traffic coming and leaving the virtual network. Incoming traffic is controlled/inspected by Firewall, where as returning traffic by default it will follow the system routes (Image 1). If we need to send traffic to certain subnet or virtual appliances or packet sniffing software, then UDR has to be applied on that subnet. With this we are overriding the Next Hop address, so that packets will be forced to certain VM’s IP (as of now single IP) or Virtual Appliances for further processing. Once this is done, again Azure Networking will receive this traffic and route to the destination or drop the packets if Next Hope is None.
 

Analyzing the Route Table

Image 1, shows the Effective Routes attached to the Virtual Machine. Its listing only the default routes. 

Image 1- Default Routes

Image 1 Line No 1. - Virtual Network:

Azure Routes all the traffic defined within the address range defined within the Virtual network. Any changes on address space will automatically update the Route Table.  
Refer to the Image 1, Route No 1.
If any address space is added, that will be automatically reflected between line 1 and 2 of Image 1. 

Image 1 Line No 2. - Internet:

Azure Default Routes 0.0.0.0/0 is destined for Internet. All routes used by Azure Services, does not fall under 0.0.0.0/0 prefix and they will never leave the azure backbone network. 

Image 1 Line No 3, 4, 5, 6 - None:

All packets leaving the Virtual Network which matches with the given prefix will be dropped.

Azure automatically creates default routes for the following address prefixes - 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16: Reserved for private use in RFC 1918 and 100.64.0.0/10- Reserved in RFC 6598. By default, all next hope for these address space will be None, however if these address space is added on virtual network address space, the Next Hop address will be changed from None to Virtual Network.

Bydefault two Virtual Network can't communicate with each other as they will not have effective routes to reach to another virtual network. In order to establish connection between two Virtual Network we can perfrom Virtual Network Peering or eastablish Vnet to Vnet Site to site Connection.
Site to Site usages Gateway to connect between Virtual network, On-Premises Network with Azure or within Azure where as Peering does not require Gateway and its faster but its used to connect Virtual Network within Azure only.  

Lets analyze Image 2.

Image 2- Different Next Hop Type

Line No 1- the device from which Effective Route is extracted lies on this network. i.e.:

192.168.0.0/16. Compare this with Image 1, line no 6 and identify the difference in Next Hop

 Line No 2 : Vnet-192.168.0.0/16 is peered with Vnet- 10.55.0.0/16. Any traffic destintned for 10.55.0.0/16 will be forwarded to Next Hope Type VNet Peering, so that traffic will reach to the destination network. 

Line No 3: Vnet-10.1.0.0/16 and Vnet-10.55.0.0/16 are connected with each other using Site to Site connection and Vnet-192.168.0.0/16 is peered with VNet-10.55.0.0/16. 

From VNet-192.168.0.0/16 we have reachability to On-Prem Network 10.1.0.0/16 because while peering with VNet-10.55.0.0/16 we had had configured to use Remote Gateway from VNet-192.168.0.0/16.

Line No 4: Default Route 0.0.0.0/0  to Internet. All the unknown route will be forwarded  to the Internet. Azure Cloud Services IP's does not fall under this default routes. 

Line No 5, 6 and 7: Default System Route

Line No  8: Default System Route for IPv6


Effective Routes with User Define Routes:

Image 3 - System and User Define Routes

Analyzing Image 3: 

Image 3- Line No 1: Routes for Current Vnet, and its still active. 

Image 3- Line No 2, 3, 4: Purpose of this is same as of Image 2, line no 2,3,4 however these are Invalid now. 

Image 3- Line No 2 is invalid because of User Define Routes of Line No 6. We are forcing traffic to certain IP and User define routes has higher precedence than System Routes.

Image 3- Line No 3: Invalid because of User Define Routes defined in Line No 7. 

Image 3- Line No 4: Invalid because of user Define Routes define in LIne No 5. 

Image 3- Line No 5: User Define Route: All unkown routes are forwarded to the Virtual Appliances.

Image 3- Line No 6: Vnet-10.55.0.0/16 and Vnet-192.168.0.0/16 is peered with each other. They know each other's routes thus they do not belong to 0.0.0.0/0. But we want to monitor all outgoing traffic from VNet-192.168.0.0/16,  that is why we are forcing that traffic to take given path in order to communicate with Vnet-10.55.0.0/16.

Image 3- Line No 7: Vnet-10.1.0.0/16 and Vnet-10.55.0.0/16 are connected with each other using site to site connection and Vnet-192.168.0.0/16 is peered with 10.55.0.0/16. This make aware of all VNet knows each other's routes and bypass Rule mentioned in Line No 5, which we don't want. 

Image 3- Line no 5,6 and 7 makes sure, east west traffic is also monitored. 

Image 3- Line No  8: Default System Route for IPv6. Since we are not using IPv6, so we are still good to achieve our goal. 

Virtual Appliances:

These can be Virtual Firewall, or any custom VM used to perform packet inspection or process business logics. 

Effective routes displays us the default route table associated with any virutal matchine attached to it.