User-Defined Routes – Virtual Networking
Using system routes, Azure automatically handles all packet routing. As mentioned earlier, users can always override these routes using user-defined routes (UDRs). To give an example of routing, assume we have three subnets inside a virtual network. The subnets are the public subnet, DMZ subnet, and private subnet. In the DMZ subnet, assume that we have a network virtual appliance (NVA). NVAs are VMs that can optimize our networks with routing and firewall capabilities. Our goal is to make sure that all traffic coming from the public subnet should be routed to the NVA before it gets routed to the private subnet. The reason for this is that a public subnet contains workloads that are Internet facing, and a private subnet contains workloads that are not exposed to the Internet, such as databases, application logic, backend servers, etc. By default, the communication from the public subnet is allowed to the private subnet; however, we need to make sure that the traffic is filtered before it reaches the private subnet. This will help us to protect the private workloads, as all traffic is matched against the rules that you have set up in the NVA. If there is any attack or malicious traffic, NVA will take care of it. Now, the question is, how can we implement this? As you can see in Figure 3.2, we have used the routing table with UDR to accomplish this task. By default, the traffic from the public subnet to the private subnet is allowed, but using UDR, you are forcing the packets to go through the NVA.
FIGURE 3.2 Routing architecture
UDR will help you create custom routes, and you can specify which is the next hop for the packet. In the previous example, the next hop was NVA. The hop can be a virtual network, VPN gateway, virtual appliance, or the Internet. You can associate the same route table to multiple subnets; however, a subnet can be associated to a single route table at a time. Creating route tables will not incur any charges, and these are free of cost.
The following are the steps to force the traffic to route through the NVA:
- Create a routing table.
- By adding a custom route, you can direct the traffic from a public subnet to the NVA.
- Finally, associate the route table to the subnet.
Let’s perform a hands-on exercise to understand how these steps can be performed on the portal. You will create a routing table, add a custom route, and finally associate the route table to the subnet. See Exercise 3.4.
EXERCISE 3.4
Creating a Route Table
- Sign in to the Azure portal and create a virtual network with the address space 172.17.0.0/16. You can review Exercise 3.1 for instructions on how to create a virtual network. The virtual network will have three subnets: public (172.17.1.0/24), DMZ (172.17.2.0/28), and private (172.17.3.0/24).
- The next action is to create a routing table, and the process is straightforward. Search for route tables in the Azure portal, and click Create. You have to provide a name for the routing table and select a subscription, a resource group, and the location.
- You can also decide if you want to use virtual network gateway route propagation by enabling Propagate Gateway Routes. The routes from on-premises are added to the route table automatically for all subnet network interfaces with virtual network gateway route propagation enabled.
- Clicking Review + Create will submit the template and create the route table.
Now that you have created the route table, you need to add the route. The routing table is a collection of routes. As mentioned earlier, each route will be evaluated before directing a packet. If no matching routes or rules are found, then the packet is dropped. In Exercise 3.5, you will create a UDR by which the packets are routed via NVA in a DMZ subnet to the private subnet.