Azure Networking Tips: UDR Implementation for Spoke VM Local Internet Breakout and Traffic Fine Control

How to easily identify whether this Virtual Network (vNET) is a Hub role or a Spoke role?

For friends who are familiar with #Azure Networking, Hub-Spoke network topology may not be unfamiliar. Generally speaking, determining whether a Virtual Network (vNET) serves as the Hub role is based on whether it includes Azure Firewall or Virtual Network Gateway or Azure Route Server within the subnet. If it does, it is mostly considered the Hub role, while other subnets are regarded as Spoke role.

The diagram below is a fairly typical example:

And in order to ensure that the services within the Spoke are protected by Azure Firewall, we need to use an Azure Route Table to configure a User-Defined Route (UDR) to control the behavior of the default route. As shown in this diagram, you can see that Azure Route Table on right is set to "Propagate gateway routes: No" by design, and the NextHop for the default route (0.0.0.0/0) is set to the private IP of Azure Firewall (192.168.100.4).

About Propagate Gateway Route

Regarding Propagate gateway route, by default, without any configuration, it is set to Propagate gateway routes: Yes. If you do not want to this subnet to receive routes learned from the Virtual Network Gateway or Azure Route Server, you need to specifically create an Azure Route Table, associate it with the subnet, and set Propagate gateway routes: No.

This setting is very important method for controlling the routes of the Virtual Network Gateway / Azure Route Server in many Network Virtual Appliance (NVA, such as Cisco SD-WAN / Aruba SD-WAN / FortiGate) deployments. Often, you may not want specific subnets to learn routes from the Virtual Network Gateway or Azure Route Server, so you need to specifically disable it to prevent them from being learned. I will mention the importance of this setting multiple times in the following posts.

Problem #1

Using vnet-spoke-1 (192.168.102.0/24) as an example, according to the typical design, the default route (0.0.0.0/0) must go through Azure Firewall (192.168.100.4). Now, if I want to connect to the VM (azure-rhel9) inside from my laptop - Microsoft Surface Pro (55.66.55.66), apart from setting up DNAT on Azure Firewall, is there any other way to securely connect directly to the VM while still maintaining overall routing consistency?

Solution #1

Yes, use Local Internet Breakout. This uses the Longest-Prefix-Match (LPM) routing control method and is not a new Azure networking features.

1. default-route: Originally, there was already a default route (0.0.0.0/0) that sends all traffic to Azure Firewall.
2. via-internet: Local Internet Breakout. Use another route with a longer prefix to direct specific destination traffic directly to Internet (55.66.55.66/32 -> Internet)

Because the router selects the longest prefix, this route break out the traffic for that IP.

Don't forget to configure the Network Security Group (NSG) allow inbound traffic from Microsoft Surface Pro (55.66.55.66) and allow outbound traffic to the Service Tag: Internet

This scenario is commonly seen when you might need to bypass Azure Firewall's restrictions from an internet network to directly access the VM for a series of test and verifications. This is NOT COMMON IN PRODUCTION environments but may occasionally occur in development environments, especially if you want to keep a closed network environment.

Problem #2

Following up on the Problem #1, if I want the VM (azure-rhel9) to have its default route directly to the internet, but require it to go through the Azure Firewall when connecting to the intranet network, what should I do?

Solution #2

It is necessary to change the order of the routes. But essentially, it is merely the control of the Longest-Prefix-Match (LPM) routing control method.

1. via-firewall: you need to include the entire (or you want to control) private network segement here. Some people directly include the Private Address Space listed in RFC 1918 Address Allocation for Private Internets:
   1. 10.0.0.0/8
   2. 172.16.0.0/12
   3. 192.168.0.0/16
2. default-route: This is easy to understand, the default route (0.0.0.0/0) is directed towards the internet and does not pass through the Azure Firewall

This scenario is often seen when your VM is located in the DMZ or requires a specific public IP to provide external services, while also needing to connect to the internal network to access specific services. This routing configuration frequently appears in produiction envirnments. However, you still need to be cautions about security risk, as this VM is essentially exposed to the external network and can receive connections from around the world.