Azure Route Tables and User-Defined Routes (UDRs), Explained
Azure already knows how to move packets around your network. A user-defined route is how you tell it to stop doing the obvious thing and send traffic where you actually want it — usually through a firewall it would otherwise skip.
New to cloud? CAMPUX is a free, build-first course. Start here →
A user-defined route, or UDR, overrides Azure's default routing so you can steer traffic where you want it to go. By default, Azure hands every subnet a hidden set of routes that already handle the common cases — reaching other subnets, peered networks, gateways, and the internet — with nothing for you to configure. A UDR is what you write when that default sends traffic somewhere you do not want, and the most common reason is simple: you want everything leaving a subnet to pass through a firewall first. This note walks the whole model from the ground up, so the pieces stop feeling like magic.
System routes: what Azure gives you for free
When you create a virtual network, you do not write a single route and traffic still flows. That is because Azure builds a set of system routes for every subnet automatically. You cannot see them in the portal as editable entries, and you cannot delete them, but they are always there doing the plumbing.
The default system routes cover the cases you would expect to just work:
- Traffic to any address inside the VNet stays inside the VNet.
- Traffic to a peered virtual network is routed across the peering.
- Traffic to on-premises networks is sent to the virtual network gateway, when one exists.
- Everything else — the
0.0.0.0/0catch-all — is sent straight out to the internet.
That last one matters more than it looks. Out of the box, any resource with a public path can reach the internet directly, because the default route says so. For a lot of workloads that is fine. For anything you want inspected, logged, or held behind a security boundary, it is exactly the behavior you need to change. And changing a system route is the entire job of a UDR.
What a route table and a UDR are, and how you attach one
A route table is an Azure resource. It is a container that holds one or more routes you write by hand — your user-defined routes. On its own, a route table does nothing. It only takes effect once you associate it with a subnet.
Two rules about that association are worth memorizing early, because they shape every design:
- A subnet can have one route table associated with it at a time. Not two, not a stack — one.
- A single route table can be associated with many subnets at once. You write the rules once and reuse them.
So the pattern is: create a route table, add your UDRs to it, then attach it to whichever subnets should follow those rules. Each route inside the table names two things — a destination address prefix (which traffic this applies to, like 0.0.0.0/0 or 10.20.0.0/16) and a next hop (where that traffic should go). When a packet leaves a subnet, Azure looks at all the routes that apply — system, plus any you added — and picks the winner. Your UDR wins over the system route for the same prefix, which is how the override happens.
A route table does nothing until it is attached to a subnet. That one line saves people hours of "why is my UDR not working."
Next-hop types: the five places you can send traffic
Every route ends in a next hop, and Azure gives you exactly five next-hop types to choose from. Learn these five and you can read almost any route table at a glance.
- Virtual network gateway — send the traffic to a VPN or ExpressRoute gateway. This is how you push traffic toward on-premises over a tunnel.
- Virtual network — keep the traffic inside the VNet. You use this to override a more specific route and force something to stay local.
- Internet — send the traffic explicitly out to the public internet. Useful when you want a specific prefix to bypass a firewall you have pointed everything else at.
- Virtual appliance — send the traffic to an IP address you name, typically the private IP of a firewall or a network virtual appliance (NVA). This is the type that does the real work in most security designs.
- None — drop the traffic. Anything matching this route goes nowhere. It is a deliberate black hole, handy for blocking a prefix outright.
The one people reach for constantly is Virtual appliance, because it lets you insert a device into the path. You point a route at a firewall's IP, and now traffic that used to go straight out has to stop there first. That single move is the backbone of the most common UDR scenario in the wild.
The classic use case: forcing traffic through a firewall
Here is the scenario you will build more than any other. You have a subnet full of workloads. By default, their outbound traffic follows the system route for 0.0.0.0/0 and goes straight to the internet — unseen, uninspected. Security wants that traffic to pass through Azure Firewall (or a third-party NVA) so it can be filtered and logged.
You do it with one UDR:
- Destination:
0.0.0.0/0— all traffic. - Next-hop type: Virtual appliance.
- Next-hop IP: the firewall's private IP address.
Attach the route table holding that route to the workload subnet, and the override takes hold. The system default route to the internet still exists, but your UDR for the same prefix wins, so every packet leaving the subnet now lands on the firewall first. The firewall inspects it, applies its rules, and forwards what it allows. This is called forced tunneling when the same idea steers internet-bound traffic back to on-premises, and it is the reason UDRs exist for most teams.
Deploy the firewall or NVA in a different subnet from the workloads that route through it. If the appliance lives in the same subnet whose route table points at it, you can create a loop where traffic never leaves — it keeps getting routed back to the appliance's own subnet. A dedicated appliance subnet is the standard, boring, correct layout.
The gap: route precedence and the gotchas that break connectivity
Now the part that trips people up in production. A subnet can end up with routes from three different sources at once — system routes, routes learned over BGP (from an ExpressRoute or VPN gateway), and your UDRs. When more than one route covers the same destination, Azure has to choose, and the choice follows two rules in order.
First, Azure applies longest-prefix match. The most specific route always wins, full stop. A route for 10.0.1.0/24 beats a route for 10.0.0.0/16 for an address in that smaller range, regardless of where either route came from. This is the rule people forget, and it causes the classic surprise: you write a UDR for 0.0.0.0/0 to send everything to the firewall, but a more specific route somewhere else quietly wins for part of the traffic.
Only when two routes share the exact same prefix does the precedence order break the tie: UDR beats BGP beats system route.
| Route source | Who creates it | Precedence (same prefix) | Typical use |
|---|---|---|---|
| User-defined route | You, in a route table attached to the subnet | Highest — wins the tie | Force traffic through a firewall or NVA; override the default internet route |
| BGP route | Learned dynamically from a VPN or ExpressRoute gateway | Middle | Reach on-premises networks advertised over a tunnel |
| System route | Azure, automatically, for every subnet | Lowest — the default baseline | VNet-local, peering, and default internet reachability with no config |
A few gotchas follow directly from this model, and each one has broken someone's connectivity at 2am:
- The firewall route with no return path. You send
0.0.0.0/0to the appliance but forget the appliance itself needs a working route back out to the internet. Traffic reaches the firewall and dies there. - Longest-prefix surprise. A specific route learned over BGP (say a
/32or a tight subnet) beats your broad0.0.0.0/0UDR for that address, so a slice of traffic bypasses the firewall even though your UDR "looks" like it covers everything. - The dropped-traffic black hole. A leftover route with next-hop None, or a UDR pointing at an appliance IP that no longer exists, silently discards packets. There is no error — connections just time out.
- Service endpoint and platform routes you cannot override. Some Azure-managed routes, such as those for a virtual network service endpoint, take priority and cannot be overridden by a route table. If a UDR seems to be ignored, check whether a platform route is winning.
The habit that keeps you out of trouble: when routing behaves strangely, stop guessing and look at the effective routes on the network interface. Azure shows you the exact merged list — system, BGP, and UDR combined, with the winner marked — for that specific NIC. It answers "where is this packet actually going" in one screen, and it is the first place a working engineer looks.
UDRs rarely travel alone. See how NAT Gateway gives a subnet clean outbound internet, why private endpoints change the routing story for PaaS services, and how VNet peering stitches networks together before you start steering traffic between them.
Questions people also ask
What is a user-defined route in Azure?
A user-defined route, or UDR, is a route you write yourself and attach to a subnet through a route table. It overrides the system routes Azure creates automatically. Each UDR names a destination address prefix and a next hop — where traffic to that prefix should go. The most common one sends 0.0.0.0/0, all traffic, to a firewall instead of straight out to the internet.
What is the difference between system routes and UDRs?
System routes are created and maintained by Azure for you: they let a subnet reach other subnets in the VNet, peered VNets, gateways, and the internet, with nothing to configure. UDRs are routes you create to override that default behavior. System routes are the free baseline; a UDR is how you change it when the baseline sends traffic somewhere you do not want.
What are the next hop types in Azure?
Azure supports five next-hop types in a route table: Virtual network gateway (send to a VPN or ExpressRoute gateway), Virtual network (keep it inside the VNet), Internet (send explicitly out to the public internet), Virtual appliance (send to an IP address such as a firewall or NVA), and None (drop the traffic). The virtual appliance type is the one you use to steer traffic through a firewall.
How do I force traffic through Azure Firewall?
You attach a route table to the subnet with a UDR for 0.0.0.0/0 whose next-hop type is Virtual appliance and whose next-hop IP is the firewall's private IP. That overrides the system default route to the internet, so all outbound traffic goes to the firewall first. The firewall then inspects, allows or denies, and forwards the traffic on.
What takes precedence, UDR or BGP?
A UDR takes precedence over a BGP route, which takes precedence over a system route, when they cover the same address prefix. The full order is UDR > BGP > system. Before that comparison happens, Azure applies longest-prefix match, so a more specific route always wins first; the precedence order only breaks ties between routes with the same prefix.