On-prem to spoke via Azure Firewall (hybrid hub-and-spoke) facing Asymmetric routing issue

HI @Allan Solomon Mejia

Have verified all above points and all as per expectation.

To further troubleshoot this issue I checked flow logs in Azure Firewall and noticed theat I have inbound and outbound both the traffic, mean reaturn traffic is reaching to firewall but looking like firewall not sending it back to Gateway or Gateway is not sending back to source. Please note i have no UDR attached to firewall as per documentataion.

Just to validate route from destination to source i did RDP from Destination VM to Source VM which was successful but not able to RDP from Source VM to Destination VM(Actual issue). Just for testing i did NSG on both as any any so no NSG issue.

Hi @Sandeep Darak

Your UDR layout matches Microsoft’s documented hybrid Azure Firewall design:

• GatewaySubnet: 10.6.0.0/16 → Azure Firewall private IP.
• Spoke workload subnet: 0.0.0.0/0 → Azure Firewall private IP, with gateway-route propagation disabled.
• No route table on AzureFirewallSubnet.

This routing pattern is for forcing traffic between an on-premises network and a spoke through Azure Firewall.

Global peering also isn’t inherently the problem. Both regional and global virtual-network peering support gateway transit.

With the configured routes, the intended flow is:

1. On-premises → hub VPN gateway.
2. The GatewaySubnet UDR sends 10.6.0.0/16 traffic to Azure Firewall.
3. Azure Firewall forwards the permitted traffic to the spoke.
4. The spoke’s default route sends the response back through Azure Firewall.
5. Azure Firewall routes the response toward the VPN gateway and on-premises network.

Therefore, the current information doesn’t confirm asymmetric routing. Removing both UDRs only proves that the direct gateway-to-spoke route works; it doesn’t identify where the firewall path is failing.

Check the following:

1. On the spoke VM’s NIC, review Effective routes. Confirm that the effective route for 192.168.0.0/16 uses Virtual appliance with 10.5.0.4 as the next hop. Microsoft documents that effective routes combine system, UDR, and gateway-propagated routes.
2. Verify that the firewall has a valid route toward 192.168.0.0/16 through the hub VPN gateway. No UDR should normally be required on AzureFirewallSubnet; the hybrid-network explicitly states that the firewall subnet learns the gateway routes.
3. Review Azure Firewall network-rule logs for the specific source address, destination address, and TCP ports 443 and 3389. This confirms whether the connection reaches the firewall and whether a rule permits or denies it.
4. Run Azure Network Watcher Connection troubleshoot for TCP 443 and 3389. It can identify failures caused by a user-defined route, NSG, guest firewall, or unreachable destination.
5. Confirm that the destination VM is listening on the tested port and that its operating-system firewall permits traffic from 192.168.0.0/16. ICMP success doesn’t prove that TCP 443 or 3389 is accepted by the application or guest firewall.

The effective-route output, Azure Firewall log entry, and Connection Troubleshoot result are needed to identify the exact failing hop. Based on the configuration shown, changing the global peering or removing the documented UDRs isn’t yet justified.

References:

Deploy and configure Azure Firewall in a hybrid network

Azure Virtual Network peering overview

Diagnose an Azure virtual machine routing problem

Azure Network Watcher Connection Troubleshoot overview

Monitor Azure Firewall logs and metrics

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.