Azure Virtual WAN

Azure Virtual WAN is a networking service that brings together multiple networking, security, and routing functionalities into a single operational interface. It is built on a hub-and-spoke architecture where each hub (called a Virtual Hub) resides in an Azure region and acts as a central point of connectivity. Spokes can be virtual networks (VNets), branch offices connected via Site-to-Site VPN, remote users via Point-to-Site VPN, or on-premises data centers via ExpressRoute. The Virtual WAN itself is a container that manages multiple hubs across regions, providing global connectivity and routing.

Traditional hub-and-spoke networking in Azure required manual configuration of VNet peering, VPN gateways, and ExpressRoute gateways in each hub VNet. As organizations expanded globally, managing point-to-point connections between dozens of branches and VNets became complex and error-prone. Azure Virtual WAN automates much of this: it creates and manages the hub infrastructure, including gateways, and provides a centralized routing engine that uses the Border Gateway Protocol (BGP) to propagate routes between all connected entities. It also integrates with Azure Firewall and third-party Network Virtual Appliances (NVAs) for centralized security inspection.

When you create a Virtual WAN, you define a container that spans one or more regions. Within each region, you create a Virtual Hub. The hub contains various gateways: - Site-to-Site VPN gateway: For branch offices using IPsec tunnels. - Point-to-Site VPN gateway: For remote users. - ExpressRoute gateway: For dedicated private connections. - Azure Firewall: Optional, for inspecting traffic between spokes and branches. - Routing infrastructure: A built-in router that uses BGP to exchange routes between all connections.

Each spoke VNet is attached to the hub via VNet connection, which is similar to VNet peering but managed by the Virtual WAN. The hub router learns routes from all attached spokes and gateways. For example, a branch office connected via VPN advertises its on-premises prefixes over BGP. The hub router propagates these routes to all other spokes and gateways, enabling direct connectivity between branches and VNets without traversing the hub unnecessarily (unless forced by routing policies).

Azure Virtual WAN is primarily managed through the Azure portal, CLI, or PowerShell. Example CLI commands:

# Create a Virtual WAN
az network vwan create --name MyVwan --resource-group MyRG --location westus --type Standard

# Create a Virtual Hub
az network vhub create --name MyHub --resource-group MyRG --vwan MyVwan --address-prefix 10.0.0.0/24 --location westus

# Create a Site-to-Site VPN gateway in the hub
az network vpn-gateway create --name MyVpnGateway --resource-group MyRG --location westus --hub-name MyHub --scale-unit 2

# Create a VPN site (branch)
az network vpn-site create --name Branch1 --resource-group MyRG --location westus --virtual-wan MyVwan --ip-address 203.0.113.1 --bgp-peering-address 169.254.21.1

# Connect the VPN site to the hub
az network vpn-connection create --name Branch1Conn --resource-group MyRG --vpn-gateway-name MyVpnGateway --vpn-site Branch1

# Connect a VNet to the hub
az network vhub-connection create --name VNet1Conn --resource-group MyRG --vhub MyHub --remote-vnet VNet1

# View effective routes on a hub
az network vhub get-effective-routes --resource-group MyRG --name MyHub --resource-type VNetConnection --resource-id /subscriptions/.../virtualNetworks/VNet1

The hub router maintains a routing table that is populated via BGP from connected gateways and via static routes from VNet connections. By default, the hub router advertises the hub address space and any learned routes to all connected spokes and branches. Traffic between two spokes in the same region can be routed directly through the hub (or via the hub's firewall if configured). Traffic between spokes in different regions always goes through the hub in each region, using the Microsoft backbone. The hub router uses the concept of route tables and labels to control propagation. For example, you can create a custom route table that isolates a set of spokes from others.

Each Virtual Hub can support up to 500 VNet connections, 1000 Site-to-Site VPN connections, 10 ExpressRoute circuits, and 10,000 concurrent Point-to-Site VPN users. Aggregate throughput for a VPN gateway can reach 40 Gbps (with 40 scale units). ExpressRoute gateways can reach 100 Gbps. Latency is minimal because traffic stays within the Microsoft backbone. For global connectivity, hubs in different regions are interconnected via the Microsoft global network, providing low-latency any-to-any connectivity.

Virtual WAN supports Azure Firewall for centralized traffic inspection. For compliance, you can enforce routing so that all traffic between spokes and branches passes through the firewall. Additionally, you can use Private Link to ensure traffic to PaaS services never leaves the Microsoft network. Network security groups (NSGs) can be applied at the subnet level in spoke VNets, but not directly on the hub. Application security groups (ASGs) are also supported in spokes.

Azure Monitor provides metrics for gateways (throughput, packet count, BGP peer status). Diagnostic logs can be enabled for VPN and ExpressRoute gateways. The get-effective-routes command is invaluable for troubleshooting routing issues. Common problems include BGP misconfiguration, overlapping address spaces, and route propagation not working due to route table labels. Always verify that the hub's address space does not overlap with any connected network.

A multinational retailer has 500 stores worldwide, each with a local internet connection. They also have three data centers (US, Europe, Asia) and multiple Azure VNets hosting e-commerce and inventory applications. Without Virtual WAN, they would need to configure hundreds of VPN tunnels and manage complex routing. With Azure Virtual WAN, they deploy a hub in each region (US West, US East, West Europe, Southeast Asia). Each store connects to the nearest hub via Site-to-Site VPN using a simple router. The data centers connect via ExpressRoute to their regional hubs. All VNets are attached to the hubs. The hub routers automatically exchange routes via BGP, enabling any store to reach any application or data center. The retail IT team can manage all connections from a single pane in the Azure portal. They also enable Azure Firewall in each hub to inspect traffic between stores and the internet, enforcing security policies. Scale: each hub handles up to 500 VPN connections, easily covering the stores. Performance: each VPN gateway at scale unit 10 provides 5 Gbps, sufficient for store traffic.

A bank requires that all traffic between branches and Azure VNets be inspected by a certified NVA. They deploy a third-party firewall (e.g., Palo Alto) in a spoke VNet in each region. They use Virtual WAN with BGP peering between the hub and the NVA. The NVA advertises a default route (0.0.0.0/0) to the hub, causing all outbound traffic from spokes and branches to be sent to the NVA for inspection. Additionally, they create custom route tables to isolate different business units (retail, investment, corporate). The hub router ensures that traffic between units is forced through the NVA. They also use ExpressRoute with Global Reach for low-latency connectivity between data centers. Common misconfiguration: overlapping BGP AS numbers between the NVA and the hub, which causes route flapping. They solved this by using unique private AS numbers for each NVA.

A technology company transitions to remote work and needs secure connectivity for 10,000 employees globally. They use Point-to-Site VPN on Azure Virtual WAN. They deploy hubs in three regions (North America, Europe, Asia). Each hub's Point-to-Site gateway is configured with 20 scale units, supporting 10,000 concurrent connections. Employees use the Azure VPN Client with Azure Active Directory authentication. Traffic from remote users is routed through the hub and then to corporate VNets or to the internet (with Azure Firewall inspection). The company also integrates with Azure Private DNS so that employees can resolve on-premises resources. Common issue: users in one region connecting to a hub far away, causing high latency. They solved this by using Azure Traffic Manager to redirect users to the nearest hub based on geo-location.