Skip to main content
Diagnosing Azure routing issues can be straightforward if you follow a repeatable checklist. This guide provides an ordered troubleshooting flow to find and fix routing problems quickly. Work through the steps in sequence — most faults stem from a missing, conflicting, or misdirected route or from a required device being down.

​
Quick checklist (summary)

  • Effective routes (per NIC)
  • Network Watcher diagnostics
  • User-defined routes (UDRs)
  • Route table associations
  • Asymmetric routing (and IP forwarding)
  • Gateway / NVA health
  • NSGs, Azure Firewall, and appliance rules

​
1. Check effective routes

Start by examining the effective routes for the VM’s network interface (or the VM itself). In the Azure portal: VM → Networking → Network interface → Effective routes. This view shows the exact routes Azure is using for outbound traffic from that NIC. Look for:
  • Missing routes for expected prefixes
  • Unexpected next hops or metrics
  • UDRs that override system routes
Remember: Azure uses longest-prefix-match (most specific route). A user-defined route (UDR) that matches the same prefix as a system route will take precedence.

​
2. Use Azure Network Watcher

Network Watcher gives targeted diagnostics to visualize and simulate traffic flows:
  • IP Flow Verify — checks whether traffic is allowed/blocked by NSGs and returns the evaluated flow.
  • Next Hop — shows the next hop Azure will use between two points.
  • Connection Troubleshoot / Connectivity Check — simulates a connection and helps locate path breaks.
If Network Watcher isn’t available in your region, enable the Network Watcher resource for that region in the portal.
Network Watcher’s IP Flow Verify, Next Hop, and Connection Troubleshoot often pinpoint the misconfiguration quickly — use them early in your investigation.

​
3. Review user-defined routes (UDRs)

UDRs override Azure’s system routes when their prefixes match. Validate each custom route:
  • Route prefix — is it correct and not overly broad?
  • Next hop type — VirtualAppliance, VirtualNetworkGateway, Internet, VirtualNetwork, VnetLocal, None, etc.
  • Next hop IP — is the IP reachable and correct for the intended appliance?
Common mistakes: overlapping prefixes, wrong next hop IP (steering to a non-forwarding VM), or using an inappropriate next hop type.
Next Hop TypeUse CaseExample / Notes
VirtualApplianceSend traffic to a firewall or NVANext hop IP should be the NVA’s NIC IP
VirtualNetworkGatewayRoute to VPN or ExpressRoute gatewayUsed for on-premises connectivity
InternetSend to internetUsed to force internet-bound traffic out
VirtualNetwork / VnetLocalLocal network routesFor intra-VNet routing
NoneDrop trafficExplicitly drop matched traffic

​
4. Confirm route table associations

A route table only affects subnets it’s associated with. Verify:
  • Each subnet is associated with the intended route table.
  • There are no accidental associations (a route table attached to the wrong subnet will cause unexpected routing).
  • If a subnet has no associated route table, Azure uses built-in system routes.

​
5. Watch for asymmetric routing

Asymmetric routing occurs when outbound and return packets take different paths. This can break stateful devices (firewalls, NATs) and cause connection failures. If you’re steering traffic through a firewall or NVA:
  • Ensure both directions can traverse the device.
  • Confirm the return path will route via the same appliance when required.
  • Check health probes and routing on hub/spoke topologies that rely on a central forwarder.
If a traffic-forwarding VM/NVA is in the path, ensure IP forwarding is enabled on the NIC and the VM OS. Also verify security rules allow the forwarded traffic. Disabled IP forwarding or asymmetric routes are frequent causes of dropped packets.

​
6. Verify gateways and NVAs

Check the health and availability of any gateways (VPN Gateway, ExpressRoute gateway) and NVAs. If the hub appliance or gateway is down, traffic will be dropped. For a VM acting as a forwarder:
  • Confirm the VM is running and reachable.
  • Enable OS-level IP forwarding.
  • Enable IP forwarding on the VM’s network interface (Azure portal → NIC → IP forwarding).
  • Verify NSGs and host firewall rules on both the NIC and the VM.
Example: enable IP forwarding on a Linux forwarder 
# Enable immediate IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# To persist across reboots, add/ensure in /etc/sysctl.conf:
# net.ipv4.ip_forward = 1

​
7. Double-check network security groups and other controls

NSGs, Azure Firewall, and appliance-level firewall rules can block expected traffic even if routing is correct. Validate:
  • NSG inbound/outbound rules on NICs and subnets.
  • Azure Firewall policies and application rules.
  • Appliance NAT or application-level filtering (user-defined NAT/SNAT/DNAT) — make sure these rules match your routing plan.

​
Troubleshooting tools and where to use them

Problem areaTool/Action
Verify what Azure route is appliedEffective routes (portal)
Determine evaluated security rulesIP Flow Verify (Network Watcher)
Find Azure next hopNext Hop (Network Watcher)
Simulate a full connection pathConnection Troubleshoot / Connectivity Check
Check NIC forwarding settingNIC Networking blade (Azure portal)
OS-level forwardingsysctl, firewall-cmd/iptables, or Windows registry

​
Summary — ordered approach

  1. Inspect effective routes for the VM/NIC.
  2. Run Network Watcher diagnostics (IP Flow Verify, Next Hop, Connectivity Check).
  3. Validate UDRs: prefixes, next hop type, and next hop IP.
  4. Confirm route table to subnet associations.
  5. Check for asymmetric routing and IP forwarding on NVAs.
  6. Verify gateway / NVA health and availability.
  7. Re-check NSGs, Azure Firewall, and appliance-level rules.
Most routing issues reduce to: a missing or conflicting route, traffic steered to an offline device, or security rules blocking flows. Methodically working through the steps above will resolve the majority of Azure routing problems.
A presentation slide titled "Diagnosing a Routing Problem" showing six numbered troubleshooting steps. The steps list checking effective routes, using Network Watcher, adding/removing custom routes, checking subnet association, and verifying gateway/NVA status.
Check each step in order

Watch Video