System routes exist for every subnet: between subnets of the VNet, to peered VNets, to on-premises through VPN/ExpressRoute gateways, and 0.0.0.0/0 to the Internet. They exist even before you create any route.
A route table holds user-defined routes (UDRs): each route has a destination address prefix and a next hop:
| Next hop type | Meaning |
|---|---|
VirtualAppliance |
Send to the IP of an NVA/Azure Firewall (needs --next-hop-ip-address) |
VirtualNetworkGateway |
Send through the VPN gateway |
VnetLocal |
Keep inside the VNet |
Internet |
Go to the Internet |
None |
Drop the packet (block) |
flowchart LR W["snet-web 10.10.1.0/24<br/>route table rt-fw"] -- "0.0.0.0/0 → 10.10.2.4" --> F["NVA / Firewall 10.10.2.4"] F --> A["snet-app"] F --> I["Internet"]
- A route table attaches to a subnet (not to a VNet or a VM).
- The longest (most specific) prefix wins; for equal prefixes, a UDR beats a system route.
- An NVA running on a VM needs IP forwarding enabled on its NIC, otherwise packets are dropped.
- Check the result with the NIC's effective routes.
| Command | Meaning |
|---|---|
az network route-table create -g rg-devops-lab -n rt-fw |
Create a route table |
az network route-table route create ... --next-hop-type VirtualAppliance --next-hop-ip-address 10.10.2.4 |
Add a UDR |
az network vnet subnet update ... --route-table rt-fw |
Attach it to a subnet |
az network nic show-effective-route-table -g rg-devops-lab -n nic-web-01 -o table |
Effective routes |
Where routes come from
A subnet's effective routes combine three sources:
| Source | Example |
|---|---|
| System routes | VNet range, peered VNets, 0.0.0.0/0 to Internet |
| BGP routes | Prefixes learned from on-premises through a VPN or ExpressRoute gateway |
| User-defined routes | Your route table entries |
When several routes match, the longest prefix wins. For the same prefix, a UDR is preferred over a BGP route, and a BGP route over a system route.
Controlling gateway routes
A route table has a propagate gateway routes setting. Turning it off stops BGP routes from the VPN or ExpressRoute gateway being added to that subnet, which is how you force all traffic, including traffic to on-premises, through a firewall in the hub.
Common patterns
- Spoke-to-spoke through a hub firewall: each spoke subnet gets a route for the other spokes' prefixes (or
0.0.0.0/0) with the firewall as next hop, because peering is not transitive. - Forced tunnelling:
0.0.0.0/0points to the VPN gateway so internet traffic leaves through the office for inspection. - Service tags in routes: a route's address prefix can be a service tag such as
StorageorAzureMonitor, which keeps it valid when Azure changes its ranges. - Azure Route Server lets a network appliance exchange routes with the VNet over BGP instead of maintaining UDRs by hand.
Troubleshooting
Asymmetric routing is the classic failure: traffic goes out through the firewall but the reply returns another way, and the stateful firewall drops it. Make sure both directions follow the same path. Network Watcher Next hop (az network watcher show-next-hop) tells you which route a packet from a VM to a destination will use and why.