Introduction
If you’ve ever tried to configure Azure Firewall or third-party Network Virtual Appliance (NVA) like Palo Alto VM-Series in an Azure Virtual WAN (vWAN) topology, you’ll know the documentation can be confusing, contradictory, and spread across dozens of pages and videos with snips of information. After weeks of hands-on lab testing and production deployments, I’ve compiled this guide to give you the definitive answer to one question:
What routing and security combinations actually work in Azure vWAN — and which ones don’t?
This post covers six common design scenarios, explains exactly why each one does or doesn’t work, and finishes with a master comparison table so you can make an informed architectural decision.
Key Concepts You Need to Understand First
Before diving into the scenarios, let’s establish some fundamentals.
What Is Routing Intent?
Routing Intent is a declarative feature in Azure vWAN that allows you to configure Internet Traffic and Private Traffic routing policies on a virtual hub. When enabled, it automatically:
- Takes over management of the
defaultRouteTableand all connection associations/propagations - Injects RFC1918 aggregate routes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for private traffic
- Injects a 0.0.0.0/0 default route for internet traffic
- Forces all connections to associate with and propagate to the
defaultRouteTable
You lose the ability to use custom route tables or manually control association/propagation. The platform manages everything.
What Is a Secured Virtual Hub?
A secured virtual hub is a vWAN hub with a security solution deployed inside it. Valid security solutions are:
- Azure Firewall (deployed in the hub)
- Integrated NVA partner (e.g., Fortinet, Barracuda — deployed in the hub via Firewall Manager)
- Palo Alto Cloud NGFW (SaaS resource deployed in the hub)
A Palo Alto VM-Series deployed as IaaS in a spoke VNet is NOT a hub-integrated security solution and cannot be used as a Routing Intent next hop.
Direct Spokes vs Indirect Spokes
- Direct spoke: A VNet connected directly to the vHub via a hub virtual network connection
- Indirect spoke: A VNet peered to another spoke (typically an NVA transit VNet) that is connected to the vHub. The indirect spoke has no direct connection to the hub.
The Golden Rule of vWAN Static Routes
There are two mutually exclusive ways to steer traffic to Azure Firewall in a vHub:
- Routing Intent (declarative, platform-managed)
- Static routes in hub route tables (manual, operator-managed)
You cannot mix these two approaches. Enabling Routing Intent on a hub that has manually configured static routes will cause conflicts, and the platform will not reconcile them automatically.
Scenario 1: Full Routing Intent (Both Policies)
The Design
Azure Firewall deployed in a secured vHub with Routing Intent enabled for both Internet and Private traffic. All spokes connected directly to the hub. No third-party NVA.
Spoke 4 Spoke 5
(direct conn) (direct conn)
\ /
\ /
┌──────────────────────────┐
│ Secured vHub │
│ Azure Firewall │
│ Routing Intent: │
│ Internet → AzFW │
│ Private → AzFW │
└──────────────────────────┘
│
ExpressRoute / VPN
│
On-Premises
Traffic Flows
| Source → Destination | Path | Inspected? |
|---|---|---|
| Spoke ↔ Spoke | Via Azure Firewall | ✅ Azure Firewall |
| Spoke ↔ Branch | Via Azure Firewall | ✅ Azure Firewall |
| Spoke → Internet | Via Azure Firewall | ✅ Azure Firewall |
| Branch → Internet | Via Azure Firewall | ✅ Azure Firewall |
| Inter-hub (if multi-hub) | Via Azure Firewall (both hubs) | ✅ Azure Firewall |
Configuration
Routing Intent:
| Policy | Destination | Next Hop |
|---|---|---|
| InternetTraffic | Internet | Azure Firewall |
| PrivateTraffic | PrivateTraffic | Azure Firewall |
VNet Connections (managed by platform):
| Setting | Value |
|---|---|
| Associated route table | defaultRouteTable (auto) |
| Propagated route tables | defaultRouteTable + noneRouteTable (auto) |
enableInternetSecurity | true (auto) |
Prerequisites
- Only
defaultRouteTableandnoneRouteTablecan exist — delete all custom route tables - No static routes with next hop type = VNet connection
- Azure Firewall must be deployed in the hub (not in a spoke VNet)
- If non-RFC1918 private address space is used, add it as “Private Traffic Prefixes”
Critical Lesson Learnt
If the hub previously had static routes, custom next hops, or custom route tables before Routing Intent was enabled, simply deleting those routes while intent is active is not sufficient. The correct procedure is:
- Fully remove Routing Intent
- Delete all static routes, custom next hops, and custom route tables
- Verify only
defaultRouteTableandnoneRouteTableremain - Re-enable Routing Intent
This forces the platform to rebuild the routing state from scratch.
Verdict: ✅ Fully Supported
Scenario 2: PA Cloud NGFW (Internet) + Azure Firewall (Private) with Routing Intent
The Design
Split the security duties using Routing Intent with two different in-hub security solutions: Palo Alto Cloud NGFW (a SaaS offering deployed inside the vHub) for internet traffic, and Azure Firewall for private/east-west traffic.
Spoke 4 Spoke 5
(direct conn) (direct conn)
\ /
\ /
┌──────────────────────────┐
│ Secured vHub │
│ │
│ Azure Firewall │
│ (private traffic) │
│ │
│ PA Cloud NGFW (SaaS) │
│ (internet traffic) │
│ │
│ Routing Intent: │
│ Internet → PA NGFW │
│ Private → AzFW │
└──────────────────────────┘
Traffic Flows
| Source → Destination | Path | Inspected by |
|---|---|---|
| Spoke ↔ Spoke | Via Azure Firewall | ✅ Azure Firewall |
| Spoke ↔ Branch | Via Azure Firewall | ✅ Azure Firewall |
| Spoke → Internet | Via PA Cloud NGFW | ✅ Palo Alto |
| Branch → Internet | Via PA Cloud NGFW | ✅ Palo Alto |
Why This Works
PA Cloud NGFW is a SaaS resource deployed inside the vHub — it’s a first-class Routing Intent next hop, just like Azure Firewall. You can point each routing policy at a different in-hub resource.
Trade-offs
- ✅ Cleanest split architecture — fully declarative, single-hop
- ✅ Fully supported by Microsoft and Palo Alto
- ✅ PA Cloud NGFW integrates with Panorama / Strata Cloud Manager
- ❌ Requires PA Cloud NGFW licensing (consumption-based SaaS) — not existing VM-Series licensing
- ❌ Feature set differ from VM-Series
Verdict: ✅ Fully Supported
Scenario 3: Routing Intent with Private-Only Policy + PA VM-Series (Spoke) for Internet
The Design
Enable Routing Intent for only Private Traffic (pointing at Azure Firewall), then use a static route on the PA transit VNet connection to steer internet traffic (0.0.0.0/0) to the Palo Alto VM-Series in a spoke VNet.
Spoke 4 Spoke 5 PA Transit VNet
(direct conn) (direct conn) (direct conn +
\ / static 0/0 → PA)
\ / │
┌──────────────────────────┐ │
│ Secured vHub │─────────────┘
│ Azure Firewall │
│ Routing Intent: │
│ Private → AzFW │
│ Internet → ??? │
└──────────────────────────┘
Why This DOESN’T Work
When Routing Intent is enabled — even with only the Private Traffic policy — the platform takes over management of the defaultRouteTable and all connection associations/propagations. You cannot layer a static route (0.0.0.0/0 → PA ILB) on a VNet connection on top of an active Routing Intent configuration.
The static route pattern documented by Microsoft for Routing Intent is specifically for reaching indirect spokes behind an NVA — not for routing internet traffic to an NVA in a spoke bypassing the hub security solution.
Routing Intent next hops must be a resource deployed in or integrated with the vHub:
| Valid Next Hop | Type |
|---|---|
| ✅ Azure Firewall | Deployed in hub |
| ✅ Integrated NVA partner | Deployed in hub |
| ✅ PA Cloud NGFW | SaaS in hub |
| ❌ PA VM-Series in a spoke VNet | Not valid |
Verdict: ❌ Not Supported — Tested and Confirmed
Scenario 4: Service Chaining Azure Firewall (Hub) → PA VM-Series (Spoke) for Internet
The Design
Use Routing Intent for both policies pointing at Azure Firewall, then have Azure Firewall “forward” internet-bound traffic to the PA VM-Series in a spoke VNet for deep inspection before egress.
Spoke 4
(direct conn)
│
▼
Azure Firewall (hub)
│
▼ ← "forward internet to PA"
PA Transit VNet (spoke)
│
▼
Internet
Why This DOESN’T Work
There is no mechanism to get traffic from Azure Firewall inside the hub to an NVA in a spoke:
| What you’d need | Why it’s impossible |
|---|---|
| UDR on Azure Firewall’s subnet | It’s managed infrastructure — no subnet access |
| VNet peering into the firewall | Hub infrastructure isn’t peerable |
| Azure FW “forward to next hop” rule | Azure FW rules allow/deny/DNAT — no “forward to NVA” action |
| BGP from PA in spoke to vHub router | PA VM-Series IaaS can’t BGP peer with the vHub router |
Azure Firewall in a vHub is a walled garden. There is no data-plane path from Azure Firewall to say “after inspection, send this to the PA ILB in a spoke VNet.”
Microsoft does document a “Forced Tunnel” mode, but the valid sources of a 0.0.0.0/0 for forced tunnel are limited to: on-premises (via BGP), an NVA deployed in the hub, or a SaaS solution in the hub — not an NVA in a spoke VNet.
Verdict: ❌ Not Supported — No Mechanism Exists
Scenario 5: Static Routes Only — PA VM-Series (Internet), east\west not supported
The Design
Manually configure static routes in the defaultRouteTable to steer 0.0.0.0/0 to the PA VM-Series transit VNet connection for internet access. RFC1918 traffic to PA VM-Series NOT supported
┌──────────────────────────────┐
│ vHub (Secured - NO Routing │
│ Intent enabled) │
│ Azure Firewall deployed │
│ │
│ defaultRouteTable: │
│ ┌──────────────────────────┐ │
│ │ 10.0.0.0/8 → NA │ │
│ │ 172.16.0.0/12 → NA │ │
│ │ 192.168.0.0/16→ NA │ │
│ │ 0.0.0.0/0 → PA conn │ │
│ └──────────────────────────┘ │
└──┬────────┬────────┬──────────┘
│ │ │
Spoke 4 Spoke 5 PA Transit VNet
Traffic Flows
| Source → Destination | Path | Inspected by |
|---|---|---|
| Spoke ↔ Spoke | Via Azure Firewall | ✅ Palo Alto |
| Spoke ↔ Branch | Via Azure Firewall | ✅ Palo Alto |
| Spoke → Internet | Via PA transit VNet → PA | ✅ Palo Alto |
| Branch → Internet | Via PA transit VNet → PA | ✅ Palo Alto |
| Inter-hub | ❌ Not inspected | Direct via vWAN backbone |
| Branch ↔ Branch | ❌ Not inspected | Direct via vHub |
Configuration
defaultRouteTable Static Routes:
| Route Name | Destination Prefix | Next Hop Type | Next Hop |
|---|---|---|---|
private_traffic | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | Azure Firewall | Azure Firewall resource ID |
internet_traffic | 0.0.0.0/0 | Virtual Network Connection | PA transit VNet connection |
Spoke VNet Connections (Spoke 4, Spoke 5, etc.):
| Setting | Value |
|---|---|
| Associated route table | defaultRouteTable |
| Propagated route tables | noneRouteTable |
| Propagated labels | none |
| Static routes | None |
enableInternetSecurity | true |
Critical: Spokes must propagate to
noneRouteTable, notdefaultRouteTable. If spokes propagated their specific prefixes (e.g., 10.20.20.0/24), these would be more specific than the RFC1918 aggregates (10.0.0.0/8) and traffic would bypass Azure Firewall via longest-prefix match.
PA Transit VNet Connection:
| Setting | Value |
|---|---|
| Associated route table | defaultRouteTable |
| Propagated route tables | noneRouteTable |
| Static route | 0.0.0.0/0 → PA ILB VIP |
enableInternetSecurity | false ⚠️ |
Critical: If
enableInternetSecurityistrueon the PA connection, the 0.0.0.0/0 route gets advertised back to the PA VNet, creating a routing loop. The PA must use its own external interface for internet egress.
Limitations
- Inter-hub traffic is not inspected — traffic between hubs bypasses Palo Alto (inter-hub inspection requires Routing Intent)
- Branch-to-branch traffic is not inspected — ExpressRoute ↔ VPN bypasses not inspected
- Cannot enable Routing Intent — the two approaches are mutually exclusive
- Manual route management — static routes must be maintained across all hubs
Verdict: ✅ Fully Supported for Internet Access only
Scenario 6: Transit NVA vNet – PA VM-Series for Everything — Indirect Spoke Pattern (No Azure Firewall)
The Design
No Azure Firewall, no Routing Intent. Standard vHub with all spokes peered to a regional PA transit VNet. The PA handles all inspection — internet and east-west. UDRs on every spoke subnet point 0.0.0.0/0 at the PA internal load balancer VIP.
Spoke 4 Spoke 5
(VNet peer) (VNet peer)
\ /
\ /
PA Transit VNet (NVA)
(PA VM-Series Active/Active
behind Standard ILB)
│
Hub VNet Connection
(static routes for spoke
prefixes → PA ILB VIP)
│
┌──────────────────────┐
│ vHub (Standard) │
│ No Azure Firewall │
│ No Routing Intent │
└──────────────────────┘
│
ExpressRoute / VPN
│
On-Premises
Traffic Flows
| Source → Destination | Path | Inspected by |
|---|---|---|
| Spoke ↔ Spoke | Via PA (UDR → PA ILB) | ✅ Palo Alto |
| Spoke ↔ Branch | Via PA → vHub → Branch | ✅ Palo Alto |
| Spoke → Internet | Via PA (SNAT) → Internet | ✅ Palo Alto |
| Branch → Spoke | Via vHub → PA transit → PA → Spoke | ✅ Palo Alto |
| Inter-hub (remote spokes) | Via vHub → remote hub → PA → Spoke | ✅ Palo Alto (at source) |
Configuration
Spoke Subnets — UDR:
| Route | Next Hop | Gateway Route Propagation |
|---|---|---|
0.0.0.0/0 | PA internal LB VIP | Disabled |
UDRs must be applied to every subnet in every spoke VNet.
PA Transit VNet Connection to vHub:
| Setting | Value |
|---|---|
| Associated route table | defaultRouteTable |
| Propagated route tables | defaultRouteTable (label: default) |
| Static route | Spoke summary prefix → PA ILB VIP |
enableInternetSecurity | false |
defaultRouteTable:
| Route | Destination | Next Hop |
|---|---|---|
| Regional spoke summary | e.g., 10.20.0.0/16 | PA transit VNet connection |
Advantages
- ✅ Single inspection point — PA handles everything
- ✅ Uses existing PA VM-Series licensing and Panorama
- ✅ No Azure Firewall cost
- ✅ Full PA feature set (App-ID, Threat Prevention, URL Filtering, SSL Decryption, WildFire)
- ✅ Proven pattern for enterprises with existing Palo Alto investment
Limitations
- ❌ More complex operational management (UDRs on every subnet, static routes per spoke)
- ❌ No Routing Intent simplicity
- ❌ Spoke onboarding requires UDR creation and VNet peering
- ❌ PA becomes a single point of inspection (capacity planning critical)
Verdict: ✅ Fully Supported — Production Proven
Master Comparison Table
| Scenario 1 | Scenario 2 | Scenario 3 | Scenario 4 | Scenario 5 | Scenario 6 | |
|---|---|---|---|---|---|---|
| Name | Full Routing Intent | Cloud NGFW + AzFW Routing Intent | Private Intent + PA Spoke | Service Chain AzFW → PA | Static Routes | Transit NVA Network |
| Supported? | ✅ Yes | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ✅ Yes |
| Routing Intent | Both policies | Both policies | Partial | Both policies | None | None |
| Internet inspection | Azure Firewall | PA Cloud NGFW | — | — | Palo Alto VM-Series | Palo Alto VM-Series |
| East-west inspection | Azure Firewall | Azure Firewall | — | — | ❌ No, Direct vHub | Palo Alto VM-Series |
| Inter-hub inspection | ✅ Yes | ✅ Yes | — | — | ❌ No | ✅ Via PA at source |
| Branch-to-branch inspection | ✅ Yes | ✅ Yes | — | — | ❌ No | ✅ Via PA |
| Uses PA VM-Series IaaS | ❌ | ❌ | — | — | ✅ | ✅ |
| Uses PA Cloud NGFW | ❌ | ✅ | — | — | ❌ | ❌ |
| Uses Azure Firewall | ✅ | ✅ | — | — | yes, instead of Palo Alto | ❌ |
| Custom route tables | ❌ Not allowed | ❌ Not allowed | — | — | ✅ Supported | ✅ Supported |
| UDRs on spoke subnets | Not required | Not required | — | — | Not required | Required (every subnet) |
| Operational complexity | Low | Low | — | — | Medium | Medium-High |
| Routing management | Platform-managed | Platform-managed | — | — | Manual static routes or BGP | Manual UDRs + static routes or BGP |
| Spoke onboarding effort | Low (connect to hub) | Low (connect to hub) | — | — | Low (connect to hub) | High (peer + UDR per subnet) |
| Azure Firewall cost | ✅ Yes | ✅ Yes | — | — | ❌ None | ❌ None |
| PA licensing model | N/A | Cloud NGFW SaaS | — | — | VM-Series IaaS | VM-Series IaaS |
Decision Flowchart
Do you need a third-party NVA (e.g., Palo Alto) for ANY traffic?
│
├─ NO → Scenario 1 (Azure Firewall + Full Routing Intent)
│
└─ YES → Is it PA Cloud NGFW (SaaS) or PA VM-Series (IaaS)?
│
├─ Cloud NGFW → Scenario 2 (Cloud NGFW Internet + AzFW Private)
│
└─ VM-Series IaaS → Do you need Azure Firewall for east-west?
│
├─ YES → Scenario 5 (Static Routes Split)
│ ⚠️ No inter-hub or branch-to-branch inspection, traffic is direct via vWAN\vHubs
│
└─ NO → Scenario 6 (Transit NVA vNet)
✅ Full inspection coverage
Conclusion
The Azure vWAN routing landscape is powerful but opinionated. The platform gives you clean, declarative routing through Routing Intent — but only if your security solutions are deployed inside the hub. The moment you introduce an IaaS NVA in a spoke VNet, you’re working outside the Routing Intent model and must use manual static routes and UDRs.
The two approaches — Routing Intent and static routes — are mutually exclusive. Understanding this single constraint will save you hours of troubleshooting.
Key takeaways:
- Routing Intent next hops must be in-hub resources — Azure Firewall, integrated NVA, or Cloud NGFW SaaS
- PA VM-Series IaaS in a spoke is NOT a valid Routing Intent next hop — no matter how you configure it
- You cannot service-chain from Azure Firewall in a hub to an NVA in a spoke — there’s no mechanism
- You CAN split Azure Firewall (east-west) and PA VM-Series (internet) using static routes — but you must NOT enable Routing Intent
- If the hub had pre-existing static routes before Routing Intent was enabled, you must fully remove intent, clean up all routes, and re-enable — the platform doesn’t auto-reconcile
Choose the scenario that matches your security requirements, licensing investment, and operational maturity. There’s no single “right” answer — but there are several combinations that simply don’t work, and now you know which ones they are.
Tested and validated in lab and production environments, May 2026. Based on Microsoft Learn documentation and hands-on deployment experience.
That’s the full blog post ready to copy. Want me to also generate a featured image / header graphic for it, or export it as a Word document?