Routing: UDRs, Route Server & NAT Gateway
Control traffic flow in Azure with user-defined routes, understand BGP route exchange via Route Server, and configure NAT Gateway for predictable outbound internet access.
Routing: UDRs, Route Server & NAT Gateway
Azure automatically routes traffic between subnets, to the internet, and to on-premises. But the real power — and what the exam tests — is overriding those defaults with custom routes. This module covers the full routing stack.
🎬 Video coming soon
Routing, UDRs, Route Server & NAT Gateway
Routing, UDRs, Route Server & NAT Gateway
~15:00Routing is the GPS of your network — it decides which path every packet takes. Azure handles most routing automatically. But sometimes you need to override the GPS: send traffic through a firewall, force internet traffic through on-premises, or tell Azure about routes your NVA knows. That’s where user-defined routes (UDRs) come in.
System Routes — The Defaults
Every VNet comes with system routes that Azure creates automatically:
| Destination | Next Hop | Purpose |
|---|---|---|
| VNet address space | VNet (direct) | Intra-VNet traffic between subnets |
| 0.0.0.0/0 | Internet | Default outbound internet access |
| 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | None (drop) | RFC 1918 ranges not in your VNet are dropped |
| VNet peering ranges | VNet peering | Added when peering is configured |
| VNG learned routes | Virtual network gateway | Added when VPN/ER gateway with BGP |
System routes work fine for basic scenarios. But enterprise architectures need control — that’s where UDRs come in.
User-Defined Routes (UDRs)
UDRs override system routes. You create a route table, add routes, and associate it with one or more subnets.
Next hop types:
| Next Hop Type | What It Does | Common Use |
|---|---|---|
| Virtual appliance | Sends traffic to a specific IP (NVA or firewall) | Force traffic through Azure Firewall |
| Virtual network gateway | Sends traffic to VPN/ER gateway | Forced tunneling to on-premises |
| Virtual network | Keeps traffic in the VNet (overrides dropped routes) | Re-enable routes that system routes block |
| Internet | Sends traffic directly to internet | Bypass firewall for specific destinations |
| None | Drops the traffic (black hole) | Block specific ranges |
🔒 Aisha’s scenario: Sentinel Banking requires all traffic to flow through Azure Firewall for inspection. She creates UDRs on every workload subnet:
Route Table: rt-workload-subnets
Route 1: 0.0.0.0/0 → Virtual appliance → 10.10.1.4 (Firewall private IP)
Route 2: 10.20.0.0/16 → Virtual appliance → 10.10.1.4 (Spoke-to-spoke via firewall)This overrides the default internet route and forces all outbound traffic through the firewall. Without these UDRs, traffic would go directly to the internet.
Route Priority
When multiple routes match a destination, Azure uses this priority order:
Exam Tip — Route Priority:
- User-defined routes (highest priority)
- BGP routes (from VPN/ER gateway)
- System routes (lowest priority)
Within the same priority level, longest prefix match wins. A /24 route beats a /16 route for the same destination because it’s more specific.
Example: If you have a system route for 0.0.0.0/0 to Internet and a UDR for 0.0.0.0/0 to Virtual appliance, the UDR wins. If you also have a UDR for 10.20.5.0/24 to a different appliance, that /24 beats the /0 for addresses in that range.
Forced Tunneling
🏢 Ravi’s scenario: Pinnacle Financial’s compliance team requires that all internet-bound traffic from Azure goes through the on-premises proxy for logging and inspection.
Ravi creates a UDR with 0.0.0.0/0 → Virtual network gateway. This forces all internet traffic from Azure through the VPN/ExpressRoute tunnel to on-premises, where the proxy inspects it before sending it to the internet.
Important caveat: Forced tunneling increases latency and can break Azure services that expect direct internet access. Platform services (like Azure Backup, Windows activation, Azure Monitor) may need service tags or specific route exceptions to function correctly.
Default Outbound Access — Going Away
Default Outbound Access Retirement
Historically, Azure VMs without an explicit outbound method (public IP, LB, NAT Gateway) could still reach the internet via default outbound access — a hidden SNAT that Azure provided automatically.
This is being retired:
- 30 September 2025: New resources in new subscriptions no longer get default outbound internet access
- 31 March 2026: New VNets have subnets that are private by default — no outbound unless you configure an explicit method
Existing VMs with default outbound access are not affected by these dates. However, Microsoft strongly recommends migrating to explicit outbound. Plan to use:
- NAT Gateway (recommended — best practice)
- Azure Firewall with SNAT rules
- Standard Load Balancer outbound rules
- Public IP on the NIC
The exam will test that you know default outbound is going away and what replaces it.
Azure Route Server
Route Server is a fully managed service that enables your Network Virtual Appliances (NVAs) to exchange routes with Azure’s network fabric via BGP.
| Feature | Manual UDRs | Azure Route Server |
|---|---|---|
| Route management | Create/update manually for each subnet | Automatic BGP route exchange |
| Scalability | Complex at scale — each route needs manual entry | NVA advertises routes via BGP, Azure learns them |
| Dynamic updates | Static — you must update routes when topology changes | Dynamic — routes update automatically |
| NVA support | UDRs point to NVA IP | NVA peers with Route Server via BGP |
| Deployment | Route tables on subnets | RouteServerSubnet (/27 minimum) |
| Transit routing | Manual UDRs required | Enables transit between ER and VPN when configured |
Route Server as a BGP route reflector: When you enable branch-to-branch on Route Server, it reflects routes between your VPN/ER gateways and NVAs. This enables transit routing — for example, on-premises traffic arriving via ExpressRoute can transit through an NVA and reach a branch office connected via S2S VPN.
NAT Gateway
NAT Gateway provides outbound-only internet access for resources in a subnet using one or more static public IPs.
🏪 Sam’s scenario: Harbour Retail’s 50 stores each connect to Azure APIs. Sam needs consistent outbound IPs so his vendors can allowlist them, and he needs to avoid SNAT port exhaustion.
| Feature | Public IP on NIC | Load Balancer Outbound | NAT Gateway |
|---|---|---|---|
| Scope | Per-VM | Per-backend pool | Per-subnet |
| Static IPs | Yes (Standard SKU) | Yes | Yes |
| SNAT ports | 64,000 per IP | Shared across pool (configurable) | 64,000 per IP per destination |
| Port exhaustion risk | Low (single VM) | Medium-high (shared pool) | Very low (dynamic allocation) |
| Zone redundancy | Standard SKU only | Standard SKU only | Yes (with zone-redundant IPs) |
| Management | Per-VM config | LB outbound rules | Subnet association — automatic for all resources |
| Cost | Public IP cost | LB + IP cost | NAT Gateway + IP cost |
Exam Tip — NAT Gateway Priority: NAT Gateway takes precedence over all other outbound methods for a subnet. If a VM has a public IP on its NIC and is also in a subnet with NAT Gateway, the NAT Gateway wins for outbound traffic. This is a common exam question.
NAT Gateway key facts:
- Supports up to 16 public IPs or public IP prefixes
- Provides up to 50,000 concurrent connections per IP to the same destination
- No inbound initiation — outbound only, return traffic allowed
- Subnet-level association — all resources in the subnet use it automatically
- Not compatible with Basic SKU resources in the same subnet
Diagnosing Routing Issues
When traffic isn’t flowing as expected, use these Network Watcher tools:
| Tool | What It Shows |
|---|---|
| Effective Routes | All routes applied to a NIC — system, UDR, and BGP combined |
| Next Hop | Which next hop Azure will use for a specific source/destination pair |
| Connection Troubleshoot | Tests end-to-end connectivity and shows where it breaks |
🔒 Aisha’s debugging: A workload VM can’t reach the internet. She checks Effective Routes and sees her UDR (0.0.0.0/0 to firewall) is active. She checks the firewall and finds the application rule for outbound HTTPS is missing. Problem solved — the route was correct, the firewall rule was the issue.
Key Takeaways
- UDRs override system routes; longest prefix match resolves conflicts within the same priority
- Forced tunneling sends all internet traffic through on-premises via 0.0.0.0/0 to gateway
- Default outbound access is retiring — plan explicit outbound (NAT Gateway recommended)
- Route Server enables dynamic BGP route exchange with NVAs
- NAT Gateway takes priority over all other outbound methods on a subnet
Test Your Knowledge
Aisha wants all workload traffic to flow through Azure Firewall at 10.10.1.4. What UDR should she create?
A subnet has both a UDR for 10.20.0.0/16 pointing to a firewall and a BGP route for 10.20.5.0/24 from VPN. Which route wins for traffic to 10.20.5.10?
Which outbound method takes highest precedence when associated with a subnet?
Next up: VNet Peering and Connectivity — Connect VNets with peering, enable gateway transit, and explore Azure Virtual Network Manager.