2.3 System Routes & User-Defined Routes (UDR)

System Routes & User-Defined Routes (UDR)

Routing in Azure Virtual Networks is controlled by a software-defined networking (SDN) fabric known as the Azure Virtual Filtering Platform (VFP). Rather than relying on traditional physical switches and routers with hop-by-hop forwarding tables, Azure applies routing logic directly to each virtual machine's Network Interface Card (NIC).

To effectively design secure hub-and-spoke topologies, enforce perimeter firewall inspection, and prevent unauthorized egress, network engineers must master System Routes, User-Defined Routes (UDRs), and next hop behavior.

---

Default System Routes

When a subnet is created in an Azure Virtual Network, Azure automatically injects a collection of Default System Routes. These routes cannot be directly deleted, but they can be overridden by custom routes.

+-----------------------------------------------------------------------------+
|                        Azure Subnet Default System Routes                   |
|                                                                             |
|   Address Prefix         Next Hop Type          Description                 |
|   --------------------   --------------------   -------------------------   |
|   <VNet Address Space>   VnetLocal              Intra-VNet & Peered VNets   |
|   0.0.0.0/0              Internet               Direct Outbound Internet    |
|   10.0.0.0/8             None                   RFC 1918 Blackhole Drop     |
|   172.16.0.0/12          None                   RFC 1918 Blackhole Drop     |
|   192.168.0.0/16         None                   RFC 1918 Blackhole Drop     |
|   100.64.0.0/10          None                   RFC 6598 CGNAT Drop         |
+-----------------------------------------------------------------------------+

Detailed Breakdown of System Route Types

1. VnetLocal (Virtual Network):
   • Matches the IP address space of the containing VNet.
   • Expands automatically when you add new address prefixes to the VNet or establish Virtual Network Peering.
   • Routes packets directly between subnets within the VNet without passing through an external gateway.
2. Internet:
   • Configured with prefix 0.0.0.0/0.
   • Provides default direct Internet egress for all VMs that possess a public IP address or use default outbound access.
3. None (Traffic Blackhole):
   • Automatically covers private address ranges defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and RFC 6598 (100.64.0.0/10) that are NOT included within your VNet address spaces.
   • Any packet sent to these unmapped private ranges is dropped immediately to prevent private IP leakage to the Internet.
4. VirtualNetworkGateway:
   • Injected dynamically when a Virtual Network Gateway (VPN or ExpressRoute) is deployed or when VNet peering has UseRemoteGateways enabled.

---

User-Defined Routes (UDR) & Route Tables

A Route Table (Microsoft.Network/routeTables) is an Azure Resource Manager resource containing a list of user-defined routing rules. When associated with a subnet, the Route Table overrides default system routes and dynamically learned BGP routes.

Available Next Hop Types

// Azure Bicep: Custom Route Table Forcing All Outbound Traffic to Azure Firewall
resource spokeRouteTable 'Microsoft.Network/routeTables@2023-05-01' = {
  name: 'rt-spoke-to-firewall'
  location: 'eastus'
  properties: {
    disableBgpRoutePropagation: false
    routes: [
      {
        name: 'route-default-to-nva'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'
        }
      }
    ]
  }
}

---

Subnet Association Rules & Infrastructure Subnet Constraints

Cardinality Rules

• 1 Route Table to Many Subnets: A single Route Table can be associated with multiple subnets across the same VNet or different VNets (within the same subscription and region).
• 1 Subnet to 1 Route Table: A subnet can have zero or one Route Table attached. Subnets cannot combine multiple route tables.

Special Subnet Restrictions

Azure reserves specific subnet names for managed platform services, which enforce strict routing constraints:

+---------------------------------------------------------------------------------------+
|                           Infrastructure Subnet UDR Constraints                       |
|                                                                                       |
|   Subnet Name           UDR Allowed?   Key Restrictions & Rules                       |
|   -------------------   ------------   --------------------------------------------   |
|   GatewaySubnet         YES (Restricted) Cannot have 0.0.0.0/0 -> VirtualAppliance    |
|                                        Cannot have local VNet -> VirtualAppliance     |
|                                        Used for Spoke-bound ingress inspection UDR    |
|   AzureBastionSubnet    NO / Restricted Cannot route Bastion egress to NVA/Firewall   |
|                                        Requires direct Internet access                |
|   AzureFirewallSubnet   YES (Restricted) Cannot have 0.0.0.0/0 -> VirtualAppliance    |
|                                        0.0.0.0/0 next hop must be Internet            |
|   AzureFirewallMgmtSub  NO / Restricted Dedicated to Azure Firewall Management traffic |
+---------------------------------------------------------------------------------------+

1. GatewaySubnet:
   • You CAN attach a route table to GatewaySubnet to steer inbound traffic from on-premises through an NVA.
   • Prohibited Routes: You cannot create a route with destination 0.0.0.0/0 and next hop VirtualAppliance on GatewaySubnet. You also cannot redirect traffic destined for the local VNet address space to a VirtualAppliance.
   • Allowed Ingress Pattern: Create routes for Spoke VNet prefixes (e.g., 10.100.0.0/16) with next hop VirtualAppliance (10.0.1.4).
2. AzureBastionSubnet:
   • Azure Bastion manages secure RDP/SSH sessions via browser.
   • Attaching a UDR with 0.0.0.0/0 pointing to an NVA will break the control plane and management communications, resulting in service disruption.
3. AzureFirewallSubnet:
   • Cannot contain a UDR with 0.0.0.0/0 pointing to another virtual appliance (which would cause infinite routing loops).
   • May contain a UDR with 0.0.0.0/0 next hop Internet if BGP routes are propagated from an ExpressRoute gateway.

---

Traffic Blackholing with Next Hop "None"

Traffic blackholing is an essential security design pattern in multi-tenant or regulated environments. Instead of relying solely on Network Security Group (NSG) deny rules, routing traffic to next hop None drops packets at the kernel SDN layer before they ever reach destination subnets.

Example: Strict Subnet Isolation

• Objective: Prevent the Database Subnet (10.1.3.0/24) from communicating with the Dev Subnet (10.1.5.0/24) and the Public Internet, while allowing Web Subnet (10.1.1.0/24) communication.
• Route Table Configuration on Database Subnet:
  • Route 1: 10.1.5.0/24 -> Next Hop: None (Drops all Dev traffic)
  • Route 2: 0.0.0.0/0 -> Next Hop: None (Drops all Internet traffic)
  • Default VnetLocal system route handles 10.1.1.0/24 communication seamlessly.

---

IP Forwarding Requirement on NVAs

When a virtual machine acts as a Network Virtual Appliance (NVA), routing software (e.g., pfSense, VyOS, FortiGate) receives packets whose destination IP address does not match the NVA's own NIC IP.

By default, the Azure SDN fabric drops packets where the destination IP does not match the receiving NIC. To allow an NVA to process and forward transit traffic:

• IP Forwarding must be ENABLED on the NVA's Azure Network Interface card (enableIPForwarding: true).
• Failure to enable IP forwarding results in complete traffic blackholing at the NVA ingress interface.