User Defined Routes

​

System routes: what Azure provides by default

• Azure automatically creates system routes that enable:
  • VNet-local communication (VNet local).
  • Internet-bound traffic (0.0.0.0/0 → Internet).
  • Connectivity to virtual network gateways and service endpoints.
• System routes allow VMs and other resources in the same VNet to reach one another and perform outbound connections (e.g., to NTP or Windows Update).
• Inbound connections from the Internet are blocked by default unless you explicitly enable them with a public IP or an NSG; system routes alone do not open inbound access.

​

When you should use UDRs

• Use UDRs when you must override Azure’s default routes to:
  • Force traffic through an NVA/firewall for inspection, logging, or policy enforcement.
  • Send traffic to a specific next hop (for example, to an on‑premises VPN gateway or to a virtual appliance).
• Common pattern: create a route table with a route that directs traffic from a subnet to the NVA’s private IP (Next hop type: Virtual appliance), then associate that table with the subnet so the UDR overrides the system route for matching destinations.
• The NVA can then inspect and forward traffic to other subnets (for example, to a database subnet) based on its own rules.

​

Important networking prerequisites

• VNets containing the source subnet and the NVA must have connectivity (for example, VNet peering). If the NVA is in a different VNet, peering must be configured to allow forwarded traffic.
• A UDR that points to an NVA IP is only effective if the source subnet can actually reach that IP. Without connectivity (peering, route, or gateway connectivity), the next hop will be unreachable even though the route exists.

​

Creating a route table — portal walkthrough

1. Open the Azure portal and search for “Route tables” or follow the Route Table overview documentation: Route tables.
2. Create a new route table (for example, rt-intersite). Choose the target subscription, resource group, and region. Optionally enable Propagate gateway routes if you want routes learned from a virtual network gateway to be propagated into this table.
3. After deployment, open the route table and add user-defined routes under the Routes section — specify destination prefixes, next hop type, and next hop address (when applicable).

​

Associating the route table with a subnet

• A route table can be associated with one or more subnets. Each subnet can have only one associated route table at a time.
• In the route table blade, use Subnets → Associate to pick the virtual network and subnet to apply the UDRs.
• Be cautious with the GatewaySubnet: associating or changing routes for the GatewaySubnet can disrupt VPN or ExpressRoute gateway operations.

​

Example UDR entries and expected behavior

• Because Azure uses longest-prefix match, a specific VNet-local route (e.g., 192.168.1.0/24) will match before the 0.0.0.0/0 default route, allowing you to create exceptions that bypass the NVA for chosen destinations.
• In many scenarios you only add exception prefixes to bypass the NVA; Azure already provides routes for VNet-local ranges.

​

Route priority and matching (quick reference)

• Azure route selection uses longest-prefix (most specific) match:
  • /27 (more specific) wins over /24.
  • /24 wins over 0.0.0.0/0 (default).
• Use this behavior to create specific exception routes that bypass the NVA while keeping a broad default route to the NVA for all other traffic.

​

Operational considerations

• You can combine multiple routes in a route table to send different destination ranges to different next hops (for example, some traffic to an internal firewall, other traffic to a VPN gateway).
• Confirm that VNet peering is configured to allow forwarded traffic when an NVA is in a peered VNet.
• Verify that NSG rules permit the intended flows — NSGs are applied before/after routing depending on the direction, so misconfigured NSGs can block traffic even when UDRs are correct.
• Monitor reachability and logs on both the NVA and Azure side to troubleshoot dropped or misrouted traffic.

​

Summary

• Use UDRs when you need to override Azure’s system routes (for example, to force inspection or apply security controls via an NVA/firewall).
• Create a route table, add UDRs using the appropriate destination prefixes and next hop types, and associate the table with the target subnet(s).
• Use longest-prefix match to design exception routes that bypass the NVA for specific destinations while routing all other traffic to the NVA.
• Always verify VNet peering and NSG configurations so that traffic can actually reach and be forwarded by the chosen next hop.

​

Links and references

• Azure Route tables overview
• Network security groups (NSGs)
• Virtual network peering overview