Connecting Legacy Hub vNet to New Virtual Hub

Question

Connecting Legacy Hub vNet to New Virtual Hub

Rob Bendig 0

We have an existing environment with a Hub vNet (containing Palo Alto Firewalls and a VPN Gateway) and several Spoke vNets. To this, we would like to connect a new vWAN/vHub with an SD-WAN NVA in it.

Since the existing Hub vNet has a VPN Gateway, we cannot do the standard Connection between vHub and the Hub vNet. What other mechanisms are available to establish the connection shown by the dotted line? We don't want to rip apart the existing environment but want to be able to do a phased migration from old connectivity to new.

Vallepu Venkateswarlu 10,510 Reputation points Microsoft External Staff Moderator

2026-05-27T20:21:03.52+00:00
Hi Rob Bendig,

Welcome to Microsoft Q&A Platform

It looks like you want to integrate your existing customer-managed hub VNet which already contains the Palo Alto firewalls and VPN Gateway with a new Azure Virtual WAN hub. The goal is to route part of the traffic through the new SD-WAN NVA without disrupting the current environment.

However, this setup has a limitation: a hub VNet that already contains its own gateway cannot be directly added as a standard VNet connection to a Virtual WAN hub.

Alternatively, there are a couple of approaches you can consider:

Site-to-Site VPN between hubs

Treat your existing hub vNet as if it were “on-prem.”

In Azure, create a Local Network Gateway object that points at your existing VPN GW (or your PA firewall’s public IP).

On your new Virtual WAN hub, spin up the built-in VPN gateway and establish an IPsec/IKE Site-to-Site connection to that Local Network Gateway.

Advertise the spoke/vNet CIDRs on both sides so each hub knows how to reach the other’s networks. The vHub route tables can then steer traffic from spokes through your SD-WAN NVA.

ExpressRoute association (if you have an ER circuit)

If your existing hub uses ExpressRoute, you can associate the same circuit (or a new one) to your Virtual WAN hub.

Leverage the Virtual WAN’s “ExpressRoute to hub” feature, then inject your existing hub’s prefixes via route tables.

This gives you a private, higher-bandwidth transit path between the two hubs.

Transit spoke VNet (VNet peering + vHub connection)

Spin up a small “transit” VNet (no gateways in it).

Peer it to your existing hub vNet.

Attach that transit VNet to the vHub normally (the vHub sees no gateway on the spoke, so peering is allowed).

Use that as a pivot to carry traffic between your old hub and the new one.

Phased-migration outline:

Deploy your new Azure Virtual WAN & hub (with SD-WAN NVA).

Create the Local Network Gateway for your existing hub and establish the S2S VPN on the vHub.

Validate you can ping/route from old spokes → new vHub → SD-WAN NVA.

On the old hub, add UDRs or adjust PA rules to point new-WAN traffic at the vHub tunnel.

One by one, detach spokes from the old hub (peering) and attach them to the vHub as VNet connections.

Once everything’s over the vHub, decommission the old VPN gateway and convert your hub-vNet into a spoke if desired.

Reference:

Create a site-to-site connection using Azure Virtual WAN (portal) Create a site-to-site VPN in Virtual WAN using PowerShell Connect a virtual network to a Virtual WAN hub (portal) Migrate from hub-spoke to Azure Virtual WAN ExpressRoute association in Virtual WAN

Pleaseand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.
Rob Bendig 0 Reputation points

2026-05-27T20:43:51.7233333+00:00

Regarding option (3) Transit spoke VNet (VNet peering + vHub connection)

Will this allow traffic along the path: new WAN > vHub > Transit Spoke vNet > old Hub VNet > Spoke vNet?

I thought there were challenges getting traffic to transit multiple vNets.
Vallepu Venkateswarlu 10,510 Reputation points Microsoft External Staff Moderator

2026-05-28T01:42:52.0133333+00:00

Yes, the Transit VNet approach can work, but it requires custom routing (UDRs/BGP/NVA forwarding) because Azure VNet peering itself is not transitive.

Since the existing Hub VNet already contains a VPN Gateway, it cannot be directly connected to the vHub as a standard VNet connection. Because of this, Site-to-Site VPN or ExpressRoute connectivity are often the preferred interconnect options for phased migration scenarios.

Those approaches provide a cleaner routing boundary and simpler route propagation during phased migration.

You can follow to Connect a VPN Gateway (virtual network gateway) to Virtual WAN &&& Configure Palo Alto Networks Cloud NGFW in Virtual WAN

Please "upvote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Rob Bendig 0 Reputation points

2026-05-27T20:43:51.7233333+00:00

Regarding option (3) Transit spoke VNet (VNet peering + vHub connection)

Will this allow traffic along the path: new WAN > vHub > Transit Spoke vNet > old Hub VNet > Spoke vNet?

I thought there were challenges getting traffic to transit multiple vNets.
Vallepu Venkateswarlu 10,510 Reputation points Microsoft External Staff Moderator

2026-05-28T01:42:52.0133333+00:00

Yes, the Transit VNet approach can work, but it requires custom routing (UDRs/BGP/NVA forwarding) because Azure VNet peering itself is not transitive.

Since the existing Hub VNet already contains a VPN Gateway, it cannot be directly connected to the vHub as a standard VNet connection. Because of this, Site-to-Site VPN or ExpressRoute connectivity are often the preferred interconnect options for phased migration scenarios.

Those approaches provide a cleaner routing boundary and simpler route propagation during phased migration.

You can follow to Connect a VPN Gateway (virtual network gateway) to Virtual WAN &&& Configure Palo Alto Networks Cloud NGFW in Virtual WAN

Please "upvote" if the information helped you. This will help us and others in the community as well.

Answer 1

The standard Virtual WAN VNet connection cannot be used because the existing hub VNet already has a virtual network gateway, and spoke VNets connected to a virtual hub are not allowed to have their own gateways.

To achieve the dotted-line connectivity and enable a phased migration, use an SD‑WAN (or other) NVA in a spoke VNet that is peered to the Virtual WAN hub, and then connect that environment to the legacy hub using IPsec/BGP. The supported pattern is:

Deploy an SD‑WAN NVA in a spoke VNet that is peered with the new Virtual WAN hub.
Configure BGP peering between the SD‑WAN NVA and the Virtual WAN hub route server. This lets the NVA learn and advertise routes to/from the vHub.
From that SD‑WAN NVA, build IPsec tunnels toward the existing hub’s VPN gateway (or toward the on‑prem/legacy WAN side of the existing hub). Use BGP on those tunnels if supported, so that routes between the legacy hub/spokes and the new vHub/spokes are exchanged dynamically.

This pattern is explicitly called out for scenarios where SD‑WAN NVAs cannot be deployed directly into Virtual WAN hubs but still support BGP, and it is also recommended when connecting two Virtual WANs using SD‑WAN NVAs in spoke VNets. It fits a phased‑migration approach because:

The existing hub VNet and its VPN gateway remain unchanged.
The new vHub and SD‑WAN NVA operate in parallel.
Traffic can be gradually steered from the old WAN to the new WAN by adjusting routes on the SD‑WAN NVA and in the vHub route tables.

If more granular traffic steering or multiple security stacks are needed, consider:

Using multiple hubs (for example, one vHub for new WAN/SD‑WAN and the existing hub VNet for legacy WAN), each with its own next‑hop choice.
Placing additional NVAs in spoke VNets and selectively peering only the VNets that must use them.

These approaches are consistent with the documented guidance that:

Virtual WAN hubs only support Microsoft‑managed gateways, Azure Firewall, route tables, and some integrated NVAs.
Spoke VNets connected to a virtual hub cannot have their own virtual network gateway.
SD‑WAN NVAs that cannot run inside the hub should be placed in peered spokes and connected via BGP to the hub route server.

References: