Design, Implement, and Manage VNet Routing

The main purpose of an Azure virtual network (VNet) is to facilitate the delivery of data between point A (an Azure VNet workload) and point B (other connected systems). Routing defines the path that the transferred data will take between point A and point B.

There is a default routing behavior for workloads in an Azure subnet, but we also have options to customize the default behavior and control/influence the path of network traffic.

This is useful for many scenarios. For example, you may have an organizational requirement to inspect outbound network traffic with network virtual appliances (NVAs), such as third-party firewall solutions, for example, Palo Alto VM-Series firewalls. To implement this architecture, traffic must be properly routed through the NVAs for the inspection to occur. You may also have a requirement to redirect internet-bound traffic to an on-premises gateway instead of directly via Azure’s internet connectivity...

Technical requirements

To follow along with the instructions in this chapter, you will need the following:

• A PC with an internet connection
• An Azure subscription

Before we proceed to cover the security best practices, let us prepare our Azure subscription for the hands-on exercises that we will be completing later in the chapter.

Understanding the default routing for Azure VNet workloads

In previous chapters of this book, we created some VNets with subnets and deployed virtual machine (VM) workloads into them. Without making any changes, the default routing behavior for Azure subnets takes effect and controls the path that traffic will follow to get to their intended destination. Let’s examine what this default routing behavior looks like.

The default routing behavior for Azure subnets is controlled by system routes, which are automatically associated via a default route table (Figure 3.1). System routes are a collection of routing entries that define several destination networks (marked as the Address Prefix column in Figure 3.1) and the next hop to send the traffic to (marked as Next Hop Type in Figure 3.1) – this is the path that the traffic should follow to get to the defined destination.

Figure 3.1 – Azure VNet default route table with system routes

...

Modifying the default routing behavior

In some scenarios that you may have, the default flow of traffic as defined by system routes may not meet your organizational requirements. For example, you may want to implement the following scenarios:

• Forward outbound network traffic to NVAs, such as third-party firewall solutions, for inspection before being sent to the final destination.
• Direct all internet-bound traffic through your on-premises network maybe for compliance reasons. This is also referred to as forced tunneling.
• Completely isolate a VNet from the internet for compliance reasons.

For these scenarios, we have two main options for implementing custom routing. Since we cannot modify or update system routes, we can override system routes with user-defined routes or use the Border Gateway Protocol (BGP) to exchange routes.

What is a network virtual appliance?

An NVA is a virtual appliance that can be deployed from Azure Marketplace into Azure subnets...

Hands-on exercise – cleaning up resources

In this exercise, we will remove the resources that we created in the chapter exercises to avoid running up a large cost in Azure!

In Cloud Shell, run the following command to delete the CharisTechRG-C3 resource group:

az group delete --name CharisTechRG-C3 --yes

This will remove all the resources that we created for the exercises in this chapter.

Summary

In this chapter, we established a good foundation of understanding routing in Azure and how we can control/influence the path that traffic takes when it leaves an Azure subnet. We discussed how to implement custom routing with route tables and user-defined routes. We implemented custom routing with user-defined routes and BGP-advertised routes via a route server.

In the next chapter, we will start to build on this foundation by covering the first aspect of connectivity – cross-VNet connectivity. See you in the next chapter!

Further reading

Refer to the following links for more information about the topics covered in this chapter:

• VNet routing: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
• Azure Route Server FAQ: https://docs.microsoft.com/en-us/azure/route-server/route-server-faq