Troubleshooting Lab: Create a virtual hub in Virtual WAN
Diagnostic Scenarios
Scenario 1 — Root Cause
An infrastructure team created a Standard Virtual WAN and provisioned a virtual hub in the Brazil South region with the address space 10.100.0.0/24. The hub reached the Succeeded state normally. Next, the team attempted to connect the VNet vnet-prod-spoke1 (range 10.100.0.0/23) to the hub via the Azure portal. The operation failed immediately with the following message:
Error: HubVnetConnectionFailed
Code: VnetAddressSpaceOverlapWithHubAddressSpace
Message: The virtual network address space '10.100.0.0/23' overlaps with
the hub address space '10.100.0.0/24'. Connection cannot be created.
The team observed that the spoke VNet in question is in the same subscription as the Virtual WAN, that RBAC permissions are correct, and that other hubs in the same organization accept connections without issues. A colleague suggested that the problem could be the Virtual WAN type, since Basic hubs would have additional VNet restrictions.
What is the root cause of the failure?
A) The Virtual WAN is in a different subscription from the spoke VNet, requiring cross-subscription peering approval.
B) The spoke VNet address space overlaps with the virtual hub's reserved address space.
C) The Standard Virtual WAN type does not allow connections with VNets whose range is larger than /24.
D) The hub has not yet completed internal route propagation, and the connection will fail until BGP is active.
Scenario 2 — Action Decision
The root cause has already been identified: the virtual hub hub-eastus was created with the address space 10.100.4.0/24, but the revised network planning requires the hub to use 10.50.0.0/22 to accommodate additional gateways and NVA services planned for the next 30 days. The hub already has two active spoke VNet connections and a VPN Gateway in Succeeded state. The change is urgent, as the NVA deployment is scheduled for next week. The team has full permissions over the Virtual WAN and its dependencies.
What is the correct action to take at this moment?
A) Edit the hub's address space directly through the Azure portal, updating the address space field to 10.50.0.0/22.
B) Delete the VPN Gateway, change the hub's address space, and recreate the gateway, keeping the VNet connections intact.
C) Recreate the virtual hub with the correct address space, reconnect the spoke VNets, and reconfigure the VPN Gateway after the new hub reaches Succeeded state.
D) Create a second virtual hub in the same region with the correct address space and migrate the connections gradually.
Scenario 3 — Root Cause
An engineer reports that they created a virtual hub in the West Europe region with Basic type and, when trying to add an ExpressRoute Gateway through the portal, the option is completely absent from the interface. The engineer verified that they have the Contributor role in the subscription, that the Virtual WAN is in Succeeded state, and that the hub is also in Succeeded state. The architecture team informs that the company has an active ExpressRoute circuit provisioned by the provider, with 1 Gbps bandwidth and private peering configured. The West Europe region is supported by ExpressRoute.
What is the root cause of the missing ExpressRoute Gateway creation option?
A) The Contributor role does not have permission to add gateways to a virtual hub; the Network Contributor role is required.
B) The ExpressRoute circuit needs to be associated with a Resource Group in the same management group as the Virtual WAN before the gateway can be created.
C) The Basic Virtual WAN type does not support ExpressRoute Gateway; this functionality is only available in the Standard type.
D) The ExpressRoute Gateway can only be added during the initial hub creation and is not available as a post-creation operation.
Scenario 4 — Diagnostic Sequence
An architect receives the following report: after creating a Standard virtual hub in the Southeast Asia region, none of the connected spoke VNets can communicate with each other, despite all connections showing Connected status in the portal. The hub was created two hours ago.
The following investigation steps are available, out of order:
[P] Verify if the Virtual WAN is Standard type (requirement for transitive routing)
[Q] Confirm that VNet connections are in Connected state in the portal
[R] Verify if Routing Intent or hub route tables are correctly propagating
routes to each spoke
[S] Confirm that spoke VNet prefixes appear in the effective route table
of VMs in each spoke
[T] Verify if there is address space overlap between spoke VNets
What is the correct investigation sequence?
A) T, P, Q, R, S
B) Q, P, T, R, S
C) P, Q, T, R, S
D) Q, T, P, R, S
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message is direct: VnetAddressSpaceOverlapWithHubAddressSpace. The spoke VNet range is 10.100.0.0/23, which completely encompasses the hub range 10.100.0.0/24. Any overlap between the hub's address space and the connected VNet's address space prevents connection creation, as this would cause routing ambiguity in the hub's internal components.
The information about RBAC permissions and other hubs working correctly is irrelevant for this diagnosis; it was included to divert focus to operational causes when the cause is purely network configuration.
The colleague's suggestion about the Basic type is the most dangerous distractor: the Virtual WAN type has no relationship to this specific error. Acting on this hypothesis would lead the team to try recreating the WAN as Basic, which would not solve anything and add unnecessary downtime.
Answer Key — Scenario 2
Answer: C
A virtual hub's address space is immutable after creation. There is no mechanism in the portal, CLI, or API to change this field in an existing hub. Therefore, the only valid solution is to recreate the hub with the correct space.
Distractor A is the most dangerous: many engineers try to edit the field in the portal and may interpret the absence of a save button as a temporary bug, wasting time. Distractor B starts from the false assumption that only the gateway blocks the change. Distractor D is technically possible as a migration strategy, but does not solve the original hub's problem and introduces unnecessary complexity when the direct solution is to recreate.
The critical constraint of the scenario is that the hub already has active connections and a gateway: this means that recreation requires maintenance window planning, as there will be connectivity interruption during the process.
Answer Key — Scenario 3
Answer: C
The Basic Virtual WAN type only supports Site-to-Site VPN Gateway. ExpressRoute and User VPN (Point-to-Site) gateways are exclusive to the Standard type. Since the hub was created within a Basic Virtual WAN, the portal simply does not display the ExpressRoute Gateway creation option, as it is not a valid operation in this context.
The information about the active ExpressRoute circuit, 1 Gbps bandwidth, and configured private peering is irrelevant for this diagnosis. They describe the circuit state on the provider side, which is correct, but the problem is on the hub side before even reaching the circuit.
Distractor D represents a dangerous misconception: if the engineer believes that the gateway can only be created during hub creation, they may conclude that the hub needs to be recreated, which is partially true (for other reasons), but for the wrong reason. The correct action is to upgrade the Virtual WAN to Standard type.
Answer Key — Scenario 4
Answer: B
The correct sequence is Q, P, T, R, S, which follows the logic of progressive elimination from most basic to most specific:
| Step | Verification | Reason |
|---|---|---|
| Q | Are connections Connected? | Validates if the problem is at the connection or routing layer |
| P | Is Virtual WAN Standard? | Confirms if transitive routing is supported in the topology |
| T | Is there address overlap? | Eliminates ambiguous routing cause before investigating route tables |
| R | Are route tables propagating routes? | Investigates the hub's control plane layer |
| S | Are effective routes on VMs correct? | Confirms data plane state at VM level |
Sequence A (starting with T) doesn't make sense because checking overlap before confirming connection state reverses the triage order. Sequence C starts by checking WAN type, which is relevant but secondary to connection state. Starting with the visible and observable state (Q) before investigating configuration causes is the central principle of progressive diagnostic reasoning.
Troubleshooting Tree: Create a virtual hub in Virtual WAN
Color Legend:
| Color | Meaning |
|---|---|
| Dark blue | Initial symptom (root node) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, identify the observed symptom and locate the root node. From there, answer each diagnostic question based on what is directly verifiable in the portal or via tools like Network Watcher and Azure CLI. Each answer eliminates a branch and narrows the diagnosis to the corresponding cause or action. Never skip an intermediate question: the verification order prevents you from treating a symptom as a cause.