Skip to main content
This guide explains how to use Azure Firewall Manager in practice and compares the two common deployment models: Hub Virtual Network (Hub VNet) and Secured Virtual Hub (Virtual WAN secured hub). Both provide a centralized inspection point for traffic, but they differ in scale, automation, integration, and operational model. Use this article to decide which model fits your control, scale, and partner-integration needs. Key search terms: Azure Firewall Manager, Azure Firewall, Virtual WAN, secured virtual hub, hub virtual network, Firewall Policy, UDR, BGP. Summary table — Hub VNet vs Secured Virtual Hub
CapabilityHub Virtual Network (Hub VNet)Secured Virtual Hub (Virtual WAN)
TerminologyStandard Azure VNet acting as the hubSecured hub built on Azure Virtual WAN
Connectivity modelManual VNet peering (hub-and-spoke)Automated hub-and-spoke via Virtual WAN
Scale~10 Gbps VPN throughput; ~30 S2S tunnels (typical)Up to ~20 Gbps; thousands of tunnels; SD‑WAN integrations
AutomationManual peering, routing, partner setupCentralized management and partner integrations via VWAN
IP provisioningCustomer-managed firewall IPsVWAN auto-generates hub IPs
RoutingUDRs and manual route managementBGP-based centralized route management in VWAN
Forced tunnelingManual forced tunnel configurationsCombine Azure Firewall + partner services via VWAN
Third-party partnersManual integrationAutomated/managed partner integrations
WAF / NVAsSupported; often hub or spokeSupported; typically deployed in spokes
DDoS ProtectionDirectly integrable with DDoS Protection plansIntegration model differs; check Azure docs
Terminology
  • Hub VNet: A standard Azure Virtual Network you create and manage to act as a central inspection and routing point.
  • Secured Virtual Hub: A hub implemented with Azure Virtual WAN (VWAN) that offers higher automation, global connectivity, and partner integrations.
Hub connectivity and scale
  • Hub VNets use manual VNet peering for hub-and-spoke topologies. This gives control but increases operational overhead as the environment grows.
  • Secured Hubs automate hub-and-spoke connectivity using Azure Virtual WAN. They scale higher and are designed for enterprise-grade, global connectivity with automated branch and SD‑WAN integrations.
Automation and integration
  • Hub VNets require explicit configuration for peering, routing (UDRs), and third-party integrations.
  • Secured Hubs automate many connectivity tasks and include built-in partner integrations (for example, SD‑WAN providers and third‑party security services available through Virtual WAN).
IP and hub provisioning
  • Hub VNets: you assign and manage firewall IP addresses.
  • Secured Hubs: Virtual WAN can auto-provision hub IP addresses, reducing manual network configuration.
High availability and third-party partners
  • Both models support availability zones and resiliency patterns.
  • Third-party partner integrations (e.g., Zscaler, Check Point) require manual setup in Hub VNets, while VWAN secured hubs often provide automated integration workflows.
Routing and forced tunneling
  • Hub VNets rely on User-Defined Routes (UDRs) and route propagation you maintain.
  • Secured Hubs centralize routing with BGP-based management inside the VWAN fabric, simplifying routing at scale.
  • For forced tunneling to third-party services, Hub VNets need manual UDR and routing configuration; VWAN secured hubs can combine Azure Firewall for private traffic with an integrated partner for internet filtering.
Web Application Firewall (WAF) and NVAs
  • Both architectures support WAF (Application Gateway) and Network Virtual Appliances (NVAs). With VWAN secured hubs, these are typically placed in spokes to keep the hub focused on transit and centralized enforcement.
DDoS Protection
DDoS integration models change over time. Always check Azure documentation before designing DDoS protection into VWAN-secured hubs or hub VNet topologies.
When to choose which model
  • Choose Hub VNet when you require fine-grained, customer-managed control over IP addressing, peering, and routing, and when your environment is small-to-medium scale.
  • Choose Secured Virtual Hub (Virtual WAN) for global-scale environments needing automation, central BGP routing, integrated partner services, and high tunnel throughput for many branch sites.
Configuration differences — step-by-step guidance Hub Virtual Network (more hands-on)
  1. Create an Azure Firewall Policy to define enforcement (DNAT, Network, Application rules, TLS inspection, Threat Intelligence settings).
  2. Design and implement the hub-and-spoke topology. Create the hub VNet and configure Manual VNet peering with spokes.
  3. Use Firewall Manager to centralize Azure Firewall policy management. If using third‑party NVAs, note these often require manual deployment and won’t be centrally managed by Firewall Manager the same way Azure Firewalls are.
  4. Configure UDRs on spoke subnets to force traffic to the hub firewall for inspection and egress routing.
Secured Virtual Hub (automated and scalable)
  1. Design the topology using Azure Virtual WAN: create a secured virtual hub and define spokes through VWAN.
  2. Select security providers — use Azure Firewall and optionally configure supported partner services available through VWAN.
  3. Attach Firewall Policies directly to the secured hub to centralize rule enforcement across hub traffic.
  4. Rely on VWAN centralized/BGP route management to control traffic steering; this reduces the need for manual UDRs and manual route distribution.
Key distinction: Hub VNets provide hands-on control; Secured Virtual Hubs provide streamlined automation and easier partner integration for large-scale deployments. Firewall Manager — control plane vs data plane Azure Firewall Manager is a control-plane service. It orchestrates and manages resources you deploy — such as Azure Firewall instances, Firewall Policies, secured virtual hubs, and hub VNets. There is no Firewall Manager appliance to deploy; instead, you use Firewall Manager to create and manage firewall resources and policies.
Azure Firewall Manager is a management/control-plane service. Look for and manage the resources (Azure Firewalls, Firewall Policies, and hub configurations) rather than a separate Firewall Manager VM or appliance.
Portal experience and policies In the Azure portal, go to Network Security → Firewall Manager to manage Azure Firewalls and Firewall Policies. From a Firewall Policy you can:
  • Review and edit DNAT, Network, and Application rule collections.
  • Configure settings such as Threat Intelligence, TLS Inspection, and parent/local policy relationships.
  • Attach policies to virtual networks, secured hubs, or specific Azure Firewall instances.
A screenshot of the Microsoft Azure portal displaying an Azure Firewall Policy page for "fw-policy-01," showing essentials like resource group, location, subscription ID, and provisioning state. The left-hand navigation lists Activity log, Rules (DNAT/Network/Application), and Settings with "Parent policy" highlighted.
From the Virtual Networks / Secured Virtual Networks view you can see which networks are managed, the policy status, and the associated Azure Firewall instances. This helps you confirm policy attachment and operational state across your hub and spoke environment.
A screenshot of the Microsoft Azure portal showing a firewall policy page titled "fw-policy-01 | Secured virtual networks." The page lists a virtual network (vnet-az700-firewall/AzureFirewallSubnet) with its policy status as Managed and the associated Azure Firewall and location.
References and further reading Use this guide to match the correct deployment model to your organizational needs — balancing control, scale, automation, and partner integrations.