🌐 Azure Virtual WAN Architecture Guide

šŸ“‹ Table of Contents

šŸ” 1. Azure Virtual WAN Overview

graph TB subgraph "Azure Virtual WAN" VWAN[Virtual WAN Instance] subgraph "Virtual Hubs" Hub1[Hub - East US] Hub2[Hub - West Europe] Hub3[Hub - Southeast Asia] end subgraph "Connectivity Options" VPN[VPN Gateway] ER[ExpressRoute Gateway] P2S[Point-to-Site VPN] SD[SD-WAN Partners] end subgraph "Connected Resources" VNet1[Virtual Networks] Branch1[Branch Offices] Remote1[Remote Users] OnPrem1[On-Premises] end end VWAN --> Hub1 VWAN --> Hub2 VWAN --> Hub3 Hub1 --> VPN Hub1 --> ER Hub1 --> P2S VPN --> Branch1 ER --> OnPrem1 P2S --> Remote1 Hub1 --> VNet1 Hub2 --> VNet1 Hub3 --> VNet1 style VWAN fill:#e1f5fe style Hub1 fill:#f3e5f5 style Hub2 fill:#f3e5f5 style Hub3 fill:#f3e5f5
Diagram Explanation: This diagram illustrates the high-level Azure Virtual WAN architecture demonstrating the global network fabric concept. The Virtual WAN serves as the central orchestrator, functioning as a software-defined networking overlay that abstracts the complexity of traditional hub-and-spoke deployments.

šŸ—ļø Architecture Components:
  • Virtual WAN Instance: Acts as the global network container, providing unified management across regions with built-in redundancy and automatic failover capabilities
  • Virtual Hubs: Regional network aggregation points that eliminate the need for traditional hub VNets, providing native transit capabilities with Microsoft's global backbone integration
  • Gateway Integration: Each hub supports multiple gateway types simultaneously, enabling hybrid connectivity patterns without complex routing configurations

šŸš€ Traffic Flow Optimization: The architecture leverages Microsoft's global network backbone for inter-hub communication, ensuring optimal latency and throughput. Traffic between hubs bypasses the public internet, using Microsoft's private fiber network.

āš™ļø Default vs. Configured Behaviors:
  • Hub-to-Hub Connectivity (DEFAULT): Microsoft's backbone routing is automatic and enabled by default for Standard SKU Virtual WAN. No configuration required - traffic automatically uses the optimal Microsoft global network path
  • Any-to-Any Connectivity (CONFIGURABLE): The any-to-any model is controlled by two key settings:
    • --allow-branch-to-branch-traffic (controls branch-to-branch communication)
    • --allow-vnet-to-vnet-traffic (controls VNet-to-VNet communication)
  • Route Propagation (DEFAULT): By default, all connections propagate routes to the "Default" route table, enabling automatic connectivity discovery
  • Custom Segmentation (CONFIGURED): Organizations can override defaults using custom route tables to implement traffic segmentation and security policies

šŸŽÆ Configuration Control Points:
  • Virtual WAN Level: Global policies for branch-to-branch and VNet-to-VNet communication
  • Route Table Level: Granular control over which connections can communicate with each other
  • Connection Level: Individual connection association and propagation settings

šŸ“‹ Default Behavior Summary: Out-of-the-box, Standard SKU Virtual WAN provides full any-to-any connectivity with Microsoft backbone optimization. Organizations must explicitly configure restrictions if traffic segmentation is required for security or compliance purposes.

šŸ”„ Scalability Benefits: Unlike traditional hub-and-spoke models that require manual peering configurations, Virtual WAN automatically handles routing advertisements and updates. This eliminates the exponential complexity growth (n² problem) seen in traditional mesh topologies. The centralized policy engine ensures consistent security and routing policies across all connected resources, regardless of their geographic location.

šŸŒ Global Reach: The multi-hub design supports geo-distributed applications with automatic traffic steering to the nearest hub, reducing latency for end users. Cross-region redundancy is built-in, with automatic failover to alternate hubs in case of regional outages, ensuring business continuity for critical applications.

šŸ“¦ 2. Virtual WAN SKU Selection

graph LR subgraph "SKU Comparison" Basic[Basic SKU] Standard[Standard SKU] subgraph "Basic Features" B1[Site-to-Site VPN only] B2[Up to 2 Gbps aggregate] B3[No hub-to-hub connectivity] B4[No ExpressRoute support] end subgraph "Standard Features" S1[All VPN types supported] S2[ExpressRoute support] S3[Hub-to-hub connectivity] S4[Route tables & NVA support] S5[Up to 20 Gbps aggregate] S6[VNet-to-VNet transit] end end Basic --> B1 Basic --> B2 Basic --> B3 Basic --> B4 Standard --> S1 Standard --> S2 Standard --> S3 Standard --> S4 Standard --> S5 Standard --> S6 style Basic fill:#ffecb3 style Standard fill:#c8e6c9
Diagram Explanation: This comparison provides a detailed analysis of the two Virtual WAN SKU options, highlighting the architectural and functional differences that impact deployment decisions.

šŸ’” Basic SKU Analysis:
  • Site-to-Site VPN Only: Restricted to traditional IPSec VPN connections, suitable for simple branch connectivity scenarios with limited complexity
  • Bandwidth Limitations: 2 Gbps aggregate throughput across all connections, which may become a bottleneck for organizations with high bandwidth requirements
  • Isolated Hub Operation: Each hub operates independently without inter-hub communication, requiring traditional VNet peering for cross-region connectivity
  • No Advanced Features: Lacks support for custom routing, NVA integration, and advanced security features

šŸš€ Standard SKU Capabilities:
  • Comprehensive Gateway Support: Supports all gateway types including ExpressRoute (up to 10 Gbps per circuit), Point-to-Site VPN (supporting up to 100,000 concurrent users), and Site-to-Site VPN with advanced BGP features
  • Hub-to-Hub Transit: Enables automatic hub-to-hub connectivity using Microsoft's global backbone, providing optimal routing without additional configuration
  • Advanced Routing Engine: Supports custom route tables, route propagation policies, and static route injection for granular traffic control
  • Security Integration: Native support for Azure Firewall, third-party NVAs, and advanced security policies with automatic rule propagation
  • High Performance: Up to 20 Gbps aggregate throughput with auto-scaling capabilities and performance monitoring

šŸŽÆ Selection Criteria: Choose Basic SKU for proof-of-concept deployments or simple branch connectivity with minimal traffic. Standard SKU is essential for production environments requiring enterprise-grade features, high availability, advanced security, or plans for future expansion. The cost difference is typically justified by the operational simplicity and advanced capabilities provided.

šŸ“Š Migration Considerations: Migration from Basic to Standard SKU requires recreation of the Virtual WAN instance and all associated resources, making initial SKU selection critical. Standard SKU provides future-proofing for evolving networking requirements and regulatory compliance needs.
Step 1: Create Resource Group
az group create \
    --name rg-vwan-prod \
    --location eastus \
    --tags environment=production project=networking
Purpose: Creates a resource group to contain all Virtual WAN resources.
Parameters:
ParameterDescriptionOptions
--nameResource group nameMust be unique within subscription
--locationAzure regioneastus, westus2, westeurope, etc.
--tagsMetadata tagsKey-value pairs for organization
Next Step: Create the Virtual WAN instance within this resource group.
Step 2: Create Virtual WAN (Standard SKU)
az network vwan create \
    --resource-group rg-vwan-prod \
    --name vwan-global-prod \
    --location eastus \
    --type Standard \
    --disable-vpn-encryption false \
    --allow-branch-to-branch-traffic true \
    --allow-vnet-to-vnet-traffic true \
    --tags environment=production tier=standard
Purpose: Creates the Virtual WAN instance with Standard SKU for full functionality.
Key Parameters:
ParameterDescriptionOptions
--typeSKU typeBasic, Standard
--disable-vpn-encryptionVPN encryption settingtrue, false (recommended: false)
--allow-branch-to-branch-trafficInter-branch communicationtrue, false
--allow-vnet-to-vnet-trafficVNet-to-VNet transittrue, false
Next Step: Create Virtual Hubs in desired regions.

šŸ—ļø 3. Architecture Design

graph TB subgraph "Multi-Region Virtual WAN Architecture" subgraph "North America" HubUS[Virtual Hub - East US] VPNGWUS[VPN Gateway] ERGWUS[ExpressRoute Gateway] P2SGWUS[P2S Gateway] end subgraph "Europe" HubEU[Virtual Hub - West Europe] VPNGWEU[VPN Gateway] ERGWEU[ExpressRoute Gateway] end subgraph "Asia Pacific" HubAP[Virtual Hub - Southeast Asia] VPNGWAP[VPN Gateway] end subgraph "Connected Resources" VNetUS1[VNet - Web Apps US] VNetUS2[VNet - Database US] VNetEU1[VNet - Web Apps EU] VNetAP1[VNet - Analytics AP] BranchUS[US Branch Office] BranchEU[EU Branch Office] BranchAP[AP Branch Office] RemoteUsers[Remote Users] DataCenter[Corporate Data Center] end end HubUS --> VPNGWUS HubUS --> ERGWUS HubUS --> P2SGWUS HubEU --> VPNGWEU HubEU --> ERGWEU HubAP --> VPNGWAP VPNGWUS --> BranchUS VPNGWEU --> BranchEU VPNGWAP --> BranchAP ERGWUS --> DataCenter ERGWEU --> DataCenter P2SGWUS --> RemoteUsers HubUS --> VNetUS1 HubUS --> VNetUS2 HubEU --> VNetEU1 HubAP --> VNetAP1 HubUS -.->|Hub-to-Hub| HubEU HubEU -.->|Hub-to-Hub| HubAP HubAP -.->|Hub-to-Hub| HubUS style HubUS fill:#e3f2fd style HubEU fill:#e8f5e8 style HubAP fill:#fff3e0
Diagram Explanation: This architecture demonstrates a sophisticated multi-region Virtual WAN deployment designed for global enterprise connectivity with geographic optimization and redundancy.

šŸŒ Regional Distribution Strategy:
  • North America Hub (East US): Serves as the primary hub with full gateway deployment including Point-to-Site for remote workforce, ExpressRoute for corporate data center connectivity, and VPN for branch offices. The region choice leverages low-latency connectivity to major US population centers
  • Europe Hub (West Europe): Provides GDPR-compliant data processing with ExpressRoute and VPN gateways, ensuring European data residency requirements are met while maintaining high-performance connectivity
  • Asia Pacific Hub (Southeast Asia): Offers VPN gateway for regional branch connectivity, positioned to serve the growing APAC market with optimal latency to major Asian business centers

šŸ”— Connectivity Patterns:
  • ExpressRoute Integration: Private connectivity from corporate data centers terminates at multiple hubs, providing redundant paths and automatic failover capabilities
  • Branch Office Connectivity: Each region's branch offices connect to their nearest hub, with automatic failover to alternate hubs during outages
  • VNet Distribution: Application workloads are distributed across regions based on user proximity and compliance requirements, with automatic cross-region connectivity

⚔ Hub-to-Hub Communication: The dotted lines represent Microsoft's global backbone connectivity, providing sub-50ms latency between major regions. This enables real-time application synchronization, disaster recovery scenarios, and global load balancing. Traffic between hubs is automatically encrypted and routed through Microsoft's private network, ensuring security and performance.

šŸ›”ļø Security and Compliance: Each hub can implement region-specific security policies while maintaining global consistency. Data sovereignty requirements are addressed by keeping regional traffic within appropriate geographic boundaries, while still enabling controlled cross-region communication for business continuity.

šŸ“ˆ Scalability and Performance: This design supports horizontal scaling by adding additional hubs in new regions as business grows. Each hub can scale independently based on regional demand, and the mesh connectivity ensures optimal routing regardless of traffic patterns. The architecture supports thousands of sites and millions of users with consistent performance.
Architecture Design Considerations:
  • Hub Placement: Deploy hubs in regions closest to your users and resources
  • Gateway Selection: Choose gateway types based on connectivity requirements
  • Redundancy: Consider multiple hubs per region for high availability
  • Bandwidth Planning: Size gateways based on expected traffic volume
  • Security: Implement routing policies and firewall integration

šŸ¢ 4. Hub Creation

sequenceDiagram participant Admin as Administrator participant CLI as Azure CLI participant ARM as Azure Resource Manager participant Hub as Virtual Hub participant Route as Route Table Admin->>CLI: az network vhub create CLI->>ARM: Validate parameters ARM->>Hub: Provision virtual hub Hub->>Route: Create default route table Route->>Hub: Configure initial routes Hub->>ARM: Hub ready ARM->>CLI: Success response CLI->>Admin: Hub created successfully Note over Admin,Route: Hub creation process includes
automatic route table setup
Diagram Explanation: This sequence diagram illustrates the complex orchestration process behind Virtual Hub creation, revealing the automated infrastructure provisioning and configuration that occurs behind the scenes.

šŸ”„ Orchestration Process:
  • Parameter Validation: Azure Resource Manager performs comprehensive validation including subscription limits, regional capacity, IP address space conflicts, and SKU compatibility before initiating deployment
  • Infrastructure Provisioning: The hub creation involves deploying multiple Azure services including virtual routers, load balancers, and management infrastructure across multiple availability zones for high availability
  • Network Fabric Integration: The hub integrates with Microsoft's global network backbone, establishing BGP peering relationships and route advertisement capabilities

šŸ›£ļø Automatic Route Table Creation: During hub creation, Azure automatically provisions the default route table with built-in routes for hub infrastructure. This includes:
  • System Routes: Automatic routes for hub-to-hub communication and internet breakout
  • Propagation Policies: Default route learning and advertisement policies for connected resources
  • Security Rules: Basic traffic filtering rules to prevent unauthorized access to hub infrastructure

ā±ļø Deployment Timeline: Hub creation typically takes 10-15 minutes and includes several phases: resource allocation (2-3 minutes), network fabric integration (5-7 minutes), route table configuration (2-3 minutes), and final validation (1-2 minutes). During this time, the hub is not available for gateway deployment or connection association.

šŸ” Post-Deployment Verification: After successful creation, the system performs automated health checks including connectivity tests to other hubs, route propagation verification, and monitoring service initialization. This ensures the hub is fully operational before allowing additional resource deployment.

🚨 Error Handling: The process includes automatic rollback capabilities if any step fails, ensuring no partial deployments that could cause network instability. Common failure points include IP address conflicts, subscription quota limits, and regional capacity constraints.
Step 3: Create Virtual Hub - East US
az network vhub create \
    --resource-group rg-vwan-prod \
    --name vhub-eastus-prod \
    --vwan vwan-global-prod \
    --location eastus \
    --address-prefix 10.1.0.0/16 \
    --sku Standard \
    --tags region=eastus purpose=primary-hub
Purpose: Creates the primary Virtual Hub in East US region.
Key Parameters:
ParameterDescriptionConsiderations
--address-prefixHub IP address spaceMust not overlap with connected VNets
--skuHub SKUStandard required for full features
--vwanParent Virtual WANMust exist before hub creation
Address Planning: The /16 prefix provides 65,534 IP addresses for hub infrastructure and connected resources.
Step 4: Create Virtual Hub - West Europe
az network vhub create \
    --resource-group rg-vwan-prod \
    --name vhub-westeurope-prod \
    --vwan vwan-global-prod \
    --location westeurope \
    --address-prefix 10.2.0.0/16 \
    --sku Standard \
    --tags region=westeurope purpose=secondary-hub
Purpose: Creates a secondary Virtual Hub in West Europe for European connectivity.
Network Segmentation: Uses 10.2.0.0/16 to avoid IP conflicts with the East US hub.
Next Step: Deploy gateways into the created hubs based on connectivity requirements.

āš–ļø 5. Gateway Scale Units

graph TD subgraph "Gateway Scale Units" subgraph "VPN Gateway" VPN1[1 Scale Unit = 500 Mbps] VPN2[2 Scale Units = 1 Gbps] VPN3[20 Scale Units = 10 Gbps] VPN4[40 Scale Units = 20 Gbps] end subgraph "ExpressRoute Gateway" ER1[1 Scale Unit = 2 Gbps] ER2[2 Scale Units = 4 Gbps] ER3[10 Scale Units = 20 Gbps] end subgraph "Point-to-Site Gateway" P2S1[1 Scale Unit = 500 Mbps] P2S2[Up to 100 Scale Units] P2S3[Max 100,000 users] end end subgraph "Scaling Factors" Traffic[Traffic Volume] Users[Number of Users] Sites[Number of Sites] Redundancy[Redundancy Requirements] end Traffic --> VPN1 Users --> P2S1 Sites --> VPN2 Redundancy --> ER1 style VPN1 fill:#e3f2fd style ER1 fill:#e8f5e8 style P2S1 fill:#fff3e0
Diagram Explanation: This diagram provides comprehensive scaling guidance for Virtual WAN gateways, essential for capacity planning and cost optimization in enterprise deployments.

šŸ”Œ VPN Gateway Scaling Analysis:
  • Linear Scaling Model: Each scale unit provides 500 Mbps of site-to-site VPN throughput with support for approximately 30 concurrent connections per unit
  • BGP Performance: Higher scale units improve BGP convergence times and support more complex routing policies with faster failover capabilities
  • Connection Density: Maximum of 1,000 site-to-site connections per VPN gateway regardless of scale units, requiring careful planning for large branch deployments
  • Performance Characteristics: Actual throughput may vary based on packet size, encryption overhead, and geographical distance to connected sites

⚔ ExpressRoute Gateway Scaling:
  • High-Performance Design: Each scale unit provides 2 Gbps of dedicated ExpressRoute bandwidth with sub-millisecond latency for connected circuits
  • Circuit Aggregation: Multiple ExpressRoute circuits can be terminated on a single gateway, with automatic load balancing across available bandwidth
  • Redundancy Considerations: Multiple scale units provide redundancy and increased capacity, with automatic failover between gateway instances
  • FastPath Support: Higher scale configurations support ExpressRoute FastPath for direct data plane connectivity, bypassing gateway processing for improved performance

šŸ‘„ Point-to-Site Gateway Optimization:
  • User Density: Each scale unit supports approximately 10,000 concurrent users with 500 Mbps aggregate throughput
  • Authentication Scaling: Higher scale units improve authentication processing for large user bases, reducing connection establishment times
  • Geographic Distribution: Consider multiple P2S gateways in different regions for global remote workforce with optimal performance
  • Client Load Balancing: Azure automatically distributes client connections across available gateway instances for optimal performance

šŸ“Š Scaling Decision Framework:
  • Traffic Volume: Monitor current bandwidth utilization and plan for 2-3x growth to avoid performance degradation
  • Connection Count: Consider both current and projected connection requirements for each gateway type
  • Redundancy Requirements: Deploy additional scale units beyond minimum requirements for high availability scenarios
  • Cost Optimization: Balance performance requirements with operational costs, as scale units incur per-hour charges


šŸŽÆ Best Practices: Start with minimum scale units and monitor performance metrics to determine scaling needs. Implement Azure Monitor alerts for gateway utilization thresholds. Consider regional distribution of gateways for optimal user experience and disaster recovery capabilities.
Scale Unit Planning Guidelines:
Gateway TypeMin Scale UnitsMax Scale UnitsBandwidth per Unit
VPN Gateway140500 Mbps
ExpressRoute Gateway1102 Gbps
Point-to-Site VPN1100500 Mbps

šŸš€ 6. Gateway Deployment

flowchart TD Start([Start Gateway Deployment]) --> CheckHub{Virtual Hub Ready?} CheckHub -->|No| WaitHub[Wait for Hub Creation] WaitHub --> CheckHub CheckHub -->|Yes| SelectGW[Select Gateway Type] SelectGW --> VPNPath[VPN Gateway] SelectGW --> ERPath[ExpressRoute Gateway] SelectGW --> P2SPath[Point-to-Site Gateway] VPNPath --> ConfigVPN[Configure VPN Settings] ERPath --> ConfigER[Configure ExpressRoute Settings] P2SPath --> ConfigP2S[Configure P2S Settings] ConfigVPN --> DeployVPN[Deploy VPN Gateway] ConfigER --> DeployER[Deploy ER Gateway] ConfigP2S --> DeployP2S[Deploy P2S Gateway] DeployVPN --> ConnectSites[Connect Branch Sites] DeployER --> ConnectCircuits[Connect ER Circuits] DeployP2S --> ConfigUsers[Configure User Access] ConnectSites --> Complete([Deployment Complete]) ConnectCircuits --> Complete ConfigUsers --> Complete style SelectGW fill:#e3f2fd style Complete fill:#c8e6c9
Diagram Explanation: This comprehensive flowchart maps the gateway deployment process, highlighting critical decision points and dependencies that ensure successful implementation.

šŸ” Pre-Deployment Validation:
  • Hub Readiness Check: Verifies that the Virtual Hub is fully provisioned, has sufficient IP address space, and is not undergoing maintenance operations
  • Quota Verification: Ensures subscription limits allow for gateway deployment, including scale unit quotas and regional capacity constraints
  • Network Planning: Confirms that gateway subnet allocations don't conflict with existing network infrastructure

šŸš€ Gateway-Specific Deployment Paths:
  • VPN Gateway Path: Includes BGP ASN configuration, pre-shared key generation, and routing policy setup. Requires coordination with on-premises equipment for successful tunnel establishment
  • ExpressRoute Gateway Path: Involves circuit validation, bandwidth verification, and peering configuration. Requires coordination with service provider for circuit provisioning
  • Point-to-Site Gateway Path: Includes certificate authority setup, client configuration package generation, and user authentication policy configuration

āš™ļø Configuration Complexity Analysis:
  • VPN Configuration: Most complex due to IPSec parameter negotiation, BGP configuration, and potential for multiple site connections with varying requirements
  • ExpressRoute Configuration: Moderate complexity focusing on circuit integration and routing optimization for private connectivity
  • P2S Configuration: Variable complexity depending on authentication method (certificate-based vs. Azure AD integration)

šŸ”— Connection Establishment Process:
  • Site Connections: Involves creating VPN site objects, configuring connection parameters, and establishing IPSec tunnels with automatic retry mechanisms
  • Circuit Connections: Requires ExpressRoute circuit provisioning, peering configuration, and route filter application for controlled route advertisement
  • User Access: Includes client configuration distribution, certificate deployment, and user access policy enforcement


ā±ļø Deployment Timeline Expectations: VPN gateways typically deploy in 15-30 minutes, ExpressRoute gateways in 20-45 minutes, and P2S gateways in 10-20 minutes. Actual times may vary based on region, scale units, and current Azure service load. Plan for additional time for connection establishment and testing.

šŸ› ļø Post-Deployment Activities: Each deployment path concludes with connection validation, performance testing, and monitoring configuration. Establish baseline performance metrics and configure alerting for proactive issue detection.
Step 5: Deploy VPN Gateway
az network vpn-gateway create \
    --resource-group rg-vwan-prod \
    --name vpngw-eastus-prod \
    --vhub vhub-eastus-prod \
    --location eastus \
    --scale-unit 2 \
    --bgp-settings asn=65515 \
    --tags gateway-type=site-to-site region=eastus
Purpose: Deploys a VPN Gateway into the Virtual Hub for site-to-site connectivity.
Key Parameters:
ParameterDescriptionRecommendations
--scale-unitGateway capacityStart with 2 units (1 Gbps)
--bgp-settingsBGP configurationASN should be unique per region
--vhubTarget Virtual HubHub must be in same region
Deployment Time: VPN gateway deployment typically takes 15-30 minutes.
Next Step: Create VPN sites and connections after gateway deployment completes.
Step 6: Deploy ExpressRoute Gateway
az network express-route-gateway create \
    --resource-group rg-vwan-prod \
    --name ergw-eastus-prod \
    --location eastus \
    --virtual-hub vhub-eastus-prod \
    --min-scale-units 1 \
    --max-scale-units 2 \
    --tags gateway-type=expressroute region=eastus
Purpose: Deploys an ExpressRoute Gateway for private connectivity to on-premises.
Scaling Configuration:
ParameterDescriptionImpact
--min-scale-unitsMinimum capacityAlways-on bandwidth (2 Gbps)
--max-scale-unitsMaximum capacityBurst capacity (4 Gbps)
Cost Consideration: ExpressRoute gateways incur charges based on scale units provisioned.
Next Step: Connect ExpressRoute circuits to the gateway.
Step 7: Deploy Point-to-Site Gateway
az network p2s-vpn-gateway create \
    --resource-group rg-vwan-prod \
    --name p2sgw-eastus-prod \
    --location eastus \
    --scale-unit 1 \
    --vhub vhub-eastus-prod \
    --vpn-server-config p2s-config-prod \
    --address-space 172.16.0.0/16 \
    --tags gateway-type=point-to-site region=eastus
Purpose: Creates a Point-to-Site VPN gateway for remote user connectivity.
Prerequisites: Must create VPN server configuration first (contains authentication settings).
Address Space: 172.16.0.0/16 provides IP addresses for connecting clients.
Capacity: 1 scale unit supports up to 500 Mbps and 10,000 concurrent connections.
Next Step: Configure VPN server settings and client certificates.

šŸ›£ļø 7. Virtual Hub Routing

graph TB subgraph "Virtual Hub Routing Architecture" subgraph "Route Tables" DefaultRT[Default Route Table] CustomRT1[Custom Route Table 1] CustomRT2[Custom Route Table 2] NoneRT[None Route Table] end subgraph "Connections" VNetConn[VNet Connections] VPNConn[VPN Connections] ERConn[ExpressRoute Connections] P2SConn[P2S Connections] end subgraph "Traffic Flow" VNet1[VNet-A: 10.10.0.0/16] VNet2[VNet-B: 10.20.0.0/16] Branch1[Branch-A: 192.168.1.0/24] Branch2[Branch-B: 192.168.2.0/24] end end VNetConn --> DefaultRT VPNConn --> CustomRT1 ERConn --> CustomRT2 P2SConn --> DefaultRT DefaultRT --> VNet1 CustomRT1 --> Branch1 CustomRT2 --> Branch2 DefaultRT --> VNet2 VNet1 -.->|Inter-VNet| VNet2 Branch1 -.->|Branch-to-Branch| Branch2 VNet1 -.->|VNet-to-Branch| Branch1 style DefaultRT fill:#e3f2fd style CustomRT1 fill:#e8f5e8 style CustomRT2 fill:#fff3e0 style NoneRT fill:#ffebee
Diagram Explanation: This sophisticated routing architecture diagram illustrates the advanced traffic engineering capabilities of Virtual WAN hubs, enabling granular control over network traffic flow and security policy enforcement.

šŸ›£ļø Route Table Architecture:
  • Default Route Table: Automatically created with each hub, containing system routes and serving as the primary routing domain. All connections initially associate with this table unless explicitly configured otherwise
  • Custom Route Tables: User-defined routing domains that enable traffic segmentation, security policy enforcement, and custom routing policies. Each table can contain static routes, propagated routes, and route filters
  • None Route Table: Special isolation table that prevents route learning and propagation, used for complete traffic isolation scenarios or security quarantine

šŸ”„ Route Learning and Propagation:
  • Association Model: Determines which routes a connection learns and uses for forwarding decisions. Each connection can associate with only one route table at a time
  • Propagation Model: Controls which route tables receive routes from a connection. A single connection can propagate routes to multiple tables, enabling flexible traffic engineering
  • Label-Based Propagation: Allows bulk route propagation management using logical labels, simplifying large-scale deployments with hundreds of connections

šŸ“Š Traffic Flow Analysis:
  • Inter-VNet Communication: VNet-to-VNet traffic follows routes in the associated route table, enabling both direct communication and traffic inspection through security appliances
  • Branch-to-Branch Connectivity: Branch offices communicate through the hub using BGP-learned routes, with automatic failover and load balancing capabilities
  • VNet-to-Branch Integration: Hybrid connectivity allowing cloud resources to communicate with on-premises infrastructure through optimized routing paths

šŸŽÆ Advanced Routing Scenarios:
  • Traffic Inspection: Custom routes can direct traffic through Network Virtual Appliances (NVAs) for security inspection, compliance monitoring, and advanced filtering
  • Geo-Routing: Route tables can implement geographic routing policies, ensuring data residency compliance and optimal performance
  • Service Chaining: Multiple NVAs can be chained together using custom routing for comprehensive security policy enforcement


šŸ”’ Security and Isolation Benefits: Route table segregation enables micro-segmentation of network traffic, allowing different security zones (production, development, DMZ) to operate independently while maintaining controlled communication paths. This supports zero-trust networking principles and regulatory compliance requirements.

šŸ“ˆ Scalability Considerations: Virtual WAN supports up to 1,000 route tables per hub with 10,000 routes per table, enabling large-scale enterprise deployments. Route convergence is optimized for sub-second failover in most scenarios, ensuring high availability for critical applications.
Step 8: Create Custom Route Table
az network vhub route-table create \
    --resource-group rg-vwan-prod \
    --vhub-name vhub-eastus-prod \
    --name rt-dmz-prod \
    --labels DMZ Security \
    --routes destination_type=CIDR \
           destinations=10.100.0.0/16 \
           next_hop_type=ResourceId \
           next_hop=/subscriptions/{subscription-id}/resourceGroups/rg-vwan-prod/providers/Microsoft.Network/azureFirewalls/fw-hub-prod
Purpose: Creates a custom route table for DMZ traffic routing through Azure Firewall.
Key Components:
ParameterDescriptionExample Values
--labelsRoute table categorizationDMZ, Production, Development
destination_typeRoute destination typeCIDR, ResourceId
next_hop_typeNext hop typeResourceId, IPAddress
Use Case: This route table directs traffic to specific networks through a security appliance.
Next Step: Associate connections with the custom route table.
Step 9: Configure Route Table Association
az network vhub connection create \
    --resource-group rg-vwan-prod \
    --vhub-name vhub-eastus-prod \
    --name conn-dmz-vnet \
    --remote-vnet /subscriptions/{subscription-id}/resourceGroups/rg-vwan-prod/providers/Microsoft.Network/virtualNetworks/vnet-dmz-prod \
    --associated-route-table rt-dmz-prod \
    --propagated-route-tables rt-dmz-prod defaultRouteTable \
    --labels DMZ
Purpose: Associates a VNet connection with custom route table for traffic control.
Routing Concepts:
  • Associated Route Table: Routes this connection learns
  • Propagated Route Tables: Route tables that learn routes from this connection
  • Labels: Used for bulk route propagation management
Traffic Impact: This VNet will follow routes defined in rt-dmz-prod table.
Next Step: Verify routing configuration and test connectivity.
sequenceDiagram participant VNet as VNet-A participant Hub as Virtual Hub participant RT as Route Table participant FW as Azure Firewall participant Target as VNet-B VNet->>Hub: Traffic to 10.20.0.0/16 Hub->>RT: Lookup route for destination RT->>Hub: Route via Azure Firewall Hub->>FW: Forward traffic FW->>FW: Apply security rules FW->>Hub: Forward allowed traffic Hub->>Target: Deliver to VNet-B Target->>Hub: Return traffic Hub->>FW: Route return traffic FW->>Hub: Forward return traffic Hub->>VNet: Deliver to VNet-A Note over VNet,Target: Traffic inspection and
security policy enforcement
Diagram Explanation: This detailed sequence diagram illustrates the sophisticated traffic inspection process enabled by custom route table configuration, demonstrating how Virtual WAN integrates with security appliances for comprehensive traffic analysis.

šŸ” Traffic Interception Process:
  • Route Lookup Mechanism: When VNet-A initiates traffic to VNet-B, the Virtual Hub performs a longest prefix match against the associated route table, identifying the custom route directing traffic through Azure Firewall
  • Traffic Forwarding: The hub encapsulates the original packet and forwards it to the Azure Firewall's internal interface, maintaining source and destination information for policy enforcement
  • Stateful Inspection: Azure Firewall performs deep packet inspection, application-layer filtering, and threat intelligence correlation before making allow/deny decisions

šŸ›”ļø Security Policy Enforcement:
  • Application Rules: Layer 7 inspection enables URL filtering, application identification, and protocol validation beyond basic IP/port filtering
  • Network Rules: Traditional firewall rules based on source, destination, protocol, and port combinations with geographic and threat intelligence integration
  • NAT Rules: Source and destination NAT capabilities for address translation and service publishing scenarios
  • Logging and Analytics: Comprehensive logging of all traffic decisions with integration to Azure Monitor and Security Information and Event Management (SIEM) systems

šŸ”„ Bidirectional Traffic Flow: Return traffic from VNet-B follows the same inspection path, ensuring stateful connection tracking and symmetric routing. The firewall maintains connection state tables to optimize performance for established connections while providing full inspection for new traffic flows.

⚔ Performance Optimization:
  • Connection Tracking: Established connections bypass full inspection after initial policy validation, reducing latency for ongoing communications
  • Load Balancing: Multiple firewall instances can be deployed with automatic load distribution for high-throughput scenarios
  • Fast Path: Certain trusted traffic patterns can be configured for fast path routing, bypassing detailed inspection for performance-critical applications

šŸ“Š Traffic Analytics: The inspection process generates detailed telemetry including connection metadata, bandwidth utilization, threat detection events, and policy violation logs. This data feeds into security operations centers (SOCs) for continuous monitoring and threat hunting activities.

šŸŽÆ Integration Benefits: This architecture centralizes security policy enforcement, eliminates the need for distributed firewall deployments, and provides consistent security posture across all connected networks. The integration with Virtual WAN's global backbone ensures optimal routing while maintaining comprehensive security coverage.

šŸ”’ 8. Third-Party NVA Integration

graph TB subgraph "NVA Integration Architecture" subgraph "Virtual Hub" Hub[Virtual Hub] BGP[BGP Peering] Routes[Route Advertisement] end subgraph "NVA Deployment" NVA[Third-Party NVA] NVAVNET[NVA VNet] UDR[User Defined Routes] end subgraph "Traffic Inspection" FWRules[Firewall Rules] IPS[Intrusion Prevention] SSL[SSL Inspection] Analytics[Traffic Analytics] end subgraph "Connected Networks" Spoke1[Spoke VNet 1] Spoke2[Spoke VNet 2] Branch[Branch Office] end end Hub --> BGP BGP --> NVA NVA --> NVAVNET NVA --> UDR NVA --> FWRules NVA --> IPS NVA --> SSL NVA --> Analytics Hub --> Spoke1 Hub --> Spoke2 Hub --> Branch Spoke1 -.->|Inspected Traffic| NVA Spoke2 -.->|Inspected Traffic| NVA Branch -.->|Inspected Traffic| NVA style NVA fill:#ffecb3 style Hub fill:#e3f2fd style FWRules fill:#ffcdd2
Diagram Explanation: This comprehensive architecture diagram illustrates the sophisticated integration of third-party Network Virtual Appliances (NVAs) with Virtual WAN, enabling advanced security services and traffic inspection capabilities beyond native Azure offerings.

šŸ—ļø NVA Integration Architecture:
  • Dedicated NVA VNet: The NVA is deployed in its own VNet to provide isolation, independent scaling, and simplified management. This design prevents resource conflicts and enables dedicated resource allocation for security processing
  • BGP Peering Establishment: The NVA establishes BGP adjacency with the Virtual Hub, enabling dynamic route advertisement and automatic failover capabilities. This creates a more resilient and adaptive network topology
  • Route Advertisement Control: The NVA can selectively advertise routes to the hub, enabling traffic steering for specific destinations or traffic types that require inspection

šŸ” Advanced Security Capabilities:
  • Next-Generation Firewall Features: Advanced threat detection, intrusion prevention, application control, and URL filtering capabilities that extend beyond Azure native security services
  • SSL/TLS Inspection: Deep packet inspection of encrypted traffic by terminating SSL connections, inspecting content, and re-encrypting for the destination
  • Advanced Threat Protection: Integration with threat intelligence feeds, machine learning-based anomaly detection, and zero-day threat protection
  • Data Loss Prevention (DLP): Content inspection and policy enforcement to prevent sensitive data exfiltration

šŸ“Š Traffic Flow Analysis:
  • Selective Traffic Steering: Through custom routing policies and BGP advertisements, specific traffic flows can be directed through the NVA while allowing other traffic to follow optimal direct paths
  • Traffic Symmetry: Ensures that both ingress and egress traffic flows follow the same inspection path to maintain stateful connection tracking and security policy consistency
  • Load Distribution: Multiple NVA instances can be deployed with load balancing to handle high-throughput scenarios and provide redundancy

šŸ”„ High Availability Design:
  • Active-Passive Clustering: Multiple NVA instances with automatic failover capabilities ensure continuous security coverage even during appliance failures
  • Health Monitoring: Continuous health checks and BGP route withdrawal mechanisms provide rapid failover and service restoration
  • Cross-Region Redundancy: NVAs can be deployed across multiple regions with intelligent traffic distribution for disaster recovery scenarios

šŸ“ˆ Analytics and Monitoring:
  • Comprehensive Logging: Detailed traffic logs, security events, and performance metrics provide visibility into network behavior and security posture
  • SIEM Integration: Native integration with security information and event management systems for centralized security monitoring and incident response
  • Performance Analytics: Real-time monitoring of throughput, latency, and resource utilization to ensure optimal performance


šŸŽÆ Deployment Considerations: NVA integration requires careful planning of IP addressing, routing policies, and security configurations. Consider the performance impact of traffic inspection on overall network throughput and plan NVA sizing accordingly. Licensing and support models for third-party NVAs should be evaluated as part of the total cost of ownership.

šŸš€ Business Benefits: This integration enables organizations to leverage existing security investments, meet regulatory compliance requirements, and implement advanced security policies that may not be available in cloud-native solutions. The centralized deployment model reduces complexity while providing comprehensive security coverage across the entire network fabric.
Step 10: Create NVA VNet
az network vnet create \
    --resource-group rg-vwan-prod \
    --name vnet-nva-prod \
    --location eastus \
    --address-prefixes 10.50.0.0/16 \
    --subnet-name subnet-nva-external \
    --subnet-prefixes 10.50.1.0/24 \
    --tags purpose=nva-security tier=premium
Purpose: Creates a dedicated VNet for hosting the third-party NVA.
Network Design: Uses 10.50.0.0/16 to avoid conflicts with hub and spoke networks.
Subnet Planning: External subnet for NVA interfaces; additional subnets may be needed for management.
Next Step: Create additional subnets for NVA internal and management interfaces.
Step 11: Create Additional NVA Subnets
az network vnet subnet create \
    --resource-group rg-vwan-prod \
    --vnet-name vnet-nva-prod \
    --name subnet-nva-internal \
    --address-prefixes 10.50.2.0/24

az network vnet subnet create \
    --resource-group rg-vwan-prod \
    --vnet-name vnet-nva-prod \
    --name subnet-nva-management \
    --address-prefixes 10.50.3.0/24
Purpose: Creates internal and management subnets for comprehensive NVA deployment.
Subnet Functions:
  • External (10.50.1.0/24): Internet-facing interface
  • Internal (10.50.2.0/24): Hub-facing interface for inspected traffic
  • Management (10.50.3.0/24): Administrative access and monitoring
Next Step: Deploy the NVA appliance with appropriate network interfaces.
Step 12: Connect NVA VNet to Virtual Hub
az network vhub connection create \
    --resource-group rg-vwan-prod \
    --vhub-name vhub-eastus-prod \
    --name conn-nva-prod \
    --remote-vnet vnet-nva-prod \
    --enable-internet-security true \
    --routing-configuration associated-route-table=defaultRouteTable \
                             propagated-route-tables=defaultRouteTable \
                             static-routes='[{"name":"nva-route","address-prefixes":["0.0.0.0/0"],"next-hop-ip-address":"10.50.2.10"}]'
Purpose: Connects the NVA VNet to the Virtual Hub with custom routing configuration.
Key Configuration:
ParameterDescriptionImpact
enable-internet-securityInternet traffic inspectionRoutes internet traffic through NVA
static-routesCustom route injectionDefines traffic flow patterns
next-hop-ip-addressNVA internal interface IPMust match NVA configuration
Traffic Flow: Default route (0.0.0.0/0) directs all traffic through the NVA at 10.50.2.10.
Next Step: Configure the NVA appliance to establish BGP peering with the hub.
āš ļø NVA Integration Considerations:
  • Performance: NVA throughput may become a bottleneck for high-traffic scenarios
  • High Availability: Deploy multiple NVA instances for redundancy
  • Routing Complexity: Complex routing scenarios may require careful route table design
  • Licensing: Third-party NVAs typically require separate licensing

šŸ”„ 9. Command Execution Flow

flowchart TD Start([Start Deployment]) --> Step1[1. Create Resource Group] Step1 --> Step2[2. Create Virtual WAN] Step2 --> Step3[3. Create Virtual Hubs] Step3 --> Step4{Need VPN Gateway?} Step4 -->|Yes| Step5[4. Deploy VPN Gateway] Step4 -->|No| Step6{Need ExpressRoute?} Step5 --> Step6 Step6 -->|Yes| Step7[5. Deploy ER Gateway] Step6 -->|No| Step8{Need P2S VPN?} Step7 --> Step8 Step8 -->|Yes| Step9[6. Deploy P2S Gateway] Step8 -->|No| Step10[7. Configure Routing] Step9 --> Step10 Step10 --> Step11{Need Custom Routing?} Step11 -->|Yes| Step12[8. Create Route Tables] Step11 -->|No| Step13{Need NVA?} Step12 --> Step13 Step13 -->|Yes| Step14[9. Deploy NVA Integration] Step13 -->|No| Step15[10. Connect VNets] Step14 --> Step15 Step15 --> Step16[11. Create Site Connections] Step16 --> Step17[12. Test Connectivity] Step17 --> Complete([Deployment Complete]) style Start fill:#c8e6c9 style Complete fill:#c8e6c9 style Step1 fill:#e3f2fd style Step2 fill:#e3f2fd style Step3 fill:#e3f2fd
Diagram Explanation: This comprehensive flowchart provides a strategic deployment roadmap for Virtual WAN implementation, incorporating decision trees and dependency management essential for successful enterprise-scale deployments.

šŸŽÆ Strategic Deployment Phases:
  • Foundation Phase (Steps 1-3): Establishes the core infrastructure including resource organization, Virtual WAN instance creation, and regional hub deployment. This phase requires careful planning of IP address spaces and regional distribution strategies
  • Gateway Phase (Steps 4-6): Deploys connectivity gateways based on organizational requirements. The decision tree approach ensures only necessary gateways are deployed, optimizing costs and complexity
  • Advanced Configuration Phase (Steps 7-9): Implements sophisticated routing policies, security integrations, and traffic engineering capabilities for enterprise-grade functionality
  • Integration Phase (Steps 10-12): Connects external resources and validates end-to-end connectivity with comprehensive testing procedures

šŸ” Decision Point Analysis:
  • VPN Gateway Decision: Consider factors including number of branch offices, bandwidth requirements, redundancy needs, and integration with existing on-premises infrastructure
  • ExpressRoute Decision: Evaluate requirements for dedicated bandwidth, predictable latency, compliance mandates, and existing ExpressRoute investments
  • Point-to-Site Decision: Assess remote workforce size, security requirements, client device management, and user experience expectations
  • Custom Routing Decision: Determine need for traffic segmentation, security policy enforcement, compliance requirements, and traffic engineering capabilities
  • NVA Integration Decision: Evaluate advanced security requirements, existing security tool investments, compliance mandates, and performance requirements

ā±ļø Deployment Timeline Planning:
  • Parallel Deployment Opportunities: While the flowchart shows sequential steps, certain activities can be parallelized, such as creating multiple hubs simultaneously or preparing NVA configurations while gateways deploy
  • Critical Path Management: Hub creation is on the critical path for all subsequent activities, while gateway deployments can often proceed in parallel once hubs are available
  • Validation Checkpoints: Each phase should include validation steps to ensure proper functionality before proceeding to the next phase, preventing cascading issues

šŸ› ļø Dependencies and Prerequisites:
  • Resource Dependencies: Each step has specific prerequisites that must be completed successfully. For example, custom route tables require existing hub infrastructure
  • External Dependencies: Some steps require coordination with external parties, such as ExpressRoute circuit provisioning or third-party NVA licensing
  • Configuration Dependencies: Advanced features like NVA integration require careful coordination of routing, security, and connectivity configurations

šŸ”§ Customization Flexibility: The flowchart accommodates various deployment scenarios from simple site-to-site connectivity to complex multi-region, multi-service architectures. Organizations can follow alternative paths based on their specific requirements while maintaining architectural consistency.

šŸ“Š Success Metrics: Each deployment phase should include measurable success criteria including connectivity validation, performance benchmarking, security posture assessment, and operational readiness verification. This ensures deployment quality and provides baseline metrics for ongoing operations.

šŸš€ Scalability Planning: The deployment approach supports both immediate requirements and future expansion scenarios. The modular design enables incremental feature adoption and capacity scaling without requiring architectural changes to existing components.
Complete Deployment Script
#!/bin/bash

# Set variables
RESOURCE_GROUP="rg-vwan-prod"
LOCATION="eastus"
VWAN_NAME="vwan-global-prod"
HUB_NAME="vhub-eastus-prod"
SUBSCRIPTION_ID=$(az account show --query id -o tsv)

echo "šŸš€ Starting Azure Virtual WAN deployment..."

# Step 1: Create Resource Group
echo "šŸ“ Creating resource group..."
az group create \
    --name $RESOURCE_GROUP \
    --location $LOCATION \
    --tags environment=production project=networking

# Step 2: Create Virtual WAN
echo "🌐 Creating Virtual WAN..."
az network vwan create \
    --resource-group $RESOURCE_GROUP \
    --name $VWAN_NAME \
    --location $LOCATION \
    --type Standard \
    --disable-vpn-encryption false \
    --allow-branch-to-branch-traffic true \
    --allow-vnet-to-vnet-traffic true

# Step 3: Create Virtual Hub
echo "šŸ¢ Creating Virtual Hub..."
az network vhub create \
    --resource-group $RESOURCE_GROUP \
    --name $HUB_NAME \
    --vwan $VWAN_NAME \
    --location $LOCATION \
    --address-prefix 10.1.0.0/16 \
    --sku Standard

# Step 4: Deploy VPN Gateway
echo "šŸ”’ Deploying VPN Gateway..."
az network vpn-gateway create \
    --resource-group $RESOURCE_GROUP \
    --name vpngw-eastus-prod \
    --vhub $HUB_NAME \
    --location $LOCATION \
    --scale-unit 2 \
    --bgp-settings asn=65515

# Step 5: Deploy ExpressRoute Gateway
echo "⚔ Deploying ExpressRoute Gateway..."
az network express-route-gateway create \
    --resource-group $RESOURCE_GROUP \
    --name ergw-eastus-prod \
    --location $LOCATION \
    --virtual-hub $HUB_NAME \
    --min-scale-units 1 \
    --max-scale-units 2

echo "āœ… Virtual WAN deployment completed successfully!"
echo "šŸ” Verify deployment in Azure Portal or using 'az network vwan show' command"
Purpose: Complete deployment script that automates Virtual WAN setup with proper error handling and progress indicators.
Execution Order: The script follows the exact sequence required for successful deployment, with each step depending on the previous one's completion.
Customization: Modify variables at the top of the script to match your environment requirements.
Error Handling: Add error checking between steps for production use to ensure each command completes successfully before proceeding.
šŸŽÆ Deployment Summary:

This comprehensive guide provides a complete Virtual WAN implementation covering SKU selection, multi-region architecture design, gateway deployment with proper scaling, advanced routing configuration, and third-party NVA integration. The modular approach allows you to implement components based on your specific requirements while maintaining a scalable and secure network architecture.

Key Benefits Achieved:

  • āœ… Global connectivity with optimized routing
  • āœ… Centralized network management
  • āœ… Scalable gateway deployment
  • āœ… Advanced security integration
  • āœ… Automated deployment capabilities