Episode 4 — Routing: System Routes & User-Defined Routes

In Episode 3 we connected virtual networks with peering and saw that peering is non-transitive — now we learn the routing engine that decides where every packet actually goes, and how to bend it to force spoke-to-spoke traffic through an inspection appliance.

Learning objectives

• Explain the system (default) routes Azure creates for every subnet and the next hop types they use.
• Apply Azure's route-selection logic: longest-prefix match first, then the priority user-defined > BGP > system.
• Configure a user-defined route (UDR) in a route table, associate it to a subnet, and force 0.0.0.0/0 egress through a network virtual appliance (NVA).
• Choose when to disable BGP route propagation and how service chaining through an NVA is enabled with IP forwarding.
• Troubleshoot routing with Network Watcher next hop and effective routes when traffic is unexpectedly dropped or blackholed.

Why it matters

Every subnet in Azure already has a working routing table before you touch anything — Azure builds it invisibly so subnets, peered VNets, and the internet "just work". That convenience is also the trap: the moment you deploy a firewall, a VPN gateway, or a hub-and-spoke design, the default routes are wrong for your intent and traffic silently flows straight to the internet or between spokes without inspection. Understanding how Azure picks a route — and how a single UDR overrides it — is the difference between a security control that works and one that is quietly bypassed. This is core AZ-104 administration: routing is invisible until it breaks, and then it is the first thing you diagnose.

System routes: what Azure builds for you

Azure automatically creates a route table for each subnet and populates it with system routes. You cannot create or delete system routes, but you can override some of them with custom routes. Each route is just an address prefix plus a next hop type — Azure forwards traffic leaving the subnet to the next hop of the route whose prefix matches the destination.

Default system routes

Whenever a virtual network is created, Azure adds these default system routes to every subnet:

The four None prefixes exist so that traffic to unused private ranges is dropped rather than leaked to the internet. Key nuance: if you assign one of these ranges (or a range that includes one) to your VNet's address space, Azure changes the next hop from None to Virtual network — the address is now yours to use, so it becomes routable inside the VNet.

Three next hop types matter here:

• Virtual network — routes between the VNet's own address ranges. This is why subnets talk to each other with zero configuration.
• Internet — sends traffic to the internet. Important exception: traffic destined for the public IP of an Azure service stays on the Microsoft backbone and never touches the public internet.
• None — the packet is dropped (blackholed).

Optional default routes

Azure adds more system routes only when you enable a capability:

You cannot specify Virtual network peering or VirtualNetworkServiceEndpoint as a next hop in a UDR — Azure creates those only when you actually configure the peering or endpoint.

Memory hook — "V-I-N times four": the always-present default next hop types are Virtual network, Internet, and None (×4 dropped private prefixes). Peering, gateway, and service-endpoint routes only appear when you switch the feature on.

How Azure selects a route

Azure runs two rules, in order.

1. Longest-prefix match. Among all routes whose prefix contains the destination, the one with the longest (most specific) prefix wins. If a table has both 10.0.0.0/24 and 10.0.0.0/16, then:

• Destination 10.0.0.5 → matched by both, but /24 is longer, so it uses the /24 route.
• Destination 10.0.1.5 → not inside /24, so the /16 route is the longest match.

2. Priority on a tie. When multiple routes share the same prefix, Azure picks by source priority:

1. User-defined route (UDR)
2. BGP route
3. System route

So a UDR for 0.0.0.0/0 → Virtual network gateway beats the built-in 0.0.0.0/0 → Internet, because same prefix, higher priority.

Important exception: system routes for virtual network, virtual network peering, and virtual network service endpoint traffic are preferred routes — they win even over a more specific BGP route, and a VirtualNetworkServiceEndpoint route cannot be overridden by a route table at all.

Exercise 1 — Predict the next hop

A subnet's effective routes are:

For each destination, name the next hop: (a) 10.0.0.20, (b) 10.0.5.20, (c) 20.30.40.50.

Solution. (a) 10.0.0.20 → Virtual appliance (10.0.100.4). It matches both /16 and /24; the /24 is the longest prefix, and that route's next hop is the appliance. (b) 10.0.5.20 → Virtual network. It is inside 10.0.0.0/16 but not inside 10.0.0.0/24, so the /16 route is the longest match — traffic stays inside the VNet. (c) 20.30.40.50 → Virtual appliance. No specific prefix matches, so both 0.0.0.0/0 routes tie; the User route beats the Default Internet route by priority, so egress goes to the NVA.

Custom routes: UDRs and BGP

You create custom routes two ways: user-defined routes (UDRs) you author, or BGP routes exchanged between your on-premises gateway and an Azure virtual network gateway. Do not modify default routes — instead add UDRs, which override them.

Route tables and association

In Azure you create a route table, then associate it to zero or more subnets. Rules to memorize:

• A subnet can have zero or one route table associated.
• A route table can be associated to many subnets, but only within the same region and subscription.
• Route tables are associated to subnets, not VNets.
• A table's routes are combined with the subnet's default routes; on conflict, the UDR wins.
• Default capacity is up to 400 UDRs per route table (expandable to 1,000 with Azure Virtual Network Manager routing configuration).

Admin actions (portal): Create a resource → Route table, then under Settings → Routes → + Add enter a Route name, Address prefix (CIDR), Next hop type, and — if the type is Virtual appliance — a Next hop address. Then associate it under the subnet's settings. Equivalent CLI:

az network route-table create -g MyRG -n MyRouteTable

az network route-table route create \
    -g MyRG --route-table-name MyRouteTable \
    -n Default-NVA \
    --address-prefix 0.0.0.0/0 \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

az network vnet subnet update \
    -g MyRG --vnet-name MyVNet -n Subnet1 \
    --route-table MyRouteTable

Note you cannot delete a route table that is still associated to a subnet — dissociate first. Dissociating returns the subnet to its default routes.

Next hop types you can set in a UDR

A UDR can use: Virtual appliance, Virtual network gateway, Virtual network, Internet, or None. (Not peering or service-endpoint types.)

The workhorse is Virtual appliance — a VM running a firewall or router. Two requirements:

• You supply the appliance's private IP as the next hop IP address, and it must have direct connectivity (not via an ExpressRoute gateway or Virtual WAN) or the UDR is invalid.
• The appliance's NIC must have Enable IP forwarding turned on (an Azure setting that disables source/destination checks), and the OS may also need IP forwarding enabled. Without it, the NVA drops the transit packets.

Note: Deploy the NVA in a different subnet than the resources routed through it. Putting it in the same subnet whose table forces traffic to it can create a routing loop where traffic never leaves the subnet.

Forced tunneling with 0.0.0.0/0

A UDR for 0.0.0.0/0 → Virtual appliance (or Virtual network gateway) is forced tunneling: every destination not matched by a longer prefix is funneled through your inspection device or on-premises. Consequences to remember:

• Even traffic to Azure services' public IPs now goes to the NVA — unless you enable a service endpoint (which adds a longer, non-overridable prefix that wins) or a UDR keeps 0.0.0.0/0 → Internet.
• Adding a 0.0.0.0/0 UDR causes Azure to remove the None routes for the reserved private prefixes from that subnet's table.
• Do not associate a route table with a 0.0.0.0/0 route to a GatewaySubnet — it can break the VPN gateway.

Exercise 2 — Force all egress through a firewall NVA

Design the route table for Subnet1 (VNet 10.0.0.0/16) so that all outbound traffic is inspected by a firewall NVA at 10.0.100.4, but intra-subnet traffic within 10.0.0.0/24 stays local. Present it as a route table.

Solution.

Route name	Address prefix	Next hop type	Next hop IP
Within-Subnet1	10.0.0.0/24	Virtual network	—
Default-NVA	0.0.0.0/0	Virtual appliance	10.0.100.4

Reasoning: 0.0.0.0/0 → Virtual appliance overrides the default 0.0.0.0/0 → Internet (same prefix, UDR wins), catching all egress. The 10.0.0.0/24 → Virtual network route is a longer prefix than 0.0.0.0/0, so intra-subnet traffic matches it first and never reaches the NVA — avoiding a needless hairpin. Also enable IP forwarding on the NVA's NIC and place the NVA in a separate subnet to avoid a routing loop. This is exactly the service-chaining pattern that lets a hub firewall inspect spoke traffic.

BGP routes and disabling propagation

When on-premises exchanges routes with an Azure virtual network gateway over BGP, Azure adds a route (source and next hop = Virtual network gateway) to all subnets for each advertised prefix. Notes:

• With an ExpressRoute gateway you must use BGP and cannot create UDRs pointing at the ExpressRoute gateway (though you can UDR that traffic to an NVA instead). With a VPN gateway, BGP is optional.
• You can disable virtual network gateway route propagation as a property on the route table — this stops both static and BGP gateway routes from being added to associated subnets. Useful in hub-and-spoke when you want spokes to reach on-premises only via a 0.0.0.0/0 UDR to the hub NVA.

Note: Never disable route propagation on the GatewaySubnet — the gateway stops functioning.

Exercise 3 — Troubleshoot: on-prem traffic blackholed after a UDR

After you added a UDR to force egress through the NVA, users report on-premises apps (10.10.0.0/16, reached via the VPN gateway) are now unreachable, while internet browsing still works through the firewall. What happened and how do you fix it?

Solution. The 0.0.0.0/0 → Virtual appliance UDR is now the longest match for on-prem destinations too, so on-prem traffic is sent to the NVA instead of the VPN gateway. If the NVA has no path to on-premises (or drops it), the traffic is effectively blackholed. The original 10.10.0.0/16 → Virtual network gateway route was a system route added by the gateway; it is more specific than 0.0.0.0/0, so it should still win — but if it was removed by disabling route propagation, or overridden, on-prem breaks. Fix: add an explicit UDR 10.10.0.0/16 with next hop Virtual network gateway (or, if the design intends inspection, 10.10.0.0/16 → Virtual appliance where the NVA does have on-prem connectivity). Being a longer prefix than 0.0.0.0/0, it is selected first. Verify with Network Watcher → Next hop for a source VM to destination 10.10.0.10: it should return VirtualNetworkGateway, not VirtualAppliance.

Diagnosing routes

Two tools you must know for AZ-104:

• Effective routes (per NIC): the combination of your route tables, Azure defaults, and BGP-propagated routes. View on the VM's NIC (Networking → Effective routes) or az network nic show-effective-route-table. This is the ground truth for "which routes actually apply".
• Network Watcher → Next hop: enter a source VM/NIC and a destination IP; Azure returns the next hop type, IP address, and route table ID (or System Route if a system route decided it). Network Watcher next hop types include Internet, VirtualAppliance, VirtualNetworkGateway, VirtualNetwork, VirtualNetworkPeering, VirtualNetworkServiceEndpoint, MicrosoftEdge, and None. If it returns None, the traffic is being dropped — a strong signal of a misconfigured or missing route.

Key takeaways

• Azure auto-creates system routes per subnet: Virtual network, Internet (0.0.0.0/0), and None for reserved private prefixes. You can't delete them, but UDRs override them.
• Optional system routes appear only when you enable a feature: Virtual network peering, Virtual network gateway (BGP), VirtualNetworkServiceEndpoint.
• Route selection = longest-prefix match first, then UDR > BGP > system. Virtual-network / peering / service-endpoint system routes are preferred and service-endpoint routes can't be overridden.
• A UDR lives in a route table associated to subnets (0 or 1 table per subnet, up to 400 routes, same region/subscription).
• Forced tunneling = 0.0.0.0/0 → Virtual appliance/gateway. For an NVA you must set its next hop private IP, enable IP forwarding, and place it in a separate subnet.
• Diagnose with effective routes (per NIC) and Network Watcher next hop; None means dropped.

Quick recall

1. Q: What are the three always-present default next hop types on a new subnet? A: Virtual network, Internet (0.0.0.0/0), and None (for reserved private prefixes 10/8, 172.16/12, 192.168/16, 100.64/10).
2. Q: Two routes match a destination equally on prefix length — one BGP, one UDR. Which wins? A: The UDR (priority order UDR > BGP > system).
3. Q: For destination 10.0.0.5 with routes 10.0.0.0/24 and 10.0.0.0/16 present, which route is used? A: The 10.0.0.0/24 route — it is the longer (more specific) prefix.
4. Q: What must be enabled on an NVA's NIC for it to forward transit traffic, and where should the NVA live? A: Enable IP forwarding on the NIC; deploy the NVA in a different subnet than the workloads routed through it to avoid a routing loop.
5. Q: Which system routes cannot be overridden by a route table? A: Routes with a VirtualNetworkServiceEndpoint next hop type (and VNet/peering system routes are preferred over more-specific BGP routes).

Coming up

Routing decides where a packet may go; next we control whether it is allowed at all — Episode 5: Network Security — NSGs & Application Security Groups, where stateful rules filter traffic by 5-tuple at the subnet and NIC.