Azure User Defined Routes (UDR) - Complete Guide

Overview

Azure User Defined Routes (UDR) allow you to control the flow of network traffic within your Azure virtual networks. By default, Azure routes traffic between subnets, virtual networks, and on-premises networks automatically. UDRs enable you to override these default routes and direct traffic through specific paths, such as network virtual appliances (NVAs), firewalls, or custom routing scenarios.

Key Components

Route Table: A collection of routes that determine where network traffic is directed
Route: Individual routing rule within a route table
Next Hop: The destination where traffic should be forwarded
Subnet Association: Links a route table to one or more subnets

Basic UDR Architecture

graph TB A[Client VM] --> B[Subnet A] B --> C[Route Table] C --> D{Route Decision} D -->|Default Route| E[Internet Gateway] D -->|Custom Route| F[Network Virtual Appliance] F --> G[Destination Network] D -->|Custom Route| H[VPN Gateway] H --> I[On-Premises Network] style A fill:#e1f5fe style B fill:#f3e5f5 style C fill:#fff3e0 style F fill:#ffebee style G fill:#e8f5e8

Diagram Explanation: This diagram shows the basic UDR architecture where traffic from a client VM in Subnet A is evaluated against a Route Table. The route table contains multiple routes that determine the next hop - either the default internet gateway, a custom Network Virtual Appliance (NVA), or a VPN gateway for on-premises connectivity. The route decision engine selects the most specific route match to determine the traffic path.

Use Case 1: Firewall Interception

Scenario

Force all traffic from web tier to database tier through an Azure Firewall for inspection and logging.

graph LR A[Web Tier
10.0.1.0/24] --> B[Route Table] B --> C[Azure Firewall
10.0.3.4] C --> D[Database Tier
10.0.2.0/24] E[Internet] --> F[Application Gateway] F --> A style A fill:#e3f2fd style C fill:#ffebee style D fill:#e8f5e8 style F fill:#fff3e0

Diagram Explanation: In this firewall interception scenario, traffic from the Web Tier (10.0.1.0/24) is forced through an Azure Firewall (10.0.3.4) before reaching the Database Tier (10.0.2.0/24). The Route Table associated with the Web Tier subnet contains a custom route that directs all traffic destined for the database subnet through the firewall's private IP address. This ensures all east-west traffic is inspected and logged.

Command Sequence for Firewall Interception

Step 1: Create Route Table - az network route-table create
Step 2: Create Routes - az network route-table route create
Step 3: Associate Route Table - az network vnet subnet update
Step 4: Verify Configuration - az network route-table show

Step 1: Create Route Table

az network route-table create \
    --name rt-web-tier \
    --resource-group rg-network \
    --location eastus \
    --tags Environment=Production Tier=Web

Parameter Explanation:

--name: Name of the route table (rt-web-tier)
--resource-group: Resource group containing the route table
--location: Azure region for the route table
--tags: Optional tags for resource management

Purpose: Creates the route table container that will hold our custom routes. This is the first component needed before defining any routes.

Step 2: Create Route for Database Traffic

az network route-table route create \
    --name route-to-database \
    --route-table-name rt-web-tier \
    --resource-group rg-network \
    --address-prefix 10.0.2.0/24 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.3.4

Parameter Explanation:

--name: Name of the individual route
--route-table-name: Route table to add this route to
--address-prefix: Destination network (database subnet)
--next-hop-type: Type of next hop (VirtualAppliance for firewall)
--next-hop-ip-address: IP address of the Azure Firewall

Purpose: Creates a route that directs all traffic destined for the database subnet (10.0.2.0/24) through the Azure Firewall at 10.0.3.4. The VirtualAppliance hop type indicates traffic should go through an NVA.

Step 3: Create Route for Internet Traffic

az network route-table route create \
    --name route-to-internet \
    --route-table-name rt-web-tier \
    --resource-group rg-network \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.3.4

Parameter Explanation:

--address-prefix 0.0.0.0/0: Default route for all internet traffic
--next-hop-type VirtualAppliance: Routes through the firewall
--next-hop-ip-address 10.0.3.4: Firewall's private IP

Purpose: Forces all internet-bound traffic from the web tier through the firewall for inspection. This ensures outbound traffic is also filtered and logged.

Step 4: Associate Route Table with Subnet

az network vnet subnet update \
    --name subnet-web \
    --vnet-name vnet-production \
    --resource-group rg-network \
    --route-table rt-web-tier

Parameter Explanation:

--name: Name of the subnet to associate
--vnet-name: Virtual network containing the subnet
--route-table: Route table to associate with the subnet

Purpose: Links the route table to the web subnet, making the custom routes active for all VMs in that subnet. This is when the routing changes take effect.

Use Case 2: Hub-and-Spoke Network with NVA

Scenario

Route traffic between spoke networks through a central hub containing a Network Virtual Appliance (NVA) for centralized security and monitoring.

graph TB A[Spoke 1
10.1.0.0/16] --> B[Hub VNet
10.0.0.0/16] C[Spoke 2
10.2.0.0/16] --> B D[Spoke 3
10.3.0.0/16] --> B B --> E[NVA
10.0.1.4] E --> F[On-Premises
192.168.0.0/16] E --> G[Internet] H[Route Table Spoke 1] --> A I[Route Table Spoke 2] --> C J[Route Table Spoke 3] --> D style A fill:#e3f2fd style C fill:#e8f5e8 style D fill:#fff3e0 style E fill:#ffebee style B fill:#f3e5f5

Diagram Explanation: This hub-and-spoke topology uses UDRs to route all inter-spoke traffic through a central NVA in the hub. Each spoke has its own route table with routes pointing to the NVA for destinations in other spokes, on-premises networks, and internet traffic. The NVA acts as a central point for security inspection, logging, and policy enforcement across all spoke networks.

Detailed Traffic Flow for Hub-and-Spoke

sequenceDiagram participant S1 as Spoke 1 VM participant RT1 as Route Table 1 participant NVA as Hub NVA participant RT2 as Route Table 2 participant S2 as Spoke 2 VM S1->>RT1: Traffic to 10.2.0.0/16 RT1->>NVA: Next hop: 10.0.1.4 NVA->>NVA: Security inspection NVA->>S2: Forward to destination S2->>S1: Return traffic Note over S1,S2: All inter-spoke traffic inspected

Diagram Explanation: This sequence diagram shows the traffic flow when a VM in Spoke 1 communicates with a VM in Spoke 2. The traffic hits the route table in Spoke 1, gets directed to the NVA in the hub, undergoes security inspection, and then reaches the destination in Spoke 2. Return traffic follows the same path through the NVA, ensuring bi-directional inspection.

Create Route Table for Spoke 1

az network route-table create \
    --name rt-spoke1 \
    --resource-group rg-network \
    --location eastus \
    --disable-bgp-route-propagation false

Parameter Explanation:

--disable-bgp-route-propagation false: Allows BGP routes from VPN/ExpressRoute

Purpose: Creates a route table for Spoke 1 with BGP route propagation enabled to receive on-premises routes through VPN or ExpressRoute connections.

Create Routes for Spoke 1

az network route-table route create \
    --name to-spoke2 \
    --route-table-name rt-spoke1 \
    --resource-group rg-network \
    --address-prefix 10.2.0.0/16 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.1.4

az network route-table route create \
    --name to-spoke3 \
    --route-table-name rt-spoke1 \
    --resource-group rg-network \
    --address-prefix 10.3.0.0/16 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.1.4

az network route-table route create \
    --name to-internet \
    --route-table-name rt-spoke1 \
    --resource-group rg-network \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.1.4

Purpose: These three routes direct traffic from Spoke 1 to:

Spoke 2: Inter-spoke communication through NVA
Spoke 3: Inter-spoke communication through NVA
Internet: All internet traffic through NVA for inspection

Each route uses the same NVA IP address (10.0.1.4) as the next hop, creating a centralized inspection point.

Use Case 3: Force Tunneling for Compliance

Scenario

Force all internet-bound traffic from Azure VMs to go through on-premises network for compliance and security inspection.

graph LR A[Azure VM
10.0.1.0/24] --> B[Route Table] B --> C[VPN Gateway
10.0.0.4] C --> D[On-Premises
192.168.1.0/24] D --> E[Corporate Firewall] E --> F[Internet] G[Default Route
0.0.0.0/0] --> B style A fill:#e3f2fd style C fill:#fff3e0 style D fill:#f3e5f5 style E fill:#ffebee style F fill:#e8f5e8

Diagram Explanation: Force tunneling redirects all internet traffic from Azure VMs through the on-premises network. The route table contains a default route (0.0.0.0/0) that points to the VPN Gateway instead of the Azure internet gateway. This ensures all outbound traffic goes through corporate security controls and meets compliance requirements for data inspection and logging.

Create Route Table for Force Tunneling

az network route-table create \
    --name rt-force-tunnel \
    --resource-group rg-network \
    --location eastus \
    --disable-bgp-route-propagation true

Parameter Explanation:

--disable-bgp-route-propagation true: Prevents BGP routes from overriding custom routes

Purpose: Creates a route table with BGP route propagation disabled to ensure the custom default route takes precedence over any BGP-learned routes from on-premises.

Create Force Tunnel Route

az network route-table route create \
    --name force-tunnel-route \
    --route-table-name rt-force-tunnel \
    --resource-group rg-network \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualNetworkGateway

Parameter Explanation:

--address-prefix 0.0.0.0/0: Default route for all internet traffic
--next-hop-type VirtualNetworkGateway: Routes through VPN/ExpressRoute gateway
No --next-hop-ip-address: Azure automatically determines the gateway IP

Purpose: Creates a default route that forces all internet-bound traffic through the VPN gateway to on-premises. This overrides Azure's default internet routing.

Use Case 4: Load Balancer with Health Probes

Scenario

Configure UDR to work with Azure Load Balancer while maintaining proper health probe functionality.

graph TB A[Internet] --> B[Load Balancer
Public IP] B --> C[Backend Pool] C --> D[VM1
10.0.1.4] C --> E[VM2
10.0.1.5] C --> F[VM3
10.0.1.6] G[Route Table] --> H[Subnet 10.0.1.0/24] H --> D H --> E H --> F I[Health Probe
168.63.129.16] --> D I --> E I --> F J[Special Route
168.63.129.16/32] --> G style B fill:#fff3e0 style D fill:#e3f2fd style E fill:#e3f2fd style F fill:#e3f2fd style I fill:#ffebee

Diagram Explanation: When using UDRs with Azure Load Balancer, you must ensure health probes from Azure's infrastructure (168.63.129.16) can reach the backend VMs directly. The route table includes a specific route for the health probe IP address that bypasses any NVA routing. This prevents health probe failures that would occur if probes were routed through network appliances.

Create Route Table for Load Balancer Backend

az network route-table create \
    --name rt-lb-backend \
    --resource-group rg-network \
    --location eastus

Create Health Probe Route

az network route-table route create \
    --name health-probe-route \
    --route-table-name rt-lb-backend \
    --resource-group rg-network \
    --address-prefix 168.63.129.16/32 \
    --next-hop-type Internet

Parameter Explanation:

--address-prefix 168.63.129.16/32: Azure's health probe service IP
--next-hop-type Internet: Routes directly without going through NVA

Purpose: Ensures Azure Load Balancer health probes can reach backend VMs directly, bypassing any custom routing that might interfere with load balancer functionality.

Create Application Traffic Route

az network route-table route create \
    --name app-traffic-route \
    --route-table-name rt-lb-backend \
    --resource-group rg-network \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.2.4

Purpose: Routes all other traffic (except health probes) through the NVA for security inspection while maintaining load balancer functionality.

Next Hop Types Explained

graph LR A[Route Decision] --> B[VirtualNetworkGateway] A --> C[VirtualAppliance] A --> D[Internet] A --> E[VnetLocal] A --> F[None] B --> G[VPN/ExpressRoute Gateway] C --> H[NVA/Firewall IP] D --> I[Azure Internet Gateway] E --> J[Same VNet] F --> K[Drop Traffic] style A fill:#fff3e0 style B fill:#e3f2fd style C fill:#ffebee style D fill:#e8f5e8 style E fill:#f3e5f5 style F fill:#ffcdd2

Diagram Explanation: This diagram shows the five possible next hop types in Azure UDRs:

VirtualNetworkGateway: Routes through VPN or ExpressRoute gateway
VirtualAppliance: Routes through a specific NVA IP address
Internet: Routes through Azure's internet gateway
VnetLocal: Routes within the same virtual network
None: Drops the traffic (blackhole route)

Route Priority and Evaluation

graph TB A[Incoming Packet] --> B{Route Evaluation} B --> C[System Routes - Priority Lowest] B --> D[BGP Routes - Priority Medium] B --> E[User Defined Routes - Priority Highest] E --> F{Most Specific Match} F --> G[32 Route - Highest Priority] F --> H[24 Route - Medium Priority] F --> I[16 Route - Lower Priority] F --> J[Default Route - Lowest Priority] style A fill:#fff3e0 style E fill:#ffebee style G fill:#e8f5e8

Diagram Explanation: Azure evaluates routes in order of priority: User Defined Routes have the highest priority, followed by BGP routes, then system routes. Within each category, the most specific route (longest prefix match) wins. For example, a /32 route takes precedence over a /24 route for the same destination.

Complete Implementation Command Flow

Implementation Order

graph TB A[1. Create Route Table] --> B[2. Create Routes] B --> C[3. Associate with Subnet] C --> D[4. Verify Configuration] D --> E[5. Test Connectivity] E --> F[6. Monitor and Troubleshoot] style A fill:#e3f2fd style B fill:#e8f5e8 style C fill:#fff3e0 style D fill:#f3e5f5 style E fill:#ffebee style F fill:#fce4ec

Diagram Explanation: The implementation follows a logical sequence where the route table container is created first, then individual routes are added, followed by subnet association to activate the routes. Verification and testing ensure the configuration works as expected, with ongoing monitoring for troubleshooting.

Verification Commands

Show Route Table Details

az network route-table show \
    --name rt-web-tier \
    --resource-group rg-network \
    --output table

List All Routes in Table

az network route-table route list \
    --route-table-name rt-web-tier \
    --resource-group rg-network \
    --output table

Show Effective Routes for VM NIC

az network nic show-effective-route-table \
    --name vm-web-nic \
    --resource-group rg-network \
    --output table

Purpose: These commands help verify that routes are properly configured and active. The effective routes command shows exactly which routes are being used by a specific network interface, including system routes, BGP routes, and UDRs.

Advanced Configuration Options

Conditional Routing with Service Tags

az network route-table route create \
    --name route-to-storage \
    --route-table-name rt-web-tier \
    --resource-group rg-network \
    --address-prefix Storage.EastUS \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.3.4

Purpose: Uses service tags to route traffic to specific Azure services through an NVA. Service tags automatically include all IP ranges for that service in the specified region.

Route Table with Multiple Associations

az network vnet subnet update \
    --name subnet-web \
    --vnet-name vnet-production \
    --resource-group rg-network \
    --route-table rt-shared

az network vnet subnet update \
    --name subnet-api \
    --vnet-name vnet-production \
    --resource-group rg-network \
    --route-table rt-shared

Purpose: Associates the same route table with multiple subnets to apply consistent routing policies across different tiers of an application.

Troubleshooting Common Issues

Warning: Always test UDR changes in a non-production environment first. Incorrect routing can cause connectivity issues and service outages.

Common Issues and Solutions

Health Probe Failures: Ensure 168.63.129.16/32 routes to Internet next hop
Asymmetric Routing: Configure return path routing on NVAs
BGP Route Conflicts: Use disable-bgp-route-propagation when needed
NVA Connectivity: Verify NVA IP forwarding is enabled

Monitoring and Diagnostics

az network watcher show-next-hop \
    --resource-group rg-network \
    --vm vm-web-01 \
    --source-ip 10.0.1.4 \
    --dest-ip 10.0.2.4

Purpose: Uses Network Watcher to determine the next hop for traffic between specific IP addresses, helping diagnose routing issues.

Best Practice: Always document your UDR configurations and maintain a network diagram showing traffic flows. This helps with troubleshooting and change management.

Summary

Azure User Defined Routes provide powerful traffic control capabilities for complex network architectures. Key takeaways:

UDRs override default Azure routing behavior
Route tables must be associated with subnets to take effect
Most specific routes (longest prefix) take precedence
Special consideration needed for load balancer health probes
Always test changes in non-production environments

Proper UDR implementation enables advanced scenarios like centralized security inspection, force tunneling for compliance, and hub-and-spoke network architectures while maintaining Azure service functionality.