Azure Vwan + SDWAN inter Hub Connectivity issue

Hi @Raj A ,

Hope you are doing well!

From your description (“the same configuration worked under hub-and-spoke, but after shutting down on-prem DC no longer works in a full-mesh”), this most commonly points to a routing/route-propagation change after the on-prem edge (or on-prem DC) stopped advertising routes into the VWAN hub(s), or to hub-level routing intent / branch-to-branch behavior changing what’s allowed to traverse the hub(s).

Based on the provided documentation, here are the key things to check that directly align with the kinds of symptoms shown in your diagram (branches reaching both sides previously, then branch-to-branch across hubs fails because prefixes aren’t being learned/propagated).

1) Confirm whether branch-to-branch connectivity is actually allowed at the Virtual Hub level

For VWAN, the Virtual Hub setting takes precedence over Virtual WAN for traffic transiting the hub.

• If branch-to-branch connectivity is disabled at the hub level, then routes between branches will not propagate and traffic can be blocked.
• If you have a feature such as Routing Intent enabled, it can bypass these settings by directing inter-branch traffic through the configured NVA / routing policies.

This matches the “it used to work, then stops when an upstream dependency changed” pattern because shutting down the on-prem DC may have stopped the only path that was previously causing prefixes to appear (or may have changed which routing policy path is actually used).
Check the Virtual Hub configuration for branch-to-branch connectivity (and confirm whether Routing Intent is enabled and, if so, that it’s correctly set for the traffic patterns you need).

2) If you rely on “routing intent / routing policies through the NVA”, verify the NVA behaviour and bypass expectations

If your design expects inter-branch (or inter-hub) traffic to traverse through an NVA in the hub, then ensure that:

• the Routing Intent (if used) is enabled/configured to route that inter-hub/inter-branch traffic through the intended NVA / policies
• your NVA is reachable and configured to handle the returned traffic path

Also note: Accelerated Networking is not enabled by default for third-party NVAs (so if performance/packet path matters, make sure it matches vendor/VM SKU guidance). This won’t usually be the root cause of “routes stop propagating,” but it can contribute to connectivity failures after changes.

3) Verify route learning and “effective routes” after the on-prem DC shutdown

A very practical way to validate the root cause is to check what the hub router believes the routing should be.

• Use the VWAN hub “effective routes” view to confirm whether the branch prefixes are still present (and whether they’re learned/installed from the expected place after the DC shutdown).
• If the prefixes are missing, it indicates VWAN is no longer learning them from on-prem (which can break inter-hub/inter-branch flows).

This aligns with the kind of failure shown in the diagram (“prefix dropped / inter-hub VNet-to-VNet broken”), which is typically a routing-table / propagation outcome.

4) Consider whether the issue is tied to ExpressRoute vs remote-hub route selection (if applicable)

There’s also a known routing behavior where ExpressRoute routes may be preferred over remote virtual hub routes based on the VWAN route selection algorithm.

A resolution described for a similar situation involved stopping advertisement of routes from on-prem so they’re learned via inter-hub routing (rather than from ExpressRoute).

What to do (if your design includes ER):

• Validate where those inter-hub prefixes are being learned from (on-prem vs ER vs inter-hub).
• If route selection is incorrect for your expectations, you may need to adjust what’s advertised and/or how routes are propagated.

5) If you’re using multiple NVAs, ensure you aren’t hitting a supported/unsupported hub limitation

If your environment changed during migration (for example, adding another SD-WAN or SaaS NVA), be aware:

• Azure Virtual WAN does not support hosting multiple NVA types (Managed NVA and SaaS NVA) simultaneously in a single hub.
• If this limitation applies, it can disrupt routing/policies.

If you’re not using multiple NVA types in the same hub, you can skip this.

Please follow the below documents for your reference:

• https://learn.microsoft.com/azure/virtual-wan/sd-wan-connectivity-architecture?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider
• https://learn.microsoft.com/azure/virtual-wan/virtual-wan-about

If you have any questions or concerns, please let me know.