Azure Route Tables: Controlling Network Traffic

How Azure routes traffic by default

Every subnet in Azure has a set of system routes created automatically. These routes define the default path for different types of traffic:

VNet-local routes: Traffic destined for any address in the VNet’s address space goes directly to the destination VM. No gateway, no hop.

Internet route: Traffic destined for addresses outside the VNet goes to the internet via Azure’s edge routers, provided the source has a public IP or NAT gateway.

Peering routes: When you peer two VNets, Azure automatically adds routes so traffic destined for the peered VNet’s address space routes correctly.

You cannot see or edit system routes directly, but you can override them with a route table attached to a subnet.

When you need a route table

You need a custom route table in these scenarios:

Forced tunneling. You want all internet-bound traffic from a subnet to go through Azure Firewall or a third-party NVA before leaving Azure. By default, traffic goes directly to the internet. A route table with a 0.0.0.0/0 route pointing to the firewall forces all internet traffic through inspection.

Hub-and-spoke with centralized inspection. In a hub-and-spoke network, spoke VNets peer to the hub. Without route tables, spoke-to-spoke traffic goes directly between spokes. If you want all east-west traffic to pass through a hub firewall, route tables in each spoke redirect that traffic to the hub.

On-premises routing. When using a VPN or ExpressRoute, you sometimes need route tables to control which subnets route to on-premises and which ones don’t.

Next hop types explained

Every route has a next hop — where traffic goes after matching the route. Azure supports these next hop types:

Creating and assigning route tables

Build a route table that forces all internet traffic through Azure Firewall (a common production pattern):

# Create the route table
az network route-table create \
  --name rt-spoke-web \
  --resource-group rg-prod-networking \
  --location eastus \
  --disable-bgp-route-propagation true

The —disable-bgp-route-propagation true flag prevents VPN gateway routes from overriding your custom routes. Set this to true when using a hub firewall to control all traffic.

# Add a default route pointing to Azure Firewall's private IP
az network route-table route create \
  --name route-to-internet \
  --route-table-name rt-spoke-web \
  --resource-group rg-prod-networking \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.0.4

# Add a route to drop traffic to a specific bad actor IP range
az network route-table route create \
  --name route-block-badactors \
  --route-table-name rt-spoke-web \
  --resource-group rg-prod-networking \
  --address-prefix 198.51.100.0/24 \
  --next-hop-type None

# Associate the route table with a subnet
az network vnet subnet update \
  --name snet-web \
  --resource-group rg-prod-networking \
  --vnet-name vnet-prod-eastus-001 \
  --route-table rt-spoke-web

List all routes in a route table:

az network route-table route list \
  --route-table-name rt-spoke-web \
  --resource-group rg-prod-networking \
  --output table

Check the effective routes on a VM’s network interface to see what routing is actually in effect:

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

This command is invaluable for debugging. It shows you the actual routes being applied to a NIC, including system routes, user-defined routes, and peering routes, with their sources and priorities.

Real failure mode: the routing loop

A routing loop is when traffic bounces between two hops indefinitely, never reaching its destination. This happens more often than you’d expect when setting up hub-and-spoke routing.

Scenario: You have a hub VNet with Azure Firewall at 10.0.0.4. You add a route table to the firewall’s subnet that says “send all traffic (0.0.0.0/0) to the internet.” But you also have a route in the same table that sends traffic back to the firewall. The packet goes: web server → firewall → firewall → firewall, forever.

The fix is to never put a route table on the AzureFirewallSubnet itself. Route tables belong on the spoke subnets pointing traffic toward the firewall. The firewall subnet uses system routes to reach its destinations directly.