R
Ramesh Subramani
Guest
An engineering look at route selection, stateful firewalls, and practical troubleshooting in Microsoft Azure.
For cloud network and security engineers designing centralized inspection in Azure.
A firewall rule can be correct, logging can be on, and the appliance can be healthy, yet traffic may still reach its destination without ever passing through the inspection point. In Azure, routing and policy enforcement are separate layers: user-defined routes (UDRs), BGP-learned routes, virtual network peering, and managed connectivity services decide where packets go, and none of them consult your firewall policy. A firewall cannot inspect traffic it never receives.
The example below is a lab-style scenario with fictional addresses, built from publicly documented Azure behavior. The later sections cover return paths, Virtual WAN, and who is allowed to change routes.
Azure picks a route for outbound subnet traffic by longest prefix match, so a more specific route beats a broader one even when the broader route is a UDR you wrote on purpose. Route source only matters as a tie-breaker.
Suppose an application subnet has these routes:
For traffic to 10.40.2.15, Azure selects the /24 BGP route, because /24 is more specific than the /16. The UDR covers the address, but it loses the comparison.
When two routes have identical prefixes, Azure generally prefers a user-defined route, then a BGP route, then a system route. Prefix length is evaluated first and route source second, as described in Microsoft's virtual network traffic routing documentation.
Peering, gateways, and some service-specific features add routes of their own, and whether BGP routes reach a subnet depends on the BGP propagation setting on its route table. Azure also has exceptions for certain preferred system routes,particularly those tied to virtual networks, peering, and service endpoints, so analyze those separately when you read effective routes.
For a centralized firewall design, the UDR configuration alone tells you very little. The effective routes on the source workload are what Azure will actually use.
The lab has three segments. The application subnet 10.20.1.0/24 and the firewall subnet 10.10.1.0/24 sit in Azure. The database subnet 10.40.2.0/24 is on-premises, reached through a virtual network gateway over ExpressRoute or a site-to-site VPN. The firewall NVA's private IP is 10.10.1.10, and the database server is 10.40.2.15.
The intended design sends application-to-database traffic through the firewall in both directions:
Forward: App VM 10.20.1.20 --> Firewall NVA 10.10.1.10 --> Database 10.40.2.15
Return: Database 10.40.2.15 -->Firewall NVA 10.10.1.10 --> App VM 10.20.1.20
To make that happen, the application subnet gets a UDR for the on-premises summary 10.40.0.0/16 with the firewall as next hop. Meanwhile, the on-premises router advertises the specific prefix 10.40.2.0/24 over BGP, and the application subnet's route table allows gateway route propagation. The effective routes now look like this, with the gateway's next-hop IP left blank (illustrative values, not captured from a live environment)
"Active" means a route is available for selection.The most specific matching prefix still decides which one is used for a given destination, so traffic to 10.40.2.15 follows the BGP /24 into the gateway and never reaches the firewall. The firewall configuration remains unchanged, and its traffic logs may show no evidence of the connection because the packets never reached the appliance.
In the Azure portal, open the VM's network interface and select Effective routes. The viewlists each route with its source, state, prefix, and next hop. The same data is available from the CLI:
az network nic show-effective-route-table \
--resource-group <resource-group>\
--name <nic-name> \
--output table
The command needs an existing VM NIC and permissions to read it. Look for any prefix more specific than your UDR that covers the destination.
Effective routes show what is available. Network Watcher Next hop answers the narrower question of which next hop Azure will pick for a given source VM and destination IP. In the lab, the destination is 10.40.2.15, and the expected result is the virtual network gateway. If the design says the firewall, that single result exposes the mismatch.
Network Watcher Connection troubleshoot shows whether a connection can be established and where it fails. Then check the firewall's traffic logs. If the application connection succeeds but the firewall recorded no session, investigate. A missing log entry alone does not prove a bypass, because logging configuration, session matching, and collection delay can also explain it, but it is the right prompt to look at routes.
One fix is a UDR for 10.40.2.0/24 that points to the firewall. With identical prefixes, the user-defined route takes precedence over the BGP route:
Another option is to disable BGP route propagation on the application subnet's route table, which removes gateway-learned routes from that subnet entirely. That is a broader change and can break other on-premises connectivity, so test it before using it.
Either way, validate the result. The firewall needs a working onward route to the database. For an Azure NVA, IP forwarding must also be enabled on its network interface, and the appliance itself must be configured to forward the traffic. The on-premises return route must also direct traffic destined for the application subnet through the intended inspection path, using a supported routing design or an appropriate NAT strategy. The change must fit the rest of the topology. Adding more specific UDRs is not always the right long-term answer. In some designs, fixing theadvertised prefixes at the source is cleaner. Whatever you choose, investigate the selected route before touching firewall rules.
A stateful firewall tracks connections so each packet can be judged as part of an established session. If the forward and return packets reach different firewall instances that do not share session state, or the return packets skip the firewall entirely, the connection can fail or go partly uninspected. The two patterns differ only in the return leg:
Symmetric
Forward: App --> Firewall A -->Database
Return: App <-- Firewall A <-- Database
Asymmetric
Forward: App --> Firewall A -->Database
Return: App <-- Firewall B <-- Database
The asymmetric pattern shows up in multi-appliance designs when traffic distribution is not coordinated across both directions. Azure Standard Load Balancer offers high availability ports (HA ports) for NVA scenarios. An internal Standard Load Balancer with HA ports can spread flows across firewall instances and keep them symmetric in supported configurations. Microsoft's HA ports documentation is explicit about the boundary: symmetry is supported for a single internal load balancer with one backend pool and supported NIC configurations, and is not guaranteed across multiple load balancers, backend pools, or frontend IP configurations. A design with a public load balancer on one side of the NVA and an internal one on the other should not assume both will independently pick the same instance.
Azure Gateway Load Balancer is the alternative when you want transparent NVA insertion through service chaining. It suits some ingress and egress patterns better than a conventional internal load balancer, but depends on appliance support and deployment requirements, so check it against yourvendor's documentation before choosing it.
Translating the client's source address to the firewall's own address can pull replies back through the same appliance, which simplifies some routing problems. The costs are real: the destination no longer sees the original client IP unless you preserve it elsewhere, translated connections consume NAT resources, and high-volume traffic has to be checked for port exhaustion. Treat SNAT as a fix after you understand why the traffic is asymmetric, not as the default answer to it.
Virtual WAN provides managed, hub-based connectivity for virtual networks, branches, and hybrid links. Connections are associated with route tables and configured for route propagation, and BGP and supported static routes influence which prefixes are learned and distributed. Virtual WAN has its own route association, propagation, and routing preference mechanisms, so route selection should be validated against the specific hub configuration rather than assumed from a conventional VNet routing design.
Routing intent lets you send private and internet traffic to a supported security solution deployed in the virtual hub. The key word is supported. Microsoft's documentation lists specific in-hub firewall NVA types and SaaS integrations as valid routing-intent next hops (Palo Alto Networks Cloud NGFW is one of the SaaS-type entries at the time of writing), while a standalone firewall VM in a spoke VNet is a different deployment model with different routing mechanics. Routing intent also has restrictions around customVirtual WAN route tables and certain static routes.
A diagram showing traffic passing through a firewall is not evidence that Azure supports the next-hop configuration behind it. Before choosing an appliance and deployment model, check the current routing intent documentation, because support lists change as the service evolves. The same applies to BGP propagation: a route learned by one component is not automatically propagated to every connected network, so verify it at the connection and workload level.
Firewall administrators get privileged access because their changes can allow or block sensitive traffic. Anyone who can change a subnet's routing can do something just as consequential: add a route that sends traffic around the firewall, leaving the policy untouched and the logs quiet.
Microsoft calls out this risk in its Zero Trust guidance for Azure Virtual WAN, recommending that you restrict who can associate UDRs with spoke subnets so routing changes cannot bypass centralized inspection. The relevant permissionsinclude route-table association, such as Microsoft.Network/routeTables/join/action.My position: treat route-table write andassociation permissions like firewall admin rights. The same goes for changes to virtual network connectivity, route propagation, and the inspection components themselves. Limit these actions with Azure RBAC, log them, and review them, especially where centralized inspection is a requirement.
This is easy to overlook because route tables are usually owned by the networking team and look like plumbing, while change reviews concentrate on firewall rules. The permission to associate a route table rarelyappears on a firewall change ticket, yet it can decide whether that ticket's policy applies at all.
Even when traffic follows the intended path, the firewall has to be able to see inside it. NSGs filter at the network layer, and a central firewall may add application-aware controls and threat prevention. Private Link gives private connectivity to supported Azure services, but the path to a private endpoint must be evaluated on its own.
Without TLS decryption, a firewall generally cannot inspectthe payload of an encrypted session. Decryption improves visibility but brings certificate trust management, application compatibility problems, privacy and legal constraints, and performance overhead. Some categories of traffic need explicit exclusions. A sound design records which traffic is decrypted, which is exempt, and what compensating controls apply when payload inspection is not available.
I would not approve a centralized firewall design on the strength of configuration screenshots showing correct policies and route tables. The design should demonstrate that representative application flows cross the intended inspection points in both directions. These are the tools for that work:
For new flow-logging designs, use VNet flow logs. Microsoft has announced the retirement of NSG flow logs for September 30, 2027, and new NSG flow log creation is no longer supported.
Test permitted traffic, denied traffic, return-path behavior, and supported failover scenarios. Any route change that touches a security-sensitive path should trigger the same validation. The troubleshooting sequence stays short: identify source and destination, inspect effective routes, test the selected next hop, confirm connectivity, and correlate with firewall logs. If the selected route bypasses the firewall, editing a firewall rule will not fix it.
Centralized inspection in Azure works only when Azure actually forwards the traffic to the firewall and brings the replies back
through it. Make path verification a standing part of architecture reviews: pick a representative connection, trace the selected route in both directions, and confirm each expected control is on that path. That verification can identify an inspection gap before the architecture is placed into production.
Note: All IP addresses and scenarios are fictional illustrations based on public technical documentation.
For cloud network and security engineers designing centralized inspection in Azure.
A firewall rule can be correct, logging can be on, and the appliance can be healthy, yet traffic may still reach its destination without ever passing through the inspection point. In Azure, routing and policy enforcement are separate layers: user-defined routes (UDRs), BGP-learned routes, virtual network peering, and managed connectivity services decide where packets go, and none of them consult your firewall policy. A firewall cannot inspect traffic it never receives.
The example below is a lab-style scenario with fictional addresses, built from publicly documented Azure behavior. The later sections cover return paths, Virtual WAN, and who is allowed to change routes.
1. How Azure chooses a route
Azure picks a route for outbound subnet traffic by longest prefix match, so a more specific route beats a broader one even when the broader route is a UDR you wrote on purpose. Route source only matters as a tie-breaker.
Suppose an application subnet has these routes:
Source | Destination prefix | Next hop |
User-defined | 10.40.0.0/16 | Virtual appliance |
BGP | 10.40.2.0/24 | Virtual network gateway |
System | 0.0.0.0/0 | Internet |
For traffic to 10.40.2.15, Azure selects the /24 BGP route, because /24 is more specific than the /16. The UDR covers the address, but it loses the comparison.
When two routes have identical prefixes, Azure generally prefers a user-defined route, then a BGP route, then a system route. Prefix length is evaluated first and route source second, as described in Microsoft's virtual network traffic routing documentation.
Peering, gateways, and some service-specific features add routes of their own, and whether BGP routes reach a subnet depends on the BGP propagation setting on its route table. Azure also has exceptions for certain preferred system routes,particularly those tied to virtual networks, peering, and service endpoints, so analyze those separately when you read effective routes.
For a centralized firewall design, the UDR configuration alone tells you very little. The effective routes on the source workload are what Azure will actually use.
2. A hypothetical bypass: finding the route that wins
The lab has three segments. The application subnet 10.20.1.0/24 and the firewall subnet 10.10.1.0/24 sit in Azure. The database subnet 10.40.2.0/24 is on-premises, reached through a virtual network gateway over ExpressRoute or a site-to-site VPN. The firewall NVA's private IP is 10.10.1.10, and the database server is 10.40.2.15.
The intended design sends application-to-database traffic through the firewall in both directions:
Forward: App VM 10.20.1.20 --> Firewall NVA 10.10.1.10 --> Database 10.40.2.15
Return: Database 10.40.2.15 -->Firewall NVA 10.10.1.10 --> App VM 10.20.1.20
To make that happen, the application subnet gets a UDR for the on-premises summary 10.40.0.0/16 with the firewall as next hop. Meanwhile, the on-premises router advertises the specific prefix 10.40.2.0/24 over BGP, and the application subnet's route table allows gateway route propagation. The effective routes now look like this, with the gateway's next-hop IP left blank (illustrative values, not captured from a live environment)
Source | State | Address prefix | Next hop type | Next hop IP |
User | Active | 10.40.0.0/16 | Virtual appliance | 10.10.1.10 |
Virtual network gateway | Active | 10.40.2.0/24 | Virtual network gateway | — |
Default | Active | 0.0.0.0/0 | Internet |
"Active" means a route is available for selection.The most specific matching prefix still decides which one is used for a given destination, so traffic to 10.40.2.15 follows the BGP /24 into the gateway and never reaches the firewall. The firewall configuration remains unchanged, and its traffic logs may show no evidence of the connection because the packets never reached the appliance.
Step 1: check effective routes
In the Azure portal, open the VM's network interface and select Effective routes. The viewlists each route with its source, state, prefix, and next hop. The same data is available from the CLI:
az network nic show-effective-route-table \
--resource-group <resource-group>\
--name <nic-name> \
--output table
The command needs an existing VM NIC and permissions to read it. Look for any prefix more specific than your UDR that covers the destination.
Step 2: ask Network Watcher for the next hop
Effective routes show what is available. Network Watcher Next hop answers the narrower question of which next hop Azure will pick for a given source VM and destination IP. In the lab, the destination is 10.40.2.15, and the expected result is the virtual network gateway. If the design says the firewall, that single result exposes the mismatch.
Step 3: confirm connectivity and look at firewall logs
Network Watcher Connection troubleshoot shows whether a connection can be established and where it fails. Then check the firewall's traffic logs. If the application connection succeeds but the firewall recorded no session, investigate. A missing log entry alone does not prove a bypass, because logging configuration, session matching, and collection delay can also explain it, but it is the right prompt to look at routes.
Step 4: correct the route design
One fix is a UDR for 10.40.2.0/24 that points to the firewall. With identical prefixes, the user-defined route takes precedence over the BGP route:
Source | Prefix | Next hop |
User | 10.40.2.0/24 | Virtual appliance 10.10.1.10 |
BGP | 10.40.2.0/24 | Virtual network gateway |
Another option is to disable BGP route propagation on the application subnet's route table, which removes gateway-learned routes from that subnet entirely. That is a broader change and can break other on-premises connectivity, so test it before using it.
Either way, validate the result. The firewall needs a working onward route to the database. For an Azure NVA, IP forwarding must also be enabled on its network interface, and the appliance itself must be configured to forward the traffic. The on-premises return route must also direct traffic destined for the application subnet through the intended inspection path, using a supported routing design or an appropriate NAT strategy. The change must fit the rest of the topology. Adding more specific UDRs is not always the right long-term answer. In some designs, fixing theadvertised prefixes at the source is cleaner. Whatever you choose, investigate the selected route before touching firewall rules.
3. Stateful inspection needs a compatible return path
A stateful firewall tracks connections so each packet can be judged as part of an established session. If the forward and return packets reach different firewall instances that do not share session state, or the return packets skip the firewall entirely, the connection can fail or go partly uninspected. The two patterns differ only in the return leg:
Symmetric
Forward: App --> Firewall A -->Database
Return: App <-- Firewall A <-- Database
Asymmetric
Forward: App --> Firewall A -->Database
Return: App <-- Firewall B <-- Database
The asymmetric pattern shows up in multi-appliance designs when traffic distribution is not coordinated across both directions. Azure Standard Load Balancer offers high availability ports (HA ports) for NVA scenarios. An internal Standard Load Balancer with HA ports can spread flows across firewall instances and keep them symmetric in supported configurations. Microsoft's HA ports documentation is explicit about the boundary: symmetry is supported for a single internal load balancer with one backend pool and supported NIC configurations, and is not guaranteed across multiple load balancers, backend pools, or frontend IP configurations. A design with a public load balancer on one side of the NVA and an internal one on the other should not assume both will independently pick the same instance.
Azure Gateway Load Balancer is the alternative when you want transparent NVA insertion through service chaining. It suits some ingress and egress patterns better than a conventional internal load balancer, but depends on appliance support and deployment requirements, so check it against yourvendor's documentation before choosing it.
SNAT: use it only when routing requires it
Translating the client's source address to the firewall's own address can pull replies back through the same appliance, which simplifies some routing problems. The costs are real: the destination no longer sees the original client IP unless you preserve it elsewhere, translated connections consume NAT resources, and high-volume traffic has to be checked for port exhaustion. Treat SNAT as a fix after you understand why the traffic is asymmetric, not as the default answer to it.
4. Azure Virtual WAN changes the routing model
Virtual WAN provides managed, hub-based connectivity for virtual networks, branches, and hybrid links. Connections are associated with route tables and configured for route propagation, and BGP and supported static routes influence which prefixes are learned and distributed. Virtual WAN has its own route association, propagation, and routing preference mechanisms, so route selection should be validated against the specific hub configuration rather than assumed from a conventional VNet routing design.
Routing intent lets you send private and internet traffic to a supported security solution deployed in the virtual hub. The key word is supported. Microsoft's documentation lists specific in-hub firewall NVA types and SaaS integrations as valid routing-intent next hops (Palo Alto Networks Cloud NGFW is one of the SaaS-type entries at the time of writing), while a standalone firewall VM in a spoke VNet is a different deployment model with different routing mechanics. Routing intent also has restrictions around customVirtual WAN route tables and certain static routes.
A diagram showing traffic passing through a firewall is not evidence that Azure supports the next-hop configuration behind it. Before choosing an appliance and deployment model, check the current routing intent documentation, because support lists change as the service evolves. The same applies to BGP propagation: a route learned by one component is not automatically propagated to every connected network, so verify it at the connection and workload level.
5. Routing permissions are security permissions
Firewall administrators get privileged access because their changes can allow or block sensitive traffic. Anyone who can change a subnet's routing can do something just as consequential: add a route that sends traffic around the firewall, leaving the policy untouched and the logs quiet.
Microsoft calls out this risk in its Zero Trust guidance for Azure Virtual WAN, recommending that you restrict who can associate UDRs with spoke subnets so routing changes cannot bypass centralized inspection. The relevant permissionsinclude route-table association, such as Microsoft.Network/routeTables/join/action.My position: treat route-table write andassociation permissions like firewall admin rights. The same goes for changes to virtual network connectivity, route propagation, and the inspection components themselves. Limit these actions with Azure RBAC, log them, and review them, especially where centralized inspection is a requirement.
This is easy to overlook because route tables are usually owned by the networking team and look like plumbing, while change reviews concentrate on firewall rules. The permission to associate a route table rarelyappears on a firewall change ticket, yet it can decide whether that ticket's policy applies at all.
Correctly routed traffic may still be uninspectable
Even when traffic follows the intended path, the firewall has to be able to see inside it. NSGs filter at the network layer, and a central firewall may add application-aware controls and threat prevention. Private Link gives private connectivity to supported Azure services, but the path to a private endpoint must be evaluated on its own.
Without TLS decryption, a firewall generally cannot inspectthe payload of an encrypted session. Decryption improves visibility but brings certificate trust management, application compatibility problems, privacy and legal constraints, and performance overhead. Some categories of traffic need explicit exclusions. A sound design records which traffic is decrypted, which is exempt, and what compensating controls apply when payload inspection is not available.
6. Validate the path before approving the architecture
I would not approve a centralized firewall design on the strength of configuration screenshots showing correct policies and route tables. The design should demonstrate that representative application flows cross the intended inspection points in both directions. These are the tools for that work:
Tool | What it tells you |
NIC Effective routes | Which routes are available to a workload, and their next-hop types |
Network Watcher Next hop | The next hop Azure selects for a specific source and destination |
Connection troubleshoot | Whether endpoints can connect, with diagnostics on failures |
Virtual Network flow logs | Network flow records for supported VNet traffic |
Firewall traffic logs | Session matches, policy actions, and inspection visibility |
Azure Activity Log | Administrative changes to routes and other Azure resources |
For new flow-logging designs, use VNet flow logs. Microsoft has announced the retirement of NSG flow logs for September 30, 2027, and new NSG flow log creation is no longer supported.
Test permitted traffic, denied traffic, return-path behavior, and supported failover scenarios. Any route change that touches a security-sensitive path should trigger the same validation. The troubleshooting sequence stays short: identify source and destination, inspect effective routes, test the selected next hop, confirm connectivity, and correlate with firewall logs. If the selected route bypasses the firewall, editing a firewall rule will not fix it.
Conclusion
Centralized inspection in Azure works only when Azure actually forwards the traffic to the firewall and brings the replies back
through it. Make path verification a standing part of architecture reviews: pick a representative connection, trace the selected route in both directions, and confirm each expected control is on that path. That verification can identify an inspection gap before the architecture is placed into production.
Note: All IP addresses and scenarios are fictional illustrations based on public technical documentation.