UDR to send all the 0.0.0.0/0 to Azure firewall is getting bypassed

The behavior indicates that not all traffic from the VM is actually following the 0.0.0.0/0 → Azure Firewall UDR. In Azure, the effective route with the longest prefix and highest precedence wins, so other routes can override or bypass the firewall even when a default route to the firewall exists.

Key Azure routing behaviors from the context that explain this:

1. UDR vs system routes and longest-prefix match
   • In a hub-spoke design, the intended pattern is: each spoke subnet has a UDR with 0.0.0.0/0 next hop = Azure Firewall private IP, so all north-south and east-west traffic is inspected.
   • However, any more specific route (for example, /32 or a smaller CIDR) will override the 0.0.0.0/0 UDR.
   • For private endpoints, Azure automatically injects a /32 system route with nextHopType: InterfaceEndpoint. This /32 route overrides a broader UDR such as 10.0.0.0/8 → VirtualAppliance or 0.0.0.0/0 → VirtualAppliance, causing traffic to bypass the firewall.
   From the context:
   • “The private endpoint /32 system route (with a next hop value of InterfaceEndpoint) overrides a less-specific user-defined route (for example, 10.0.0.0/8 → VirtualAppliance) through longest-prefix-match. In hub-spoke architectures, this behavior causes private endpoint traffic to bypass the central firewall or NVA.”
   • Diagnostic table explicitly calls out that when a /32 InterfaceEndpoint route exists plus a broader UDR to a firewall, the /32 wins and bypasses the firewall.
2. Firewall subnet and system routes
   • The AzureFirewallSubnet itself normally uses system routes to reach spokes and the internet and does not require UDRs in most scenarios.
   • Spoke subnets must have their own UDRs pointing to the firewall private IP. If the VM subnet is missing or misconfigured, traffic may go directly to the internet or to other destinations using system routes.
3. Other NVAs / gateways can also override the path
   • If there is a VPN gateway, ExpressRoute, or another NVA advertising a more specific route (for example, 0.0.0.0/0 via BGP or a more specific prefix), traffic can be forced through that path instead of the firewall.
   • The Q&A example in the context shows a misroute where Azure Storage traffic was forced through a VPN gateway instead of the firewall; once that route was removed, traffic correctly went to Microsoft over the intended path.

How to troubleshoot why the firewall is being bypassed

Use these steps to confirm the actual routing and identify what is overriding the 0.0.0.0/0 → Firewall UDR:

1. Check effective routes on the Ubuntu VM NIC
   In the Azure portal, go to the VM → Networking → NIC → Effective routes. Look for:
   • A /32 route for any private endpoint IPs with nextHopType: InterfaceEndpoint. If present, this traffic bypasses the firewall.
   • Any more specific prefixes than 0.0.0.0/0 (for example, 10.0.0.0/8, x.x.x.x/32) with nextHopType not equal to VirtualAppliance pointing to the firewall.
   • Any BGP or gateway routes that might be taking precedence.
   Use the diagnostic table from the private endpoint article:
   • If you see /32 with InterfaceEndpoint and also a broader UDR to VirtualAppliance, the private endpoint route is bypassing the firewall.
2. If private endpoints are involved, add a /32 UDR back to the firewall
   When a private endpoint /32 route is overriding the firewall path, the recommended fix is:
   • Add a UDR with destination = the private endpoint IP /32, next hop type = VirtualAppliance, next hop IP = Azure Firewall private IP, on the source subnet.
   • This restores inspection by making the UDR /32 more specific than the system /32 InterfaceEndpoint route.
   The context notes:
   • “Add a /32 UDR for the private endpoint IP pointing to the firewall or NVA so traffic still traverses the inspection path.”
   • After adding, re-check effective routes; nextHopType should show VirtualAppliance for that /32.
3. Verify the UDR association on the VM subnet
   • Confirm that the route table containing 0.0.0.0/0 → VirtualAppliance (Firewall private IP) is actually associated with the subnet where the Ubuntu VM resides.
   • Each subnet can have zero or one route table associated. If another route table is associated, or none is associated, the expected UDR will not apply.
4. Confirm hub-spoke pattern is correctly implemented
   For a standard hub-spoke with Azure Firewall:
   • Spoke (or VM) subnet route table should have:
     • 0.0.0.0/0 → Virtual appliance → Firewall private IP.
     • Any required spoke-to-spoke prefixes → Virtual appliance → Firewall private IP.
   • Ensure there are no conflicting routes that send traffic directly to the internet or to another NVA/gateway for the destinations you are testing.
5. Check for misroutes via VPN/ExpressRoute or other NVAs
   • Review effective routes for any prefixes where nextHopType is VirtualNetworkGateway or another NVA instead of VirtualAppliance to the firewall.
   • If found, adjust BGP advertisements or UDRs so that traffic intended to be inspected by the firewall is not forced through the gateway.
6. Validate that firewall logs match the effective routes
   • After correcting routes, test again with nc from the VM.
   • Confirm that the firewall now logs the connections (network/application rule logs) and that policy rules behave as expected.

If, after these checks, effective routes still show nextHopType: InterfaceEndpoint or another next hop for the tested IPs, the firewall will continue to be bypassed until a more specific UDR to the firewall is added or the conflicting route is removed.

References:

• Azure Firewall and traffic inspection (lift-shift)
• Azure Firewall and traffic inspection (modernize)
• Troubleshoot private endpoint connectivity failures
• Use Azure Firewall to manage and secure Windows 365 environments
• Limit network traffic with Azure Firewall in Azure Kubernetes Service (AKS) (user)
• Azure Firewall and Application Gateway for virtual networks
• Express virtual network injection method
• Azure Firewall blocking access to Power BI blob storage endpoint despite Network Rule allowing Storage service tag - Microsoft Q&A