Cross-tenant VNet connectivity with a shared Virtual WAN hub
One of the primary benefits of Azure Virtual WAN is the ability to connect VNets from different Azure tenants to a single managed Virtual WAN hub. This centralizes routing, security controls, and operational management while avoiding complex peering topologies. To connect a VNet from another tenant you must have at least the Contributor (or Network Contributor) role on that VNet. To establish the connection, create a new hub connection and provide the resource ID of the target VNet — cross-tenant resource IDs are supported. This pattern is useful for shared services, mergers and acquisitions, and multi-tenant governance scenarios.Ensure you have at least Contributor or Network Contributor role on the target VNet before attempting cross-tenant connections, otherwise the hub connection cannot be established.
Routing, route tables, and policies in Virtual WAN
Azure Virtual WAN uses hub-level route tables to define how traffic flows between VNets, branch sites, and external networks. Understanding association, propagation, labels, and custom route policies is essential for predictable routing.- Association: Assign a connection (VNet, VPN site, ExpressRoute circuit) to a route table so traffic from that connection follows the table’s routes.
- Propagation: Allow connections to advertise their routes into other route tables, enabling dynamic route sharing.
- Labels: Group routes and control which routes propagate by tagging them with labels (for example: default, internet, none).
- Custom route policies: Implement detailed routing behaviors for hub-and-spoke, full mesh, split-tunnel scenarios, or to integrate NVAs and Route Server.
Virtual WAN vs. traditional hub-and-spoke
Use this quick comparison to decide when Virtual WAN makes sense versus building a manual hub-and-spoke architecture.| Feature | Azure Virtual WAN | Traditional Hub-and-Spoke |
|---|---|---|
| Management model | Managed service with built-in routing, scaling, and Microsoft backbone optimizations | Self-managed: you configure route tables, gateways, and NVAs |
| Connectivity types | Consolidates site-to-site VPN, point-to-site VPN, and ExpressRoute in one service | Requires separate gateways and configurations per connectivity type |
| Routing control | Central route tables, propagation, labels, and custom route policies | Manual route tables, peering, and NVA-based routing |
| Cross-tenant support | Native — hub connections accept VNets from other tenants | Complex: requires peering, delegated permissions, or workarounds |
| Scalability & performance | Designed for global scale; optimized over Azure backbone | Dependent on design, peering, and gateway placement |
| Deployment speed | Faster via Portal/ARM/CLI templates | Slower — many manual steps and verifications |
| NVA integration | Supports Azure Route Server and integrates with NVAs | Often necessary; depends on vendor appliances and BGP |
| Cost model | Pay-per-connection + data transfer through managed hub | Resource-based billing (gateways, NVAs, peering) |
| Best for | Global multi-branch, multi-tenant, centralized governance | Small deployments or highly customized networks with specific appliances |
Portal walkthrough — create a Virtual WAN and hub
Follow these steps in the Azure portal to create a Virtual WAN, add a virtual hub (and optional gateway), configure a User VPN (P2S), and attach VNets.- Create the Virtual WAN resource
- Navigate to Azure Virtual WAN → Create.
- Provide Subscription, Resource group, Region, and Name.
- Select Type (use Standard if you need point-to-site).
- Review settings and create.
- Create a Virtual Hub (and gateway if required)
- Click New hub.
- Provide subscription, resource group, region, hub name, and hub private address space (for example 10.140.0.0/16).
- Choose capacity (infrastructure routing units) according to throughput and client counts.
- Select routing preference and whether you need a gateway for P2S or S2S.
- Note: hub + gateway provisioning can take ~30 minutes.
Creating a hub with a gateway may take ~20–30 minutes. Ensure you plan for this provisioning time and that you have the required subscription permissions (Network Contributor or higher) before deployment.
Point-to-site (User VPN) configuration
You can configure a User VPN (P2S) from the Virtual WAN resource or while creating the hub. For OpenVPN + Microsoft Entra ID (Azure AD) authentication you need the audience (issuer) and tenant ID values from your Azure AD application. Example issuer/audience URLs (replace with your tenant GUID):
- Continue hub creation and P2S settings
- Under Point-to-site, set gateway units (scale units) to match expected concurrent clients—refer to Azure docs for current capacity guidance.
- Define the client address pool for P2S clients (for example 172.16.0.0/25).
- Review and create the hub. Expect provisioning time if a gateway is requested.
Connecting VNets to the hub
- Add virtual network connections to the hub:
- In Virtual WAN → Virtual network connections → Add connection.
- Choose the hub and the target virtual network (spoke).
- Configure association (route table) and propagation (which route labels to propagate).
- Create the connection and repeat for each spoke.
Download and use the Virtual WAN user VPN profile
From the User VPN (P2S) blade you can download a client profile (XML) for the Azure VPN Client. Import the profile into the Azure VPN Client and connect. The client will show the hub as the VPN server and list propagated VPN routes.
Verify connectivity
Once the P2S connection is established and VNets are connected to the hub, validate connectivity by:- Pinging or SSHing to VMs in different spoke VNets (internal IPs).
- Accessing internal web applications by their private IP addresses.
- Confirming propagated routes show up in the VPN client and hub route tables.
- Role permissions for cross-tenant VNet connections.
- Route table associations and propagation labels.
- VPN client configuration and AAD authentication claims/audience values.
- Hub and gateway provisioning status.