How Network Routing works in Azure with System Routes and User Defined Routes

Introduction

Azure automatically creates a routing table for each subnet. By default, this includes a default route. These system routes cannot be deleted, but they can be overridden by user defined routes. Azure uses these entries to control outbound traffic from a subnet. To help you understand the routing behavior, I’ve summarized the most important principles in this post.

How Do Default Routes Work?

Each route consists of an address prefix and a target type, the so-called next hop. When traffic leaves a subnet, Azure checks the destination address and compares it with the existing prefixes in the routing table. The most suitable route is selected.

By default, the following types of next-hop targets exist:

• The next-hop type Virtual Network enables communication between subnets within the same virtual network.
• With the next-hop type Internet, all traffic that doesn't belong to the internal address space is routed to the internet. An exception applies to IP addresses assigned to Azure services. In this case, traffic remains within the Azure backbone, even if the address technically belongs to the public address space. This behavior can be adjusted with user defined routes if needed.
• The next-hop type None means that such traffic is simply dropped and does not leave the subnet.

Additional default routes may be created when using specific features:

• For example, when Virtual Network Peering is used, new routes automatically apply to all subnets within the respective network.
• When a Virtual Network Gateway uses Border Gateway Protocol (BGP), Azure dynamically creates additional routes.
• When service endpoints are enabled for certain Azure services, matching routes with the next-hop type VirtualNetworkServiceEndpoint are also automatically created. Since the public IP ranges of these services change regularly, using service endpoints and the associated service tags saves us from having to manage address ranges manually.

Natürlich! Hier ist die englische Übersetzung des nächsten Abschnitts im Markdown-Format – mit dem ursprünglichen Schreibstil beibehalten:

User Defined Routes in Azure

In many cases, the default routes don’t meet our needs, so we have to use our own routing rules. These user defined routes (UDRs) can be defined for individual subnets or globally for the entire virtual network. A routing table can contain up to 400 user defined routes, and with Azure Virtual Network Manager, you can even use up to 1000 entries.

Let’s take a look at the different options for the next-hop type of an user defined route.

Virtual Appliance

When you select Virtual Appliance, traffic is forwarded through a specific private IP address. This is usually the IP of a network interface of a VM that acts as a forwarding unit. To use this function, you must enable IP forwarding for the respective network interface. In specific cases, you’ll need to set up IP forwarding not only in the Azure portal but also within the operating system of the VM.

If the virtual appliance is supposed to forward traffic to public IP addresses, you’ll also need a network NAT or a proxy. In this case, Azure performs the translation to a public IP address before the traffic is sent to the internet.

You should also create the virtual appliance in its own subnet within your VNet to avoid a routing loop.

Virtual Network Gateway

When you specify the next-hop type Virtual Network Gateway, traffic from the VNet is forwarded to a VPN gateway.

With gateways that use ExpressRoute connections, user defined routes cannot be used, since Border Gateway Protocol (BGP) handles the routing.

The same applies when using a combination of VPN and ExpressRoute gateways. In that case, you shouldn’t configure a static route to the gateway, but instead rely on BGP. For example, all outbound traffic (0.0.0.0/0) can be handed off to the gateway via BGP.

None

The next-hop type None allows you to deliberately block traffic. When you select this type in a user defined route, packets with the assigned address prefix will not be forwarded.

This option is particularly useful when you want to secure specific IP ranges or destinations. It’s also helpful for zero-trust approaches or highly segmented networks where you want to actively block data flow, without having to set up an additional firewall or NSG rules.

Virtual Network

With the next-hop type Virtual Network, you can override the default behavior of Azure system routes within a VNet. By default, Azure allows communication between all subnets in a VNet. This is enabled by the system default route with the target type "Virtual Network".

However, when you also use "Virtual Network" as a target type in a user defined route, you can intentionally intervene and restructure routing within the network. For example, you can ensure that specific IP ranges are preferentially routed through certain subnets or appliances.

Internet

When you select the next-hop type "Internet" in a user defined route, the corresponding traffic is explicitly routed to the public internet. If you want to define that certain IP addresses or ranges should not be routed through gateways or firewalls, this next-hop type is useful.

A typical scenario would be allowing only specific subnets or workloads direct access to the internet, while all other traffic is controlled via appliances or gateways. This can also be useful in development or test environments where additional security checks are not required.

At the same time, Azure offers an elegant solution for efficiently routing traffic to specific Azure services using service tags. Instead of managing and maintaining the currently valid IP ranges in your routing tables manually, you can simply use the corresponding service tag. You can use up to 25 of these service tags in a single routing table.

What Is the Border Gateway Protocol?

The Border Gateway Protocol (BGP) is a dynamic routing protocol used to automatically connect networks with each other. Instead of configuring routing information manually, networks exchange their routes with each other using BGP. In Azure, this mechanism is used with VPN gateways and ExpressRoute connections.

For example, if you operate an on-premises corporate network and want to connect it via a VPN gateway or ExpressRoute, both sides need to know what networks exist and how traffic should be routed correctly. The Border Gateway Protocol handles this task automatically and ensures that your internal on-premises networks and Azure VNets and subnets exchange routing information.

Without BGP, you would have to manually enter all relevant routes both in your local network and in Azure. While this is technically possible, it quickly becomes complex and error-prone. With BGP, this process is much more efficient. Your local gateway automatically informs Azure which networks it’s responsible for. Azure automatically adds this information to the routing tables. In return, your on-premises gateway also learns which network ranges exist in Azure.

BGP becomes even more important with ExpressRoute connections, where the use of the protocol is mandatory. As soon as you connect your datacenter to Azure via a dedicated ExpressRoute line, your router announces the available routes via BGP to Microsoft’s edge routers. This allows Azure to know automatically which paths can be used to route traffic.

Azure Route Hierarchy

Now that we've covered the different types of routes, the question arises: how does Azure actually decide which route to use when a virtual machine tries to reach a specific destination address? Azure makes this decision automatically in the background but follows a clear logic.

Azure always uses the route with the longest prefix match. This means that the more specific the address range of a route is, the higher its priority.

For example, let’s say your virtual network has two routes. One route for 10.0.0.0/16 points to the internet, and another for 10.0.0.0/24 points to the virtual network gateway. If a VM now tries to reach the IP address 10.0.0.5, both routes theoretically match, but Azure chooses the route with the /24 prefix, since that range is smaller and therefore more precise. So the traffic is routed through the gateway, not the internet.

However, if multiple routes use the same prefix, a second rule applies. Azure then prioritizes routes based on their origin:

• First are custom routes that you’ve defined in routing tables.
• Then come dynamic BGP routes, for example from a VPN gateway.
• Finally, Azure considers system default routes.

A typical example would be a custom route for 0.0.0.0/0 pointing to a virtual network gateway. At the same time, a system route with the same prefix points to the internet. If a VM now tries to reach an external IP like 8.8.8.8, both routes match. However, since custom routes take precedence, the traffic is routed through the gateway, not directly to the internet.

What Does 0.0.0.0/0 Mean in Azure Routing Tables?

The route with the prefix 0.0.0.0/0 plays a special role in Azure. It defines how outbound traffic from a subnet is handled by default. This route essentially represents all IP addresses not covered by more specific routes. When you create a subnet in Azure, this route is added automatically.

If a virtual machine or another service wants to connect to an IP address outside its own network, Azure uses this default route—unless a more specific custom route exists. By default, this route points to the public internet.

Still, traffic does not necessarily leave the Azure platform. For example, when a VM connects to an Azure Storage Account or Azure SQL Database, the traffic is routed through the Azure backbone. Although 0.0.0.0/0 technically points to the internet, the traffic is internally routed through the Azure backbone and not sent over the public network. This intelligent resolution happens in the background and helps protect the data flow.

You can also override the default route. By creating your own route with the prefix 0.0.0.0/0, you can define that all outbound traffic must pass through a VPN gateway, a firewall appliance, or an ExpressRoute connection. This principle is commonly used in production Azure environments to gain full control over outbound traffic. Typical goals include security inspection via a central firewall or preventing direct access to the public internet.

The 0.0.0.0/0 route is therefore a key tool when you want to steer or secure network connections in Azure.

What to Watch Out for When Overriding 0.0.0.0/0

If you change the default routing in Azure and direct traffic through a VNet gateway or virtual network appliance (such as a firewall), there are a few important things to consider. Mistakes here can result in your network becoming unreachable—or your gateway failing entirely.

When Using a VNet Gateway as the Next Hop

A common mistake is configuring a custom route with the 0.0.0.0/0 prefix that points to a VPN or ExpressRoute gateway as the next hop. At first glance, this might seem logical—you want to control all traffic through the gateway. However, it becomes critical if this route is assigned to the GatewaySubnet.

The GatewaySubnet is a specially reserved area within your virtual network where Azure hosts the gateway. Azure uses this subnet internally to operate and manage the connection to external networks, like your on-premises environment or the internet. If you define a routing rule with 0.0.0.0/0 here, the gateway tries to route its own traffic through itself—breaking its ability to communicate with any external networks at all.

The result can be that VPN tunnels can’t be established, existing connections break, or the gateway becomes completely unreachable. A routing table with a 0.0.0.0/0 route must never be attached to the GatewaySubnet. This subnet should never contain user defined routes.

When Using a Virtual Appliance (e.g. Firewall) as the Next Hop

If you route outbound traffic in Azure through a virtual appliance, such as a firewall, it acts as a central control point. These appliances inspect, filter, or process the traffic before forwarding it to its destination. Common solutions include Azure Firewall or network virtual appliances from third-party vendors.

To make this setup work reliably, a few requirements must be met. The appliance itself must be reachable, especially if it handles incoming traffic from the internet or an on-premises network. In these cases, a public IP address is required, since without it, the appliance can’t receive external connections.

In addition to being reachable, correct configuration of routing, firewall rules, and NAT settings is necessary. The virtual appliance must know how to handle incoming traffic and forward it to internal targets like virtual machines in the VNet. Common methods include Source NAT (SNAT), Destination NAT (DNAT), or using the appliance as a proxy.

Another important point to keep in mind is Network Security Groups (NSGs). Even if the routing logic is correct, restrictive NSG rules can block traffic. Make sure that incoming traffic to the network appliance is allowed, as well as return connections from the appliance to the target systems. Rules like Deny All at the end of an NSG can prevent data from arriving at all.

A functioning combination of routing, network appliance, and NSG rules is essential if you want to use a central network appliance in Azure as a control point for traffic.

Example Use Case

To wrap up, let’s look at a sample scenario and apply the routing options accordingly.

Example Scenario

We have a virtual network called Virtual Network 1. Within this VNet, we’ve deployed multiple subnets for different compute resources. In total, we have four subnets, divided as follows:

• Subnet 1: A container app environment is deployed here, which includes 2 container apps.
• Subnet 2: This subnet hosts an app service plan that includes 2 app services.
• Subnet 3: This subnet contains 2 virtual machines.
• Subnet 4: This subnet is dedicated to an Azure Firewall that inspects specific egress traffic and applies firewall policies.

Our goals for this VNet setup:

• All outbound traffic from Subnet 3 should first be routed to Subnet 4 with the Azure Firewall.
• The virtual machines in Subnet 3 should be able to communicate with each other using private IP addresses.
• Outbound traffic from Subnet 3 to Subnets 1 and 2 should be denied.
• Subnets 1 and 2 should be able to access storage accounts directly, without being routed through Subnet 4.

Solution to the Example Scenario

Route Table for Subnet 1 and 2:

Explanation of the Routes:

• No additional UDR is required, since only direct access to Storage via service endpoints is needed.
• The service endpoint for Azure Storage is already enabled, so Route ID 2 ensures that Azure Storage accounts are reachable without passing through the Azure Firewall.

Route Table for Subnet 3:

Explanation of the Routes:

• ID 1: This default route within the VNet is overridden by ID 5 (UDR).
• ID 2: Allows communication within Subnet 3 (VM ↔ VM), important for private communication as required in our second condition.
• ID 3 & ID 4: Explicitly block traffic from Subnet 3 toward Subnet 1 (10.0.0.0/24) and Subnet 2 (10.0.1.0/24) per the third requirement.
• ID 5: Forces all other traffic (e.g. internet or on-prem via VPN/ExpressRoute) through the Azure Firewall in Subnet 4 (10.0.4.4 as the firewall’s private IP).

Summary

Azure automatically creates routing tables with default routes for every subnet, which determine the basic traffic behavior within the virtual network. With user-defined routes (UDRs), you can tailor this behavior to route traffic through gateways, firewalls, or specific network appliances.

Route selection always follows the rule of longest prefix match, with user-defined routes taking precedence over BGP and system routes.

The default route 0.0.0.0/0 is especially relevant, as it handles outbound traffic. It can be overridden to, for example, integrate centralized security solutions or control internet access. Care must be taken with critical subnets such as the GatewaySubnet, which should never contain custom routes.

Helpful Links for Further Research:

• Traffic routing for virtual networks: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
• Using SNAT for outbound connections: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections?toc=%2Fazure%2Fvirtual-network%2Ftoc.json
• Azure System Routes and User-Defined Routes:
  • https://learn.microsoft.com/de-de/azure/virtual-network-manager/how-to-create-user-defined-route
  • https://cloudbuild.co.uk/tag/azure-system-routes-vs-user-defined-routes/
  • https://prashanth-kumar-ms.medium.com/azure-user-defined-routing-d0a2dd1eefa6
• Azure Routing Basics: https://www.azure-heros.com/blog/azure-routing-from-zero-to-hero-the-basic