The behavior that confuses engineers most about Azure Virtual WAN is the moment they expect it to do something their old hand-built network could not. They stand up a virtual hub, connect two VNets, watch traffic flow between them without writing a single user-defined route, and conclude that Virtual WAN is a different kind of network with capabilities a manual design lacks. Then they hit a routing decision the managed network makes for them, try to override it the way they would override a route table on a spoke, and discover that the control surface is narrower and the abstraction is firmer than they assumed. The confusion is not about what Virtual WAN can do. It is about what kind of thing Virtual WAN is. The answer, and the claim this article will defend with reproducible commands and a reference model you can cite in a design review, is that Azure Virtual WAN is a managed hub-and-spoke and a global connectivity backbone, nothing more exotic and nothing less capable. Adopting it is a decision to trade the granular control of a network you build and route by hand for managed routing, automatic transit, and the ability to scale across regions without hand-stitching every connection. It is not a decision to acquire a capability that a manual hub-spoke fundamentally cannot have.

That distinction matters because it tells you where to look when Virtual WAN behaves in a way you did not predict. If you expected new capability, you will keep searching the portal for a knob that does not exist, because the knob you want belongs to the manual world you left behind. If you understand Virtual WAN as a managed version of the topology you already know, you will look in the right place: at the routing the service computes on your behalf, at the routing intent policy that overrides it, and at the few seams where the managed abstraction lets you reassert control. This article builds that mental model from the ground up, walks the routing and the routing intent at the level you need to debug them, shows the configuration that realizes a working multi-region backbone, catalogs the failure modes that send engineers in circles, and closes with the decision rule for when Virtual WAN earns its place and when a hand-built design is still the right call.

What Azure Virtual WAN Actually Is

Start with the shape, because the shape is the whole idea. A hub-and-spoke network places shared connectivity and shared services in a central hub and attaches workload networks, the spokes, to that hub. Traffic between spokes and traffic to and from on-premises and the internet flows through it, where you can inspect it, filter it, and route it centrally. Engineers have built this topology by hand for years using a VNet as the hub, VNet peering to attach the spokes, a gateway inside it for hybrid connectivity, route tables on every subnet to steer traffic, and a firewall inside it to control egress. The manual hub-spoke is the workhorse of Azure networking, and the article on hub-spoke network topology walks the hand-built version end to end.

Azure Virtual WAN is that same topology, except Microsoft builds and operates the hub for you. You do not deploy a hub VNet, peer the spokes by hand, place a gateway yourself, or write the route tables that connect everything. You declare a virtual hub in a region, attach your VNets and your connectivity endpoints to it, and the service provisions the underlying components, computes the routing, and maintains the transit relationships. The hub is a managed resource. You cannot RDP into it, you cannot see its route tables as VNet route tables, and you cannot place an arbitrary virtual machine inside it. What you get in exchange for that loss of access is a hub that scales, that connects to other hubs in other regions automatically, and that routes spoke-to-spoke, spoke-to-branch, and spoke-to-on-premises traffic without you authoring a single route by default.

The mental model to hold is a managed control plane sitting on top of the same data-plane primitives you already understand. Underneath the abstraction, the connections are still backed by the same kinds of constructs: VNet connections behave like peering, the VPN and ExpressRoute attachments terminate on managed gateways, and the routing is still longest-prefix matching against a route table. The difference is that you describe intent and association rather than authoring every primitive. When you connect a VNet to a hub, you are effectively asking the service to peer that VNet to the managed network and to program the routes that let it reach everything else attached to the hub. The service does the peering and the route programming. You see a connection object, not the peering and the route table behind it.

This is why the capability question resolves the way it does. Nothing Virtual WAN does is impossible in a manual hub-spoke. You can build spoke-to-spoke transit by hand with peering and route tables. You can connect regions by hand with VNet peering across regions or with hub-to-hub VPN. You can centralize a firewall by hand. Virtual WAN does not invent transit or global reach. It automates the construction and the maintenance of a topology that gets painful to build and operate by hand once the number of regions, spokes, and branches grows past what a small team can route correctly without mistakes. The value is operational, not capability. That is the heart of the managed-hub rule, and it is the lens through which every later section reads.

What Lives in a Virtual WAN and What Lives Around It

A Virtual WAN is the top-level resource, and it is mostly a container and a routing scope. Inside it you create one or more virtual hubs, each pinned to a region. The hub is where the work happens. To a hub you attach connections of several kinds: VNet connections that bring your workload networks into the topology, VPN sites and a VPN gateway for site-to-site and point-to-site encrypted connectivity, an ExpressRoute circuit through an ExpressRoute gateway for private connectivity, and, when you turn it on, a managed firewall that makes the hub a secured hub. Each hub has a routing scope of its own, expressed through route tables that the service manages, and the hubs within a Virtual WAN form a full mesh with each other so that any spoke on any hub can reach any spoke on any other hub.

The resources that live around the Virtual WAN are the ones you still own and operate normally. Your VNets are ordinary VNets; you keep their address spaces, their subnets, their NSGs, and their workloads. Your on-premises sites are your own. Your ExpressRoute circuit is provisioned the way any circuit is, as the ExpressRoute deep dive describes, and you attach it to the hub rather than to a standalone gateway in a hub VNet. Your VPN devices at branch offices are configured against the VPN gateway inside it. The Virtual WAN draws all of these into one routed topology, but it does not absorb them. The boundary is clean: the hub and its routing are managed, and everything that connects to the hub remains yours.

The InsightCrunch Virtual WAN Model

Here is the findable artifact this article is built around, the reference you can cite when someone asks what Virtual WAN is made of and how the pieces route. Call it the InsightCrunch Virtual WAN model. It maps every component to the manual construct it replaces, to what it connects, and to who controls its routing, so that you can reason about any traffic flow by reading the table rather than guessing.

Component	What it is	What it connects	Manual equivalent	Who controls routing
Virtual WAN	Top-level container and global routing scope	All hubs in the WAN	The whole hub-spoke estate	You, by association and policy
Virtual hub	Microsoft-managed regional hub	VNets, VPN, ExpressRoute, branches, other hubs	Hub VNet plus gateways plus firewall	The service, shaped by your config
VNet connection	Managed attachment of a spoke VNet	One VNet to one hub	VNet peering plus route tables	The service, per your associated and propagated route tables
VPN gateway (hub)	Managed site-to-site and point-to-site gateway	VPN sites and remote users to the hub	A VPN gateway inside it VNet	The service, with BGP to your devices
ExpressRoute gateway (hub)	Managed ExpressRoute attachment	An ExpressRoute circuit to the hub	An ExpressRoute gateway inside it VNet	The service, with BGP over the circuit
Hub route table	Managed route table scoping a hub	Connections, via association and propagation	A route table per spoke subnet	You, by associating and propagating
Routing intent	Centralized internet and private traffic policy	All connections on the hubs it covers	A pile of user-defined routes pointing at a firewall	You, with one policy per hub
Secured virtual hub	A hub with a managed firewall inside it	All traffic the routing intent sends to it	A firewall appliance inside it VNet	You, through firewall rules and routing intent

Read the table as a decoder. Any time Virtual WAN does something you did not expect, find the component, read its manual equivalent to recall how the behavior works in a world you already understand, and read the routing-control column to learn whether you change the behavior by editing a connection, an association, a propagation, or a routing intent policy. The model is small on purpose. The entire surface of Virtual WAN fits in those eight rows, and almost every production question reduces to which row you are standing on and which control column you should reach for.

The namable claim the model encodes is the managed-hub rule: every row has a manual equivalent, which is the proof that Virtual WAN adds no capability the manual hub-spoke lacks, only managed construction and maintenance of the same topology. When you adopt Virtual WAN you are not buying a new networking primitive. You are buying the operation of the rightmost-but-one column so you no longer have to build and maintain the constructs in it by hand across many regions.

How the Managed Hub Routes Traffic

Routing is where the managed abstraction either clicks or frustrates, so it deserves the most careful walk. The core fact is that each virtual hub has route tables, and those route tables are the mechanism by which connections learn how to reach each other. Two route tables exist by default on every hub. The Default route table is where connections live unless you say otherwise, and it is the table most spokes use. The None route table is a sink: a connection associated with None propagates and learns nothing, which is how you isolate a connection from the rest of the topology. You can also create custom route tables when you need to segment which connections can reach which.

Two verbs govern how a connection relates to a route table, and getting them straight is the single most useful piece of Virtual WAN routing knowledge. Association answers the question “which route table does this connection use to make its forwarding decisions?” A connection is associated with exactly one route table, and that table is the one the connection consults to decide where to send a packet. Propagation answers a different question: “which route tables learn about the routes this connection advertises?” A connection propagates its routes to one or more route tables, and any connection associated with a table that received the propagation can therefore reach the propagating connection. The default behavior is that every connection is associated with the Default table and propagates to the Default table, which is why, out of the box, every spoke can reach every other spoke and every branch and every on-premises network: they all read and write the same table.

Segmentation falls straight out of this. Suppose you want a group of production spokes to talk to each other and to on-premises, but a separate group of sandbox spokes to reach on-premises only and never the production spokes. You create a custom route table for production, associate the production spokes with it, and propagate the production spokes to it. You leave the sandbox spokes associated with the Default table but control what propagates into Default so they see on-premises but not production. The result is two routing domains inside one hub, achieved entirely through association and propagation, with no route authored by hand. This is the same isolation you would build by hand with route tables and careful peering in a manual hub-spoke, expressed as two managed knobs instead of dozens of route entries.

How Does a Packet Choose Its Path Through the Hub?

The forwarding decision is still longest-prefix matching, exactly as it is anywhere else in Azure and exactly as the route tables and user-defined routes discipline describes for the manual world. When a spoke sends a packet, the spoke’s effective routes, which now include routes learned from the hub it is connected to, are consulted, and the most specific matching prefix wins. The hub advertises into each connected VNet the address spaces of everything that VNet should be able to reach: other spokes on the same hub, spokes on remote hubs, on-premises ranges learned over VPN or ExpressRoute, and, when routing intent is configured, a default route that pulls internet-bound or inter-spoke traffic through the firewall. The spoke does not need a user-defined route to reach another spoke, because the hub has already programmed the spoke with a route to that spoke’s prefix.

The thing to internalize is ththere is doing the work a pile of user-defined routes would do in a manual design. In the hand-built world, a spoke that needs to reach another spoke through it needs a route table entry pointing that destination at its firewall or gateway as the next hop, and you author and maintain that entry. In Virtual WAN, the hub computes and advertises those routes from the association and propagation graph you declared, and the spoke receives them as effective routes. When you debug a flow that is not reaching its destination, you do not start by looking for a missing user-defined route on the spoke. You look at its effective routes for that connection and at which route table the connection is associated with, because that is where the decision is actually made.

Routing Intent: The Feature That Replaces a Pile of Routes

If you remember one feature from this article, make it routing intent, because it is the cleanest illustration of what managed routing buys you. In a manual hub-spoke that runs a central firewall, the way you force traffic through that firewall is to write user-defined routes on every spoke subnet that send the relevant destinations to the firewall as the next hop. For internet egress you write a route for 0.0.0.0/0 pointing at the firewall. For spoke-to-spoke inspection you write routes for each spoke’s prefix pointing at the firewall. You maintain these routes on every subnet, you keep them in sync as spokes come and go, and a single forgotten route table is a flow that bypasses inspection. Anyone who has operated that pattern at scale knows the maintenance burden and the audit anxiety it carries.

Routing intent collapses all of that into a single policy per hub. You declare, there level, that internet traffic should go through its firewall and that private traffic, meaning traffic between spokes and to and from on-premises, should also go through the firewall. The service then programs every connection on the hub with the routes that realize that intent. You do not author 0.0.0.0/0 on any spoke. You do not maintain per-spoke routes. You declare the intent once, and the managed routing computes and propagates the routes that enforce it across every connection, and it keeps them correct as connections are added and removed. This is the user-defined-route pile from the manual world, replaced by one declarative policy, and it is the single feature that most often justifies moving to Virtual WAN when central inspection across many spokes and regions is the requirement.

Routing intent has two policies you can enable independently. The internet-traffic policy steers internet-bound traffic, the 0.0.0.0/0 default, through the secured hub’s firewall, so that egress to the public internet is inspected and filtered centrally. The private-traffic policy steers traffic destined for private address ranges, which covers spoke-to-spoke, spoke-to-branch, and spoke-to-on-premises, through the firewall as well, so that east-west traffic is inspected. You can enable one, the other, or both. Enabling the private policy is what turns a flat reachable topology into one where lateral movement between workloads passes through inspection, which is usually the harder and more valuable thing to get right and the thing that is most tedious to maintain by hand.

How Does Routing Intent Interact with My Own Routes?

This is where engineers coming from the manual world stumble, because routing intent is opinionated and it largely takes over the routing decision for the traffic classes it covers. When you enable a routing intent policy, the service programs the connections with the routes that enforce it, and those routes are what the spokes use. You generally do not also hand-author competing user-defined routes for the same destinations, because the managed routing is now the authority for that traffic. The mental adjustment is to stop thinking in terms of “I will write the routes that force traffic to the firewall” and start thinking in terms of “I will declare the intent and let the hub write the routes.” If you find yourself wanting to author a 0.0.0.0/0 route on a spoke to push internet traffic to the firewall, the routing intent internet policy is the managed way to express exactly that, and reaching for the manual route is the symptom of expecting the wrong kind of network.

There are still seams where your own routing matters. Inside a spoke VNet you continue to own the subnet route tables for intra-VNet behavior and for anything the hub does not govern. When you have specific destinations that need a path different from what routing intent provides, you express that through its route tables, through static routes on the connection, or through the firewall’s own configuration rather than by fighting the managed routes on the spoke. The discipline is to make the change at the layer the managed model exposes for it, which the InsightCrunch Virtual WAN model’s routing-control column tells you for each component, rather than at the spoke route table where the change will either be overridden or create a confusing conflict.

Why Did My Traffic Stop Reaching the Internet After I Enabled Routing Intent?

A common and instructive surprise: you enable the internet-traffic routing intent policy expecting nothing to break, and suddenly spokes lose internet access. The cause is exactly what the policy says it does. Before routing intent, spokes reached the internet through Azure’s default outbound path. After you enable the internet policy, the hub programs a 0.0.0.0/0 route on the connections pointing internet traffic at the secured hub’s firewall, and if the firewall does not have a rule that allows that egress, the traffic is dropped at the firewall rather than sent to the internet. The fix is not to remove the routing intent. The fix is to recognize that you have just centralized internet egress through a firewall, which is what you asked for, and to author the firewall rules that allow the egress your workloads need. The behavior is correct; the missing piece is the firewall policy, and the diagnosis is to check the firewall logs for the dropped traffic rather than to hunt for a missing route.

The Secured Virtual Hub

A virtual hub becomes a secured virtual hub when you place a managed firewall inside it, either Azure Firewall or a supported third-party security partner. In the manual hub-spoke world, the firewall is a resource you deploy into the hub VNet, size, scale, and route traffic to with user-defined routes. In Virtual WAN, the firewall is provisioned into the managed network and becomes the inspection point that routing intent sends traffic to. The two features are designed to work together: the secured hub provides the firewall, and routing intent provides the routing that funnels traffic to it. You can run a secured hub without elaborate routing intent, but the common and intended pattern is to enable both, so that the firewall exists and the routing automatically uses it.

The reason the secured hub matters as a distinct concept, rather than just “a firewall inside it,” is that the firewall in a secured hub is integrated with the managed routing in a way a firewall you drop into a VNet is not. When you place a firewall in a manual hub VNet, you still have to write every route that sends traffic to it; the firewall does not program routes. In a secured hub, the firewall and the routing intent are part of the same managed system, so declaring that internet and private traffic should be inspected is enough to both have a firewall and have traffic reach it. The integration is the point. It is the difference between owning a firewall and owning a route table that points at it versus declaring an inspection intent and letting the platform wire the firewall into the path.

What Does the Firewall in a Secured Hub Actually Inspect?

It inspects exactly the traffic classes your routing intent sends to it, and nothing it is not in the path of. If you enable only the internet-traffic policy, the firewall sees internet-bound traffic and return traffic but does not see spoke-to-spoke traffic, which continues to flow directly through its routing without passing the firewall. If you enable the private-traffic policy as well, spoke-to-spoke, spoke-to-branch, and spoke-to-on-premises traffic is also pulled through the firewall for inspection. This is the lever that engineers most often get wrong: they assume that placing a firewall inside it means everything is inspected, then discover that lateral traffic between two spokes never touched the firewall because only the internet policy was enabled. The firewall inspects what the routing sends it, and the routing sends it what the routing intent policy declares, so the inspection scope is a direct consequence of which policies you turned on.

This connects back to the managed-hub rule in a precise way. A secured hub does not give you a kind of inspection a manual hub cannot perform. A manual hub with a firewall and the right user-defined routes inspects the same traffic. What the secured hub gives you is the same inspection without authoring and maintaining the routes that put the firewall in the path, and with the routing kept correct automatically as the topology changes. Once again the gain is operational. The capability was always there; the secured hub removes the per-spoke routing labor and the audit risk of a forgotten route that silently bypasses inspection.

The Connections: VNets, VPN, ExpressRoute, and Branches

A hub is only useful for what it connects, so walk the connection types in turn, because each one is a managed version of a primitive you already operate. The VNet connection is the simplest. You point a VNet at a hub, and the service attaches it to its routing, programming the VNet to reach everything its route tables permit and advertising the VNet’s address space to the rest of the topology. Behaviorally it is peering plus the routes that peering alone would not give you, since plain peering is not transitive and the hub provides the transit that makes spoke-to-spoke work. When you connect a spoke to a hub, you are getting the transit that a manual hub-spoke achieves with peering plus route tables, delivered as a single connection object.

The VPN gateway in a hub provides both site-to-site connectivity for branch offices and on-premises sites and point-to-site connectivity for remote users. You define VPN sites that describe your on-premises endpoints, including their public IP and their BGP details, and you connect them to its VPN gateway. The gateway is managed, so you do not size and deploy it as a VNet gateway; you specify a scale unit and the service provisions the capacity. The encrypted tunnels terminate on the hub, and the on-premises routes learned over BGP are propagated into its routing so that spokes can reach on-premises ranges. The mechanics of route-based connectivity, BGP, and the SKU-versus-scale-unit sizing question mirror what the VPN gateway deep dive covers for the standalone gateway, with the difference that here the gateway lives inside the managed network and feeds its routing directly.

The ExpressRoute gateway in a hub attaches an ExpressRoute circuit to the topology for private, high-bandwidth connectivity that does not traverse the public internet. You provision the circuit the usual way, then connect it to its ExpressRoute gateway. The circuit’s BGP advertises your on-premises prefixes into the hub, and the hub advertises Azure prefixes back over the circuit, so on-premises and Azure reach each other privately. Again the gateway is managed and sized by scale unit rather than deployed and scaled by hand. The decision between ExpressRoute and VPN for a given site is the same decision you would make outside Virtual WAN, weighing bandwidth, latency, cost, and whether traffic must stay off the public internet, and the ExpressRoute deep dive lays out that trade-off in full.

How Do Branches and SD-WAN Connect to Virtual WAN?

Branch connectivity is one of the places Virtual WAN was specifically designed to shine, because connecting many branch offices to a global Azure backbone by hand is exactly the kind of maintenance burden the managed model removes. A branch connects to a hub through its VPN gateway as a VPN site, and at scale you do not configure each branch device by hand against the gateway. Virtual WAN integrates with SD-WAN partners so that the partner’s controller and the Virtual WAN hub exchange configuration, and the branch devices are provisioned to connect to the nearest hub automatically. The result is that a fleet of branches connects to the global backbone, reaches Azure workloads in any region, and reaches each other through its, with the branch-to-hub configuration handled by the integration rather than authored device by device.

The pattern engineers report most often here is a wide-area network that has outgrown a manual design. A company with branches in many cities and Azure workloads in several regions can connect every branch to its nearest hub, let the hubs mesh, and have any branch reach any workload and any other branch through the managed backbone. Building that reach by hand would mean a VPN gateway per region, peering and routing to stitch the regions together, and per-branch tunnel configuration maintained as branches change. Virtual WAN delivers the same reachability as a managed service, which is the operational argument for it at wide-area scale. To stand a topology like this up safely before committing production branches, you can build a hub, connect VNets, and wire a site-to-site connection in a sandbox first, and the hands-on Azure labs and command library on VaultBook provide a tested environment and a command library for exactly that kind of Virtual WAN build, so you exercise the routing and the connection behavior before any real branch depends on it.

Hub-to-Hub Connectivity and the Global Backbone

The feature that turns Virtual WAN from a managed regional hub into a global backbone is automatic hub-to-hub connectivity. When you create more than one virtual hub inside a single Virtual WAN, the hubs connect to each other across the Microsoft backbone without you building anything. A spoke on a hub in one region can reach a spoke on a hub in another region, an on-premises site connected to one hub can reach Azure workloads attached to another hub, and the routes that make this work are programmed and maintained by the service. The hubs form a full mesh, so adding a third hub gives every existing hub a path to it automatically rather than requiring you to connect the new region to each existing region by hand.

Compare that with building global reach manually. To connect three regions in a manual hub-spoke you would peer the hub VNets across regions, or stand up hub-to-hub VPN, and then author the routes that let spokes in one region reach spokes in another, maintaining the route tables as the estate grows. Each new region multiplies the connections and the routes you maintain. Virtual WAN’s full mesh and managed inter-hub routing remove that multiplication. The decision boundary this draws is sharp and worth stating plainly: the more regions and the more inter-region routing you need, the more the manual approach costs to build and operate, and the more Virtual WAN’s automation is worth. The article comparing hub-spoke versus Virtual WAN architecture takes that decision apart in detail and names the deciding factors, and the short version is that scale across regions is the single factor that most cleanly tips the choice toward the managed backbone.

There is a subtlety in inter-hub traffic that interacts with routing intent and the secured hub. When traffic crosses from a spoke on one hub to a spoke on another, you decide, through routing intent on each hub, whether that traffic is inspected by a firewall and where. Getting consistent inspection across hubs means configuring routing intent on each hub deliberately, because a hub without the private-traffic policy will pass inter-spoke traffic without inspection even if a neighboring hub inspects its own. The global backbone is uniform in its reachability but only as uniform in its inspection as you make it through per-hub policy, which is the kind of detail that separates a topology that merely connects from one that connects and inspects consistently.

The Configuration That Realizes a Working Backbone

Walk a minimal but realistic build so the abstractions become concrete commands. The order of operations matters, because some resources depend on others existing first. You create the Virtual WAN, then a virtual hub in a region with an address prefix reserved for the hub, then the gateways and connections the hub needs, then the routing and routing intent that govern the traffic. The hub’s address prefix must not overlap with the VNets you intend to connect, and a common early mistake is to reuse an address range that collides with a spoke, which produces routing that does not behave as expected once the connection is made.

# Create the Virtual WAN as the top-level container
az network vwan create \
  --resource-group rg-network \
  --name vwan-global \
  --type Standard \
  --location eastus

# Create a virtual hub in the first region with a dedicated address prefix
az network vhub create \
  --resource-group rg-network \
  --name hub-eastus \
  --vwan vwan-global \
  --address-prefix 10.100.0.0/23 \
  --location eastus

# Connect a spoke VNet to the hub
az network vhub connection create \
  --resource-group rg-network \
  --vhub-name hub-eastus \
  --name conn-spoke-prod \
  --remote-vnet "/subscriptions/<sub>/resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/vnet-prod"

The Standard type matters: a Basic Virtual WAN supports only site-to-site VPN and does not support the full set of features such as hub-to-hub transit, ExpressRoute, and routing intent, so for anything beyond a simple VPN aggregation you create a Standard Virtual WAN. The hub address prefix should be sized with room for the managed components the hub provisions; a prefix that is too small can prevent the hub from deploying the gateways and the firewall it needs, and a /23 or larger is a safe starting point rather than a tight /27 that leaves no room.

Adding hybrid connectivity and inspection follows the same declarative pattern. You create the VPN or ExpressRoute gateway inside it, define the sites or attach the circuit, then enable routing intent once the secured hub’s firewall exists.

# Create a site-to-site VPN gateway inside the hub (scale units, not a SKU)
az network vpn-gateway create \
  --resource-group rg-network \
  --name vpngw-eastus \
  --vhub hub-eastus \
  --location eastus \
  --scale-unit 2

# Verify the effective routes the hub has programmed for a connection
az network vhub get-effective-routes \
  --resource-group rg-network \
  --name hub-eastus \
  --resource-type HubVirtualNetworkConnection \
  --resource-id "/subscriptions/<sub>/resourceGroups/rg-network/providers/Microsoft.Network/virtualHubs/hub-eastus/hubVirtualNetworkConnections/conn-spoke-prod"

That last command is the one you will run most often when something does not route the way you expect, because it shows you the routes the hub has actually programmed for a connection rather than the routes you assume it has. Reading effective routes there is the Virtual WAN equivalent of reading effective routes on a NIC in the manual world, and it is the first diagnostic step for almost every reachability problem.

Failure Modes and the Diagnostics That Expose Them

Virtual WAN fails in a small number of recognizable ways, and because the routing is managed, the diagnostics live there rather than scattered across spoke route tables. Learn the handful of failure modes and the command or blade that confirms each, and most incidents resolve quickly instead of turning into an afternoon of guessing.

The first and most common failure is the bypass: traffic you expected to be inspected reaches its destination without passing the firewall. The cause is almost always a routing intent policy that is not enabled for the traffic class in question, most often the private-traffic policy left off while only the internet policy is on. The confirming check is to read the effective routes on the relevant connection and look at the next hop for the destination prefix. If the next hop is the destination’s connection rather than the firewall, the traffic is not being sent to inspection, and the fix is to enable the private-traffic routing intent policy on the hub. The symptom is a security gap rather than a connectivity error, which is why it is dangerous: nothing breaks, so nothing alerts, and only an audit of the effective routes or the firewall logs reveals that lateral traffic never touched the firewall.

The second failure is the overlap: a hub address prefix or a spoke address space that collides with another network in the topology. Overlapping address space produces routing that silently prefers the wrong destination or fails to install a route at all, because longest-prefix matching cannot disambiguate two identical or overlapping prefixes cleanly. The confirming check is to inventory the address spaces of it and every connected VNet and on-premises range and look for overlap. The fix is to renumber the offending network, which is painful, which is why getting the address plan right before you build is worth the up-front effort. The hub prefix in particular is easy to overlook because it does not host your workloads, but it participates in routing and must be unique.

The third failure is the propagation gap: a connection cannot reach another connection because the routes do not propagate into the route table the source connection is associated with. This is the association-and-propagation model biting you when a custom route table is involved. The confirming check is to read the source connection’s associated route table and verify that the destination’s routes propagate into it. The fix is to adjust association or propagation so the routes reach the table the source consults. When everything is on the Default table this failure does not occur, which is why the default flat topology just works; it appears once you introduce segmentation and is the price of the isolation you asked for.

How Do I Diagnose Traffic That Will Not Cross Between Hubs?

Inter-hub reachability failures have their own signature. When a spoke on one hub cannot reach a spoke on another, the first question is whether the Virtual WAN is Standard, because Basic does not support hub-to-hub transit at all, and a topology that worked within a region but fails across regions on a Basic WAN is failing by design rather than by misconfiguration. Assuming Standard, the next check is the effective routes on the source connection: do they include the remote spoke’s prefix with a next hop that leads toward the remote hub? If the remote prefix is absent from the effective routes, the routing is not propagating across the hubs the way you expect, and the cause is usually a routing or routing intent configuration on one of its that drops or fails to advertise the prefix. Reading effective routes on both ends localizes the break to the hub that is not advertising or not learning the prefix.

The general diagnostic discipline for Virtual WAN is to stop debugging at the spoke and start debugging there. In the manual world you read the effective routes on a NIC and the route tables on a subnet. In Virtual WAN you read the effective routes the hub has programmed for a connection and the association and propagation of that connection’s route tables. The same packet-level reasoning applies, longest-prefix match against the effective routes, but the routes you read are the ones the managed network computed, and the levers you turn to change them are association, propagation, and routing intent rather than hand-authored user-defined routes. Network Watcher’s connection-oriented diagnostics still help you confirm whether a path is open end to end, and the firewall’s own logs are where you confirm whether a packet reached inspection and was allowed or denied, which is the other half of the bypass diagnosis. For structured practice running these diagnoses against seeded failure scenarios rather than waiting for a real incident, the scenario-based troubleshooting drills on ReportMedic let you reproduce a bypass or a propagation gap and walk the confirming checks until the method is automatic.

What Causes a Spoke to Lose Connectivity Right After I Change Routing Intent?

Changing routing intent reprograms routes across every connection on the hub, and a connectivity change immediately after a routing intent edit is the routes doing exactly what you told them to. If you enable the internet policy and spokes lose internet access, the firewall is now in the path and lacks an allow rule, as covered earlier. If you enable the private policy and spokes lose reach to on-premises, the same logic applies to private traffic: it is now routed through the firewall, and the firewall must permit it. The diagnostic instinct to build is that a connectivity change coincident with a routing intent change is not a bug in Virtual WAN; it is the policy taking effect, and the resolution lives in the firewall rules that must now allow the traffic the policy is funneling through inspection. Confirm by reading the firewall logs for denied traffic that matches the broken flow, then author the allow rule. The mistake to avoid is rolling back the routing intent in a panic, because that removes the inspection you wanted rather than fixing the rule that was actually missing.

How Virtual WAN Interacts with the Rest of Your Network

Virtual WAN does not exist in isolation, and the way it meets the networking you already run determines how cleanly it slots into an estate. The most important interaction is with name resolution, because reachability without resolution is useless. Virtual WAN routes packets but does not resolve names, so your DNS design continues to live in your VNets and your private DNS zones, and a spoke connected to a hub still resolves names the way any VNet does. If you run private endpoints and private DNS zones, those zones must still be linked to the VNets that need them, and the hub does not change that. A frequent confusion is expecting the hub to centralize DNS the way it centralizes routing; it does not, and DNS remains a separate concern you design alongside the connectivity rather than something the hub absorbs.

The interaction with NSGs is similarly clean and worth stating because it surprises people. NSGs live on subnets and NICs in your spoke VNets, exactly as they do without Virtual WAN, and they continue to filter traffic at the spoke regardless of whthere routes. A packet ththere happily routes to a spoke can still be dropped by an NSG on the destination subnet, and a connectivity failure that survives a clean effective-routes check there is often an NSG denying the flow at the spoke. The hub’s routing and the spoke’s NSG filtering are independent layers, and a complete diagnosis checks both: the hub answers “is there a route,” and the NSG answers “is the packet allowed at the endpoint.” Treating them as one layer is a recipe for staring at the routing while the NSG is the actual culprit.

The interaction with the firewall in a secured hub is the one that ties routing and security together, and it is where the two halves of a Virtual WAN incident usually meet. A flow that the routing sends to the firewall and the firewall denies looks, from the spoke, like a routing failure, because the traffic does not arrive. The discipline is to recognize that once routing intent is on, a dropped flow has two possible owners: the routing, which decides whether the firewall is in the path, and the firewall rules, which decide whether the packet is allowed once it arrives. Reading the effective routes tells you whether the firewall is in the path; reading the firewall logs tells you whether the firewall allowed the packet. Together they localize every secured-hub flow problem to one of those two owners, which is the whole diagnostic surface for inspected traffic.

Designing a Virtual WAN for Production

Designing well comes down to deciding the things that are painful to change later and leaving flexible the things that are cheap to change. The address plan is the expensive one. Choose hub prefixes and spoke address spaces that do not overlap and that leave the hubs room to grow their managed components, and treat the address plan as a one-time decision you make carefully rather than something you adjust on the fly, because renumbering a connected network in production is the kind of change that schedules itself for a weekend. Reserve hub prefixes from a range you keep distinct from workload ranges so ththeres never collide with a spoke as the estate expands.

Decide your inspection posture early and express it through routing intent consistently across hubs. If the requirement is that all internet egress is inspected, enable the internet policy on every hub and confirm the firewall rules exist before you cut traffic over, so the first thing the policy does is not break egress. If the requirement is that east-west traffic is inspected, enable the private policy and accept that you have now put the firewall in the path of lateral traffic, with the throughput and the rule maintenance that implies. The thing to avoid is an inconsistent posture where some hubs inspect and others do not, because uniform reachability with non-uniform inspection is a security gap that hides in the topology and surfaces only in an audit.

Segment with route tables only where you have a real isolation requirement, and resist the urge to build elaborate custom-route-table schemes for their own sake. The Default route table gives you a flat reachable topology that is easy to reason about, and every custom route table you add is another association-and-propagation relationship you maintain and another place a propagation gap can hide. Reach for custom tables when you must keep two groups of spokes from reaching each other or must give a group a different path to on-premises, and stay on the Default table when you do not, because the simplest topology that meets the requirement is the one you can debug at three in the morning. Capture the whole design as infrastructure as code so ththere, the connections, the routing intent, and the firewall policy are versioned and reproducible rather than clicked together in the portal, since a managed backbone is exactly the kind of foundational network where drift between the deployed state and the intended state is most dangerous.

When Is Virtual WAN Overkill?

A managed backbone is the wrong tool for a small estate, and the discipline of naming when not to use something is as valuable as knowing when to use it. If you run a single region with a handful of spokes and one on-premises connection, a hand-built hub-spoke is simpler, cheaper, and gives you more direct control, and the managed routing you would gain from Virtual WAN solves a maintenance problem you do not have at that scale. The cost of the managed network and its components is real, and at small scale you pay for automation you do not need. Virtual WAN earns its place when the count of regions, hubs, branches, and inter-region routes grows past what a small team can build and maintain by hand without mistakes, and below that threshold the manual design is not a compromise but the correct choice.

The Two Opposite Mistakes, and the Decision Rule Between Them

Engineers approaching Virtual WAN tend to fail in one of two opposite directions, and naming both is the fastest way to avoid each. The first mistake is adopting Virtual WAN expecting a fundamentally new capability. This engineer migrates to Virtual WAN believing it will do something a manual hub-spoke could never do, then spends weeks frustrated that the managed routing is more opinionated and the control surface narrower than the network they left. They reach for knobs that do not exist because the knob they want belongs to the hand-built world, and they conclude Virtual WAN is limited when in fact it is doing precisely what a managed hub-spoke is supposed to do. The cure is the managed-hub rule: Virtual WAN buys you operation of a topology you already understand, not a new topology, so judge it on whether it removes operational burden, not on whether it grants new powers.

The second mistake is the mirror image: hand-building a hub-spoke at a scale where Virtual WAN would plainly be simpler. This engineer takes pride in the manual design, keeps adding regions and branches and stitching them together by hand, and ends up maintaining a sprawl of peerings, gateways, and route tables that grows more fragile with every addition. They are paying, in operational labor and in the risk of a forgotten route, for control they do not actually exercise, and the route sprawl they maintain is exactly the thing routing intent was built to collapse. The cure is to count the regions, hubs, branches, and inter-region routes honestly, and to recognize that past a certain scale the managed backbone is not a loss of control but a removal of toil that was never adding value.

The decision rule that sits between these mistakes is scale, and specifically the scale of inter-region and multi-branch routing. State it as a branch. If you run one region with a few spokes and one or two hybrid connections, build the hub-spoke by hand and keep the control; Virtual WAN is overkill. If you run several regions, many branches, or a wide-area network where the inter-region routing and the per-branch tunnels are growing faster than your team can maintain them correctly, adopt Virtual WAN and trade the granular control for managed routing and automatic global transit. The deciding factor is not a feature either design has and the other lacks, because by the managed-hub rule they have the same capabilities; the deciding factor is the operational cost of building and maintaining the topology at your scale. The hub-spoke versus Virtual WAN comparison works that decision through case by case, and its verdict and this one agree: choose by the cost of operation at your scale, not by a capability difference that does not exist.

A Worked Decision: When the Manual Hub Tips Over

Make the rule concrete with a scenario engineers actually report. A company starts with one region, a hub VNet, four spokes, and a site-to-site VPN to headquarters, all built by hand and working well. Over two years they add a second region for resilience, a third for a new market, a dozen branch offices as they grow, and ExpressRoute for the data-heavy workloads. Each addition was a reasonable manual step, but the accumulated topology is now a hub VNet per region peered across regions, route tables on dozens of subnets steering inter-region and inter-spoke traffic, a VPN gateway per region with per-branch tunnel configuration, and a central firewall in each region fed by user-defined routes that someone has to keep in sync. A single new spoke now means touching route tables in three regions, and a forgotten entry means a flow that either fails or bypasses inspection.

This is the tipping point the decision rule predicts. The capabilities are all present in the manual design; nothing is impossible. What has become unsustainable is the operation: the route sprawl, the per-branch configuration, and the cross-region maintenance have outgrown what the team can do reliably. Migrating to Virtual WAN replaces the hand-peered hubs with managed hubs that mesh automatically, replaces the per-spoke firewall routes with routing intent declared once per hub, and replaces the per-branch tunnel configuration with SD-WAN integration that provisions branches to the nearest hub. The company gains no new reachability; every flow that worked before still works. What they gain is that a new spoke is now one connection, a new region is one hub that meshes with the rest automatically, and consistent inspection is a policy rather than a route audit. That is the managed-hub rule paying off at exactly the scale it was designed for.

Migrating from a Hand-Built Hub-Spoke

When the decision tips toward Virtual WAN, the migration is a routing exercise more than a rebuild, because the spokes and the on-premises connections largely stay where they are. The spokes are ordinary VNets, and moving a spoke from a manual hub to a managed hub means removing its peering to the old hub VNet and creating a connection to the virtual hub, then letting the hub program the routes that the manual route tables used to carry. The on-premises connections move by recreating the VPN sites or attaching the ExpressRoute circuit to its gateway rather than to a standalone gateway. The work is methodical rather than clever, and it is best done region by region with careful attention to the routes during the cutover so that traffic is never left without a path.

The trap during migration is running the two routing models against each other. While a spoke still has manual user-defined routes pointing at the old hub’s firewall and is also connected to a virtual hub that programs its own routes through routing intent, the two can conflict and produce a flow that takes neither path you intended. The clean approach is to migrate a spoke fully, removing the manual routes as you add the connection and letting routing intent become the single authority for that spoke’s inspected traffic, rather than leaving both in place and hoping longest-prefix matching resolves them the way you want. Plan the cutover so each spoke transitions from fully manual to fully managed in one step, validate the effective routes there immediately after, and confirm inspected flows hit the firewall before moving to the next spoke. Building and rehearsing that cutover sequence in a sandbox before touching production is exactly the kind of preparation the hands-on labs are for, and rehearsing the failure modes as drills first means the production cutover is a repeat of something you have already done rather than a first attempt under pressure.

How the Hub Learns and Prefers Hybrid Routes

The routing story so far has focused on the VNets and the routing intent, but the hybrid side, where on-premises networks meet the hub over VPN and ExpressRoute, has its own behavior worth understanding because it is where production incidents about reaching on-premises systems usually originate. On-premises prefixes do not arrive inside it by magic. They are learned over BGP from your VPN devices and your ExpressRoute circuit, and the hub propagates those learned prefixes into its route tables so that spokes can reach on-premises ranges. The chain is therefore your device advertising a prefix over BGP, the hub gateway learning it, the hub propagating it into the route tables, and the spoke receiving it as an effective route. A break anywhere in that chain produces a spoke that cannot reach on-premises, and the diagnosis walks the chain from the device outward.

The interesting case is when the same on-premises network is reachable over both ExpressRoute and VPN, which engineers configure deliberately for resilience so that a failure of one path falls back to the other. The hub must then decide which path to prefer, and the preference follows the routing logic that weighs the available paths rather than a coin flip. The practical consequence is that you should know which path your traffic prefers under normal conditions and confirm that the failover path actually carries traffic when the preferred path is down, because a redundant design that has never been tested often hides a misconfiguration that only surfaces during the failure you built the redundancy to survive. Confirm the steady-state preference by reading the effective routes and seeing which next hop carries the on-premises prefix, then validate failover in a controlled test rather than discovering its behavior during a real outage.

Route advertisement in the other direction matters too. The hub advertises Azure prefixes back to on-premises over the same BGP sessions, so your on-premises routers learn how to reach the VNets and the address ranges behind the hub. If on-premises cannot reach a spoke even though the spoke can reach on-premises, the asymmetry points at the advertisement from the hub to on-premises rather than at the spoke’s routing, because reachability requires routes in both directions and a one-way failure is almost always a missing or filtered advertisement on the return path. Checking what your on-premises routers have actually learned from the hub is the confirming step for that class of problem, and it is the half of the diagnosis engineers forget when they fixate on the Azure side of the path.

What Happens to Routing When a Gateway or a Link Fails?

Resilience in Virtual WAN comes from the managed gateways and the redundant links you configure, and understanding the failure behavior is part of designing a backbone you can trust. The VPN and ExpressRoute gateways in a hub are sized by scale unit, and a higher scale unit provides both more throughput and the redundancy that keeps connectivity alive through the loss of an underlying instance. When a link fails, BGP withdraws the routes that depended on it, the hub recomputes, and traffic shifts to a surviving path if one exists. The design responsibility on your side is to ensure a surviving path exists: a single VPN tunnel with no second tunnel and no ExpressRoute fallback has nothing to fail over to, and the managed routing cannot conjure a path that was never configured. Build the redundancy you need at the connection level, and the managed routing will use it; omit it, and the managed routing will faithfully report that there is nowhere for the traffic to go.

The lesson that ties this to the managed-hub rule is that Virtual WAN automates the routing response to a failure but not the existence of the redundant paths themselves. You still decide whether a site has two tunnels, whether ExpressRoute has a backup VPN, and whether a workload spans regions so a hub failure does not take it offline. Those are the same resilience decisions you make in a manual hub-spoke. What the managed backbone removes is the labor of authoring the failover routing by hand, because BGP and its recomputation handle the route shift once the paths exist. Design the redundancy deliberately, test the failover before you depend on it, and let the managed routing do the part it is good at, which is reacting to the failure faster and more consistently than a human editing route tables under pressure.

Operational Visibility and Monitoring

A managed network you cannot see into is a liability, so knowing where Virtual WAN exposes its state is part of operating it well. The effective-routes view is the primary window into the routing, and you read it per connection to see exactly whthere has programmed, which is the single most valuable operational habit because it turns routing questions from speculation into observation. Beyond routing, the gateways and the hub emit metrics about throughput, tunnel state, and BGP peering health, and you wire those into your monitoring so that a tunnel flapping or a gateway approaching its scale-unit throughput surfaces as an alert rather than as a user complaint. The firewall in a secured hub emits its own logs, and those logs are where you confirm whether a flow reached inspection and was allowed or denied, which is the inspection half of every secured-hub diagnosis.

The monitoring posture to aim for is one where the three layers of a Virtual WAN flow are each observable independently. The routing layer is observable through effective routes and its route tables. The connectivity layer, meaning the tunnels and circuits and their BGP sessions, is observable through gateway metrics and BGP state. The inspection layer is observable through firewall logs. When an incident arrives, you want to localize it to one of those three layers quickly, and you can only do that if each is instrumented and visible. A common operational gap is monitoring the workloads but not the network underneath them, so that a degraded tunnel or a saturated gateway manifests only as application latency with no network signal, and the team spends the incident looking at the application while the network is the cause. Instrument the network layers explicitly so the signal points at the real owner of the problem.

Treat the whole configuration as code and the whole topology as something you can describe, deploy, and inspect repeatably, because a managed backbone is foundational and drift in a foundation is the most dangerous kind. When the hub, the connections, the routing intent, and the firewall policy all live in version-controlled templates, you can answer what the network is supposed to be by reading the source rather than clicking through blades, and you can detect drift by comparing the deployed state to the intended state. That discipline pays off most during an incident, when the difference between knowing the intended configuration and reconstructing it from the portal under pressure is the difference between a short outage and a long one. The point of a managed network is to reduce toil, and capturing it as code extends that reduction from the day-to-day routing to the audit, the change review, and the recovery.

Cost and the Shape of the Trade

The managed components of Virtual WAN are not free, and the cost is part of the honest decision because the operational savings have to outweigh the spend for the trade to make sense. You pay for the hub and its data processing, for the gateways and their scale units, and for the firewall in a secured hub, and those costs accrue per hub and per region. At small scale this is the argument against Virtual WAN: a single region with a few spokes pays for managed automation that a hand-built design would not require, and the manual hub-spoke is cheaper precisely because you are doing the operational work the managed service would charge you to do for you. The cost curve and the operational-savings curve cross at scale, which is the same crossover the decision rule names. Below it you pay for automation you do not need; above it the automation saves more in operational labor and reduced error than it costs in managed components.

The subtler cost is the one that does not appear on the invoice: the cost of mistakes in a hand-built topology that has outgrown the team. A forgotten route that bypasses inspection, a misconfigured failover that does not trigger, a peering left unbuilt after a new region was added, each of these has a cost in incidents, in security exposure, and in the time spent diagnosing problems that a managed routing model would not have produced. When you weigh Virtual WAN against a manual design at scale, count that hidden cost alongside the invoice, because the route sprawl of a large hand-built estate generates exactly the kind of intermittent, hard-to-diagnose problems that consume far more engineering time than their apparent size suggests. The managed backbone trades a predictable invoice for the removal of that unpredictable toil, and at the right scale that is a trade worth making with eyes open about both sides of the ledger.

A last operational note ties the monitoring discipline back to the design. A managed backbone rewards teams that treat its configuration as a living document rather than a one-time build. Review the routing policy, the segmentation tables, and the firewall rules on a schedule, not only after an incident, because a global network accretes connections and exceptions over time, and an unreviewed policy slowly drifts away from what anyone intended. The same versioned templates that let you deploy the network let you audit it, diff it against last quarter, and prove to a reviewer that the intended posture is the deployed posture. That habit converts a sprawling estate into something a new engineer can read and reason about in an afternoon, which is the real payoff of choosing automation over hand-built complexity.

Remote User Access Through the Hub

Point-to-site connectivity is the part of Virtual WAN that brings individual users, rather than whole sites, onto the network, and it is increasingly the reason organizations adopt the managed backbone in the first place. The VPN gateway in a hub can terminate point-to-site connections from remote users, authenticate them, assign them addresses from a configured pool, and route them into the topology so that a remote engineer reaches the same Azure workloads and on-premises systems a branch office would. Because the hubs mesh globally, a user connecting to the nearest hub reaches workloads in any region through the backbone, which is a meaningful improvement over a design where remote users connect to a single gateway in one region and traverse the network from there. The address pool you assign to point-to-site users must be planned alongside the rest of the address space so it does not overlap, because a user address range that collides with a spoke produces the same routing confusion any overlap does.

Authentication for point-to-site is where the design decisions live, and the choice shapes both security and operability. The gateway supports certificate-based authentication and integration with an identity provider, and the right choice depends on how your organization already manages user identity and what posture you need for remote access. Routing for these users follows the same managed model as everything else: once a user is connected and assigned an address, its routing determines what they can reach, and routing intent decides whether their traffic is inspected by the firewall. A remote user whose traffic should be inspected is covered by the same routing intent policy that covers the spokes, which is the consistency the managed model buys: you do not configure inspection separately for users and for workloads, because both are connections on the hub governed by the same per-hub policy. Plan remote access as another class of connection rather than a bolt-on, and it inherits the routing and inspection you already designed.

The operational benefit at scale mirrors the branch story. Connecting remote users to a global backbone by hand, with a gateway per region and routing to stitch the regions together, is the same maintenance burden that branches create, and the managed networks remove it the same way. A workforce spread across regions connects to the nearest hub, reaches what it needs through the mesh, and is inspected by the same policy as the rest of the network, with the per-region gateway sprawl handled by the managed model. For a hands-on feel of how a point-to-site configuration behaves before you roll it out to a workforce, building the gateway, the pool, and the authentication in a sandbox and connecting a test client is the kind of exercise that turns the documentation into intuition, and rehearsing it removes the surprises that otherwise surface on the day real users depend on it.

Segmentation Patterns That Actually Earn Their Complexity

Custom route tables are powerful and dangerous in the same breath, because every table you add buys isolation at the cost of another association-and-propagation relationship that can develop a gap. The discipline is to add them only where a real isolation requirement exists and to keep the scheme as simple as the requirement allows, because a segmentation design you cannot reason about quickly is one you will misconfigure under pressure. The most common legitimate pattern is environment isolation: production spokes that must not reach development spokes, and development spokes that must reach shared services but not production. You realize this with a route table per environment, associating each environment’s spokes with its own table and controlling propagation so the tables learn only the routes the policy permits, and the result is two routing domains in one hub with the boundary enforced by the routing rather than by hope.

A second legitimate pattern is the shared-services domain, where a set of spokes hosting shared resources such as identity, monitoring, or a private DNS resolver must be reachable from every environment while the environments remain isolated from each other. You build this by propagating the shared-services routes into every environment’s table while keeping the environment tables from propagating into each other, so each environment reaches the shared services and on-premises but not the other environments. This is the kind of asymmetric reachability that is genuinely tedious to build and audit by hand in a manual hub-spoke, with route tables on every subnet carrying exactly the right entries, and it is where the managed association-and-propagation model earns its keep by expressing the policy as a small number of relationships rather than a large number of routes.

The failure mode to watch in any segmentation design is the propagation gap, where a connection cannot reach another because the routes never propagate into the table the source consults. When everything sits on the Default table this never happens, which is the argument for staying flat until you have a reason not to. Once you segment, every reachability problem starts with the question of whether the source’s associated table actually learned the destination’s routes, and the confirming check is to read that table and verify the propagation. Build the simplest segmentation that meets the requirement, document which tables exist and what each is for, and capture the whole scheme as code so the intended reachability is readable rather than reconstructed, because a segmentation design that lives only in someone’s memory is one outage away from being relearned the hard way. The isolation is worth having when the requirement is real, and the complexity is worth avoiding when it is not, and telling those two cases apart is the whole skill.

The Verdict

Azure Virtual WAN is a managed hub-and-spoke and a global connectivity backbone, and the most useful thing you can carry out of this article is the managed-hub rule that frames it: every component of Virtual WAN has a manual equivalent, so the service adds no capability a hand-built hub-spoke lacks, only the managed construction and maintenance of the same topology across many regions, branches, and connections. That single sentence resolves both the frustration of the engineer who expected new powers and the toil of the engineer who keeps building by hand past the point where it pays. Routing intent is the clearest expression of the trade: it collapses a pile of hand-maintained user-defined routes into one declarative policy per hub, and the secured hub integrates the firewall into that managed routing so inspection follows from intent rather than from a route audit. The decision to adopt Virtual WAN is therefore an operational one, decided by the cost of building and maintaining your topology at your scale, and the deciding factor is the count of regions, hubs, and branches rather than a feature checklist. Build the hub-spoke by hand while your estate is small and the control is worth the labor, and move to the managed backbone when the inter-region routing and the per-branch maintenance outgrow what your team can keep correct, because that crossover is the whole point of the service and the moment it earns its place in your network.

Frequently Asked Questions

Q: What is Azure Virtual WAN and what does it actually manage for me?

Azure Virtual WAN is a managed hub-and-spoke network and a global connectivity backbone. You declare a virtual hub in a region and attach your VNets, VPN sites, ExpressRoute circuits, and branches to it, and Microsoft provisions the hub, computes the routing, and maintains the transit relationships between everything connected. What it manages is the construction and the upkeep of the topology: the hub itself, the gateways inside it, the routes that let spokes reach each other and reach on-premises, and the automatic full mesh between hubs in different regions. What it does not manage is your workloads, your VNet address spaces, your NSGs, or your DNS, which remain ordinary resources you own. The clean way to hold it in mind is a managed control plane over the same data-plane primitives you already understand, so that the topology you would have built and routed by hand is built and routed by the service instead.

Q: How is Azure Virtual WAN different from a hand-built hub-spoke network?

By capability they are the same, which is the surprising and useful answer. A hand-built hub-spoke can do everything Virtual WAN does: spoke-to-spoke transit through peering and route tables, central inspection through a firewall and user-defined routes, and cross-region reach through inter-region peering or hub-to-hub VPN. Virtual WAN does not invent any of those. The difference is entirely operational. In the manual design you build and maintain every peering, gateway, route table, and route by hand, and that labor grows with every region, spoke, and branch you add. In Virtual WAN the service builds and maintains those constructs from the associations and policies you declare, and it keeps the routing correct as the topology changes. So the right comparison is not feature against feature but operational cost against operational cost, and the managed backbone wins as scale grows and loses to a simpler manual design when the estate is small.

Q: What connects to a Virtual WAN hub?

Four kinds of things attach to a hub, plus other hubs. VNet connections bring your workload networks in, giving each spoke transit to everything else on the topology. A VPN gateway inside it terminates site-to-site tunnels from on-premises and branch offices and point-to-site connections from remote users. An ExpressRoute gateway inside it attaches an ExpressRoute circuit for private, high-bandwidth connectivity that stays off the public internet. SD-WAN and branch integration connects fleets of branch devices to the nearest hub. On top of those, the hubs within a single Virtual WAN connect to each other automatically in a full mesh, so any connection on any hub can reach any connection on any other hub. Each attachment is a managed version of a primitive you would otherwise deploy and route by hand, which is why a single connection object replaces the peering and route tables the manual equivalent would require.

Q: How does routing intent work in Azure Virtual WAN?

Routing intent is a per-hub policy that declares which traffic classes should be sent through its firewall, and the service then programs every connection with the routes that enforce it. There are two independent policies. The internet-traffic policy steers internet-bound traffic, the 0.0.0.0/0 default, through the secured hub’s firewall. The private-traffic policy steers traffic between spokes and to and from on-premises through the firewall as well. You enable one, the other, or both, and the managed routing computes and propagates the routes across all connections and keeps them correct as connections change. The point is that it replaces the pile of user-defined routes you would otherwise author on every spoke subnet to force traffic to a firewall. Instead of maintaining per-spoke routes and auditing for a forgotten entry, you declare the intent once per hub and let the platform write and maintain the routes that realize it.

Q: What is a secured virtual hub and what does it inspect?

A secured virtual hub is a virtual hub with a managed firewall inside it, either Azure Firewall or a supported partner firewall. It inspects exactly the traffic that routing intent sends to it and nothing else. If you enable only the internet-traffic policy, the firewall sees internet egress and its return traffic but does not see spoke-to-spoke traffic. If you also enable the private-traffic policy, lateral traffic between spokes and traffic to on-premises is pulled through the firewall as well. The inspection scope is therefore a direct consequence of which routing intent policies you turned on, which is the detail engineers most often get wrong when they assume a firewall inside it means everything is inspected. The secured hub matters as a distinct idea because the firewall is integrated with the managed routing, so declaring an inspection intent both gives you a firewall and wires the traffic to it without you authoring the routes that put it in the path.

Q: When should I choose Virtual WAN over a manual hub-spoke?

Choose by the operational cost of your topology at your scale, because the two designs have the same capabilities. Stay with a hand-built hub-spoke when you run a single region with a handful of spokes and one or two hybrid connections, because the manual design is simpler, cheaper, and gives you more direct control, and the managed routing solves a maintenance problem you do not yet have. Move to Virtual WAN when you run several regions, many branches, or a wide-area network where inter-region routing and per-branch tunnel configuration are growing faster than your team can maintain correctly. The deciding factor is the count of regions, hubs, branches, and inter-region routes, not a feature either design has and the other lacks. The crossover point is where the route sprawl and the cross-region maintenance of the manual design start producing mistakes, and that is precisely the toil the managed backbone removes.

Q: How do branch offices and SD-WAN connect to Virtual WAN?

A branch connects to a hub as a VPN site through its VPN gateway, and at scale you do not configure each branch device by hand. Virtual WAN integrates with SD-WAN partners so the partner’s controller and the hub exchange configuration and the branch devices are provisioned to connect to the nearest hub automatically. The result is that a fleet of branches reaches Azure workloads in any region and reaches each other through the meshed hubs, with the branch-to-hub setup handled by the integration rather than authored device by device. This is one of the patterns Virtual WAN was specifically built for, because connecting many branches to a global backbone by hand, with a gateway per region and per-branch tunnel configuration maintained as branches change, is exactly the maintenance burden the managed model removes. The reachability is the same as a hand-built wide-area network; what changes is that the provisioning and the upkeep are managed.

Q: Why did my spokes lose internet access after I enabled routing intent?

Because routing intent did exactly what you asked. Before you enabled the internet-traffic policy, spokes reached the internet through Azure’s default outbound path. After you enabled it, the hub programmed a 0.0.0.0/0 route on the connections that sends internet traffic to the secured hub’s firewall, and if the firewall has no rule allowing that egress, it drops the traffic. The fix is not to disable routing intent. The fix is to recognize you have centralized internet egress through a firewall, which is what the policy is for, and to author the firewall rules that permit the egress your workloads need. Confirm the diagnosis by reading the firewall logs for the denied traffic that matches the broken flow rather than hunting for a missing route, because the route is present and correct; the missing piece is the allow rule on the firewall the route now points at.

Q: What is the difference between association and propagation in Virtual WAN routing?

Association and propagation are the two verbs that govern how a connection relates to a route table, and keeping them straight is the most useful piece of Virtual WAN routing knowledge. Association answers which route table a connection uses to make its forwarding decisions; a connection is associated with exactly one table and consults it to decide where to send a packet. Propagation answers which route tables learn the routes a connection advertises; a connection propagates to one or more tables, and any connection associated with a table that received the propagation can therefore reach it. By default every connection associates with and propagates to the Default route table, which is why a fresh topology is flat and fully reachable. Segmentation comes from changing these: associate a group of spokes with a custom table and control what propagates into it, and you have built an isolated routing domain without authoring a single route by hand.

Q: Does Virtual WAN handle DNS or do I still manage name resolution myself?

You still manage name resolution yourself. Virtual WAN routes packets but does not resolve names, so your DNS design continues to live in your VNets and your private DNS zones exactly as it does without Virtual WAN. A spoke connected to a hub resolves names the way any VNet does, and if you run private endpoints with private DNS zones, those zones must still be linked to the VNets that need them. A frequent confusion is expecting the hub to centralize DNS the way it centralizes routing, and it does not. The hub is a routing and connectivity construct, not a resolution construct. Design your DNS alongside the connectivity rather than assuming the managed network absorbs it, because a topology with perfect routing and broken resolution is still broken, and the resolution layer is entirely your responsibility regardless of how the hub routes the packets.

Q: Do NSGs still apply to traffic that flows through a Virtual WAN hub?

Yes, and they apply independently of its routing. NSGs live on subnets and NICs in your spoke VNets and continue to filter traffic at the spoke regardless of whthere routes. A packet the hub happily routes to a spoke can still be dropped by an NSG on the destination subnet, so a connectivity failure that survives a clean effective-routes check there is often an NSG denying the flow at the endpoint. The hub’s routing and the spoke’s NSG filtering are independent layers: the hub answers whether a route exists, and the NSG answers whether the packet is allowed once it arrives. A complete diagnosis checks both, and treating them as a single layer leads to staring at routing while an NSG is the real culprit. Keep your NSG strategy as you would in any VNet design, because Virtual WAN changes how packets are routed, not whether your endpoint filtering applies.

Q: What is the difference between a Basic and a Standard Virtual WAN?

The type determines which features the Virtual WAN supports, and it is a choice you make at creation that shapes everything after. A Basic Virtual WAN supports only site-to-site VPN and is suitable for simple VPN aggregation where you just need branches to reach Azure over encrypted tunnels. It does not support hub-to-hub transit, ExpressRoute, or routing intent. A Standard Virtual WAN supports the full feature set: the automatic full mesh between hubs across regions, ExpressRoute attachment, secured hubs, and routing intent. For anything beyond simple VPN aggregation, you create a Standard Virtual WAN. A common symptom of the wrong choice is a topology that works within a single region but fails across regions, which on a Basic WAN is failing by design because hub-to-hub transit is unsupported rather than misconfigured. Decide the type by the features you need, and default to Standard for any multi-region or inspected topology.

Q: How do I size the address prefix for a virtual hub?

Reserve a prefix that does not overlap with any VNet or on-premises range you intend to connect, and leave room for the managed components the hub provisions. A prefix that is too small can prevent the hub from deploying the gateways and firewall it needs, so a /23 or larger is a safe starting point rather than a tight /27. The hub prefix is easy to overlook because it does not host your workloads, but it participates in routing and must be unique across the topology, and an overlap here produces routing that silently prefers the wrong destination or fails to install a route. Trethere prefix as part of a deliberate address plan you decide once and carefully, keeping hub ranges distinct from workload ranges, because renumbering a hub or a connected network in production is the kind of change that schedules itself for a maintenance window and is far cheaper to avoid than to perform.

Q: How do I diagnose traffic that will not route correctly through a Virtual WAN hub?

Stop debugging at the spoke and start there, because the routing is managed there. The first command to run is the one that shows the effective routes the hub has programmed for a connection, which is the Virtual WAN equivalent of reading effective routes on a NIC. Look at the next hop for the destination prefix: if it points at the destination’s connection when you expected the firewall, your routing intent is not covering that traffic class; if the destination prefix is absent entirely, the routes are not propagating into the table the source connection is associated with. From there, check the association and propagation of the route tables involved to find a propagation gap, and check the firewall logs to see whether a packet reached inspection and was allowed or denied. Reading effective routes there plus the firewall logs together localizes almost every reachability or inspection problem to either the routing or the firewall rules.

Q: Why does traffic between two spokes skip the firewall even though I have a secured hub?

Because a firewall inside it does not mean everything is inspected; the routing intent decides what reaches the firewall. If you enabled only the internet-traffic policy, spoke-to-spoke traffic flows directly through its routing without touching the firewall, because nothing is steering east-west traffic to inspection. The private-traffic routing intent policy is what pulls spoke-to-spoke, spoke-to-branch, and spoke-to-on-premises traffic through the firewall. Confirm the gap by reading the effective routes on a spoke connection and checking the next hop for the other spoke’s prefix; if it points at the spoke rather than the firewall, the traffic is bypassing inspection. The fix is to enable the private-traffic policy on the hub. This is a dangerous failure because nothing breaks when lateral traffic bypasses the firewall, so no alert fires, and only an audit of the effective routes or the firewall logs reveals that east-west traffic was never inspected.

Q: Can I run Azure Firewall and a third-party firewall in the same Virtual WAN?

The secured hub model lets you place a managed firewall inside a hub, and the supported options include Azure Firewall and certain security partner firewalls, with the specific partner support being something to verify against the current official list because the supported integrations change over time. Within a single hub you choose the firewall that becomes the secured-hub inspection point for the traffic routing intent sends to it. Across a multi-hub topology you make that choice per hub, which means you can have different hubs configured differently, though a consistent inspection posture is usually what you want so that reachability and inspection are uniform across the backbone. The deciding factors are the feature set you need from the firewall, the rule management model your team already operates, and whether you have an existing investment in a partner product. Confirm the current partner support and the feature parity for your scenario against the official documentation before committing, since these integrations evolve.

Q: How does routing intent interact with user-defined routes I have already written?

Routing intent is opinionated and largely takes over the routing decision for the traffic classes it covers, so you generally stop hand-authoring competing user-defined routes for those destinations. When you enable a policy, the hub programs the connections with the routes that enforce it, and those become the authority for that traffic. If you find yourself wanting to write a 0.0.0.0/0 route on a spoke to push internet traffic to the firewall, the internet routing intent policy is the managed way to express exactly that, and reaching for the manual route is a sign you are still thinking in the hand-built model. You still own intra-VNet route tables and anything the hub does not govern, and where a specific destination needs a different path you express it through its route tables or the firewall configuration rather than fighting the managed routes on the spoke. Leaving conflicting manual routes in place alongside routing intent is the classic migration trap that produces flows taking neither path you intended.