Azure Virtual Wan - secured hub

Peter Stieber 70 Reputation points
2026-05-20T17:57:45.3133333+00:00

I found this guide which is explaining vwan traffic flow patterns - https://techcommunity.microsoft.com/blog/azurenetworkingblog/virtual-wan-traffic-flow-patterns/4102655User's image

How would the traffic flow change with a secured hub and Azure Firewall in place? Would the routing instances be in the path for traffic coming from on-premises to one of the spokes?

Azure Virtual WAN
Azure Virtual WAN

An Azure virtual networking service that provides optimized and automated branch-to-branch connectivity.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-05-20T17:58:06.0466667+00:00

    With a secured virtual hub, Azure Firewall (or another security solution) becomes the next hop for traffic according to the routing intent and policies configured on the hub. The routing instances in the hub are still in the data path, but they forward traffic to the firewall instead of directly to the destination.

    Key changes compared to an unsecured hub:

    1. Internet-bound traffic
      • When an Internet Traffic Routing Policy is configured on the hub, the hub advertises a 0.0.0.0/0 route to all VNets and branch connections.
      • All Internet-bound traffic from spokes and branches is sent to the Azure Firewall (or other configured security solution) in the secured hub.
      • The firewall inspects the traffic and then forwards it directly to the Internet (direct access pattern).
    2. Private traffic (VNet/branch to VNet/branch)
      • When a Private Traffic Routing Policy is configured, all private traffic in and out of the hub (branch‑to‑branch, branch‑to‑VNet, VNet‑to‑branch, and inter‑hub) is forwarded to the Azure Firewall or NVA in the hub.
      • The routing instances still perform routing, but the effective next hop for these flows is the firewall. After inspection, the firewall forwards traffic to the appropriate destination (another VNet, another hub, or on‑premises).
    3. Spoke‑to‑spoke and branch flows
      • In a non‑secured hub, spoke‑to‑spoke or branch‑to‑spoke traffic can be routed directly by the hub’s routing fabric.
      • In a secured virtual hub with private routing policy, these same flows are hairpinned through Azure Firewall in the hub, which applies security policy before traffic reaches the other spoke/branch.
    4. Selective or bypass scenarios
      • In designs that use static routes (without routing intent) to send traffic to Azure Firewall, it is possible to configure certain flows to bypass the firewall and route directly through the hub.
      • When routing intent is used, custom bypass scenarios are not supported; all traffic covered by the routing policy must traverse the configured next hop.

    So, with a secured hub, the routing instances remain in the path but act primarily to steer traffic to Azure Firewall (or another security solution) for inspection, rather than routing traffic directly between spokes, branches, and the Internet.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator
    2026-05-23T00:54:44.44+00:00

    Hi Peter Stieber,

    Welcome to Microsoft Q&A Platform.

    When you switch your hub to a secured virtual hub with Azure Firewall, the traffic flows change as follows:

    On-premises → Spoke

    • Your on-prem site sends traffic over the VPN or ExpressRoute gateway into the VWAN hub.
    • By using Firewall Manager in the Azure portal, you can create a new secured virtual hub or convert an existing virtual hub that you previously created by using Azure Virtual WAN.
    • The hub’s built-in router (the “routing instance”) receives the traffic and because you’ve enabled a secured hub automatically steers it through the Azure Firewall (bump-in-the-wire).
    • After inspection, the firewall hands the packets back to the hub router, which then forwards them to the target spoke.c

    Key points

    • You don’t need to create UDRs to force traffic through the firewall; routing is fully automated in a secured hub.
    • Hub route tables and the Microsoft-managed routing instance are still in the data path, but they now point your traffic at the firewall as the next hop.
    • To have on-prem----spoke (and spoke----spoke or spoke---on-prem) traffic inspected, you’ll use a Private routing intent policy. Without that routing intent, branch-to-VNet and VNet-to-VNet flows would bypass the firewall.
    • So yes---the VWAN routing instance is still in the path for on-premises-to-spoke traffic, but it simply inserts Azure Firewall as the inspection hop.

    If the above solution did not help to answer your query, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

    Reference:

    Configure Azure Firewall in a Virtual WAN hub https://docs.microsoft.com/azure/virtual-wan/howto-firewallAbout secured virtual hubs https://docs.microsoft.com/azure/firewall-manager/secured-virtual-hub

    About virtual hub routing & route tables https://docs.microsoft.com/azure/virtual-wan/about-virtual-hub-routing

    Routing traffic through an NVA in the hub https://docs.microsoft.com/azure/virtual-wan/scenario-route-through-nva

    If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

    Please210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.