Azure Virtual WAN: What’s Actually Supported — A Practical Guide to Routing Intent, Azure Firewall, and NVA Integration

---

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 defaultRouteTable and 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:

1. Routing Intent (declarative, platform-managed)
2. 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 or PA Cloud SaaS deployed in a secured vHub with Routing Intent enabled for both Internet and Private traffic. All spokes connected directly to the hub. Not using PA VM Series or IaaS NVA in spoke network.

          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 or PA Cloud NGFW	✅
Spoke ↔ Branch	Via Azure Firewall or PA Cloud NGFW	✅
Spoke → Internet	Via Azure Firewall or PA Cloud NGFW	✅
Branch → Internet	Via Azure Firewall or PA Cloud NGFW	✅
Inter-hub (if multi-hub)	Via Azure Firewall or PA Cloud NGFW (both hubs must have 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 defaultRouteTable and noneRouteTable can exist — delete all custom route tables
• No static routes with next hop type = VNet connection
• Azure Firewall or PA Cloud NGFW 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:

1. Fully remove Routing Intent
2. Delete all static routes, custom next hops, and custom route tables
3. Verify only defaultRouteTable and noneRouteTable remain
4. Re-enable Routing Intent

This forces the platform to rebuild the routing state from scratch.

Verdict: ✅ Fully Supported

---

Scenario 2: Split Firewall – 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 may 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 (Routing table only,    │
                    │  NO Routing Intent)           │
                    │                               │
                    │                               │
                    │  defaultRouteTable:           │
                    │  ┌──────────────────────────┐ │
                    │  │ 0.0.0.0/0     → PA conn  │ │
                    │  └──────────────────────────┘ │
                    └──┬────────┬────────┬──────────┘
                       │        │        │
                  Spoke 4   Spoke 5   PA Transit VNet

Traffic Flows

Source → Destination	Path	Inspected by
Spoke → Internet	Via PA transit VNet → PA	✅ Palo Alto
Branch → Internet	Via PA transit VNet → PA	✅ Palo Alto
Spoke ↔ Spoke	Direct via vHub	❌ Not inspected
Spoke ↔ Branch	Direct via vHub	❌ Not inspected
Inter-hub	Direct via vWAN backbone	❌ Not inspected
Branch ↔ Branch	Direct via vHub	❌ Not inspected

Configuration

defaultRouteTable Static Routes:

Route Name	Destination Prefix	Next Hop Type	Next Hop
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	defaultRouteTable
Propagated labels	none
Static routes	None
enableInternetSecurity	true

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 enableInternetSecurity is true on 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.

Pattern Comparison

Pattern	Internet via PA VM-Series or Transit NVA	Spoke-to-Spoke via VM-Series or Transit NVA	Why?
Direct spokes + custom route table (0.0.0.0/0 + RFC1918 → PA)	✅ Works	❌ Doesn’t work	vHub system routes override RFC1918 aggregates
Indirect spokes (peered to PA VNet) + UDRs (see scenario 6)	✅ Works	✅ Works	Spokes not connected to vHub — no system routes

Limitations

• Spoke-to-Spoke is not inspected – traffic between spokes are direct bypasses Palo Alto VM-Series
• Inter-hub traffic is not inspected — traffic between hubs bypasses Palo Alto VM-Series (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	Service Chain AzFW → PA	Static Routes	Transit NVA Network
Supported?	✅ Yes	✅ Yes	❌ No	❌ No	? Partial	✅ Yes
Routing Intent	✅ Yes	✅ Yes	❌ No	❌ No	❌ No	❌ No
Internet inspection	Azure Firewall or PA Cloud NGFW	PA Cloud NGFW	—	—	Palo Alto VM-Series	Palo Alto VM-Series
East-west inspection	Azure Firewall or PA Cloud NGFW	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	✅Optional	✅	—	—	❌	❌
Uses Azure Firewall	✅Optional	✅	—	—	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, but not required for just PA Cloud SasS	✅ Yes	—	—	❌ None	❌ None
PA licensing model	only if used	Cloud NGFW SaaS	—	—	VM-Series IaaS	VM-Series IaaS

---

Decision Flowchart

Do you need a third-party NVA (e.g., Palo Alto) for ALL traffic?
│
├─ NO → Scenario 1 (Azure Firewall + Full Routing Intent)
│
└─ YES → Is it PA Cloud NGFW (SaaS) or PA VM-Series (IaaS)?
         │
         ├─ Cloud NGFW → Scenario 1 or 2 (PA Cloud NGFW SaaS with Routing Intent)
         │
         └─ VM-Series IaaS → Do you need to secure east-west?
                      │
                      ├─ YES, east-west and internet → Scenario 6 (Transit NVA Network)
                      │                                 ✅ Full inspection coverage
                      │
                      └─ NO, Just internet → Scenario 5 (Static Routes — Internet Only)
                                              ✅ Simpler, no UDRs needed
                                       

---

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:

1. Routing Intent next hops must be in-hub resources — Azure Firewall, integrated NVA, or Cloud NGFW SaaS
2. PA VM-Series IaaS in a spoke vNet is NOT a valid Routing Intent next hop — no matter how you configure it
3. You cannot service-chain from Azure Firewall in a hub to an NVA in a spoke — there’s no mechanism
4. You cannot split Azure Firewall (east-west) and PA VM-Series (internet) using static routes — spoke filtering requires routing intent and a supported firewall such as PA Cloud NGFW, Azure Firewall or integrated vWAN partners
5. 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. hands-on deployment experience.

---