vWAN hub routing

Question

vWAN hub routing

AzurePro 80

I have two vWAN hub.

on prem >>> to vWANHUB (SDWAN) >>vWANHUB(PA FW)

I'm able to see on prem routes are being received into SDWANHUB in effective routes but not in PA HUB.

Questions:

hub for PA FW is not receiving any traffic from SDWAN hub. what actions i need to make here?
Azure workload vnets should i connect to PA FW hub or directly into SDWAN hub?

0 comments

3 answers

Your answer

Answer 1

AzurePro 80

Hi,

I followed steps in and how to fix it - Still i cant see any routes in PA hub under effective routes.

AzurePro 80 Reputation points

2026-03-26T03:35:57.71+00:00

it worked. thank you so much. i conencted vnet to pa hub instead of sdwan hub

Answer 2

Hello @ AzurePro,

Thank you for reaching Microsoft Q&A.

Thanks for reaching out with the details on your vWAN setup—two hubs (SDWAN and PA FW) in the same Virtual WAN, with on-premises routes showing up fine in the SDWAN hub but not propagating visibly to the PA hub. This is a common question with secured hubs, and the good news is it's usually just a quick config tweak away from working perfectly.

1. Why the PA FW hub isn't receiving traffic from the SDWAN hub (and how to fix it):
Your on-prem routes are being learned across the hubs automatically (via the Microsoft backbone full-mesh), but when Routing Intent is enabled on the PA hub, the specific prefixes get pushed to the Cloud NGFW next-hop instead of showing in the default route table view. To make everything flow and get inspected:

In the PA FW hub → Routing intent and policies, turn on Private traffic and select your Palo Alto Cloud NGFW as the next-hop resource.
(Optional but recommended) Do the same for Internet traffic if you want that inspected too.
Add any non-RFC 1918 on-prem prefixes under Private traffic prefixes if needed.
Then check Effective routes in the PA hub: switch the dropdown to your Cloud NGFW resource—you should see the on-prem routes there now (give it 5–10 mins for propagation).

Once that's done, traffic from the SDWAN hub will hairpin through the PA NGFW as expected. No extra peering or Global Reach required.

2. Where to connect your Azure workload VNets:
Connect them directly to the PA FW hub. That way all North-South (on-prem ↔ Azure) and East-West traffic gets inspected automatically by the Cloud NGFW. Connecting to the SDWAN hub works for basic connectivity but would bypass your firewall inspection, which defeats the purpose of the secured hub.

Here are the official Microsoft docs:

Kindly let us know if the above helps or you need further assistance on this issue.

Please "Accept the Answer" and "Upvote". If the information helped you. This will help us and others in the community as well.

Answer 3

For the PA Firewall hub to receive and forward routes and traffic from the SD-WAN hub in Virtual WAN, verify and adjust the Virtual WAN routing configuration between hubs and connections.

PA Firewall hub not receiving routes/traffic from SDWAN hub

Check these areas in order:

Inter-hub route propagation and routing intent

Ensure both hubs are part of the same Virtual WAN and that inter-hub connectivity is enabled so that routes selected in one hub are advertised to the other hub.
If the PA hub is a secured hub (Azure Firewall or NVA with routing intent), verify that:
- The SDWAN hub connections (VPN/SD-WAN NVA/ExpressRoute) are propagating to the defaultRouteTable of the PA hub, and
- The PA hub’s routing intent/private routing policies are configured so that private traffic from other hubs is sent to the PA firewall.
If there is a non-secured hub and a secured hub in the same Virtual WAN, confirm that connections to the non-secured hub are propagating to the defaultRouteTable of the secured hub. Otherwise, the secured hub cannot send packets to prefixes learned via the non-secured hub.
- This is explicitly called out: if a non-secured hub exists, connections to it must propagate to the defaultRouteTable of hubs with routing intent configured, or traffic will not flow between them.

Effective routes on the PA Firewall / NVA

After confirming the defaultRouteTable has the correct prefixes from the SDWAN hub, check the Effective Routes on the PA Firewall (or its NVA NIC) in the PA hub:
- Effective routes on the firewall show which routes Virtual WAN has actually selected and which destinations the firewall can forward to.
- If the on-prem prefixes from the SDWAN hub are missing here, adjust propagations so those routes are present in the PA hub’s defaultRouteTable and then re-check effective routes.

Routing preference and path selection

Virtual WAN uses a route selection algorithm across ExpressRoute, S2S VPN, and SD-WAN NVA connections. When multiple hubs exist, each hub selects best routes and then advertises them to other hubs.
If ExpressRoute and SD-WAN/VPN advertise the same prefixes, ensure the desired path is preferred:
- If ExpressRoute is preferred but goes down, S2S/SD-WAN routes may become preferred and stay preferred even after ExpressRoute recovers.
- To avoid unexpected path selection, configure AS-Path prepending on on-prem devices so that VPN/SD-WAN routes have a longer AS-Path than ExpressRoute routes, ensuring consistent preference.
If some hubs have routing intent private routing policies and others do not, routes from hubs with routing intent are always preferred over ExpressRoute routes from hubs without routing intent. To avoid asymmetric routing, enable routing intent on all hubs in the Virtual WAN.

Troubleshooting datapath

Use the recommended sequence:
- Verify the defaultRouteTable effective routes in both hubs contain the on-prem prefixes.
- Then verify the effective routes on the PA Firewall NVA NIC.
- Identify any missing or incorrect prefixes and adjust the relevant VPN/ExpressRoute/SD-WAN/BGP connection or propagation accordingly.

Where to connect Azure workload VNets: PA FW hub vs SDWAN hub

The choice depends on whether the PA hub is the security hub (secured hub) and how routing intent is configured:

If the PA hub is the security hub (with routing intent/private and/or internet policies):
- Connect workload VNets to the PA Firewall hub so that:
  - Their prefixes propagate into the hub’s defaultRouteTable.
  - Private routing policies can send their traffic through the PA firewall for inspection.
- Ensure on-prem routes from the SDWAN hub are visible in the PA hub’s defaultRouteTable and in the firewall’s effective routes so that traffic between workloads and on-prem is symmetric and inspected.
If the SDWAN hub is primarily for connectivity and the PA hub is not acting as the central security hub:
- Workload VNets can connect to the SDWAN hub, and traffic to on-prem will follow the SD-WAN/ER/VPN paths according to routing preference.
- In this case, if inspection by PA is still required, design must ensure traffic is steered through the PA hub (for example, via routing intent and appropriate associations/propagations), but that pattern is typically implemented by making the PA hub the secured hub.

In most Virtual WAN security designs with a central firewall (Azure Firewall or NVA such as PA), workload VNets are connected to the secured hub (PA hub), and other hubs (such as SDWAN hub) act as connectivity hubs whose routes are propagated into the secured hub. This aligns with routing intent guidance and simplifies symmetric routing and inspection.

References: