Every subnet has a set of effective routes built from system routes, routes learned over BGP and any user-defined routes. Knowing how Azure chooses between them explains most “why didn’t my traffic go through the firewall?” problems.
Longest prefix match first
- Azure picks routes by longest prefix match first. For example, a UDR for 10.0.0.0/24 to an NVA beats a BGP route for 10.0.0.0/16.
- The VNet address-space system route is more specific than a 0.0.0.0/0 UDR, so traffic between VMs in the same VNet goes direct, not via the NVA or VPN. Figure 4.1 works through three destinations on a force-tunnelled subnet.
Common trap: Assuming that a 0.0.0.0/0 UDR to an NVA sends VM-to-VM traffic within the same VNet through the NVA - it doesn’t, because the VNet address-space system route is a longer prefix match.
Which subnets a route table affects
- A route table affects only the subnets it’s associated with. A subnet with no route table uses system routes (0.0.0.0/0 → Internet) plus BGP routes learned from the gateway.
- Peering doesn’t carry UDRs to the peered VNet; each subnet that needs custom routing needs its own route table association.
- A private DNS zone or an application security group can’t change routing.
Common trap: Assuming every subnet’s internet traffic passes through a hub firewall once some subnets have a default route to it - a subnet in a peered VNet with no UDR still goes straight to the Internet.
Valid route prefixes
- 255.255.255.255/0 is not a valid prefix; the default route is 0.0.0.0/0.
- A /32 matches one address.
- The VNet prefix doesn’t cover internet traffic.