Does a Peered Azure VNet Need Its Own VPN Gateway?
A peered VNet can use the hub's VPN gateway with a supported SKU and one setting in each peering direction. Check effective routes, not peering status.
A new spoke VNet appears, the hub already has a working site-to-site gateway, and the obvious question is whether you must pay for a second gateway. Usually not: gateway transit lets the spoke consume the hub's gateway across peering. Three conditions decide whether that will work, and none of them is visible from the peering status badge. Peering connectivity and permission to use someone else's gateway are separate settings, so two VMs that can already ping each other prove nothing about the VPN path.
First condition: the gateway, and the spoke's lack of one
Azure supports gateway transit for VPN Gateway SKUs other than Basic, and both regional and global peering can carry it. The spoke consumes a gateway it does not own, so it cannot have one of its own: if a gateway already exists in the spoke, or a remote-gateway option is already selected, the transit setting you want will be unavailable or ineffective. Check that before you debug anything, because the disabled checkbox is the symptom, not the fault. Read the SKU and the existing gateway first, then look at the peering settings.
Do not delete an existing spoke gateway to make the option appear until you know what depends on it. Migration order matters more than the checkbox.
Second condition: one setting in each peering direction
A peering is two objects, one on each VNet, and the transit settings live on different sides of that pair. The hub's peering toward the spoke must allow the hub gateway to serve the spoke; the spoke's peering toward the hub must accept the hub's gateway. Microsoft's gateway-transit guide names them per direction, which is the only way to keep them straight:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
A control labelled remote changes meaning depending on which VNet's peering you are editing, so read the direction, not the word. Set both sides, save, and confirm the peering reports connected in both places.
Third condition: address space and permission boundaries
Transit cannot make the same destination prefix mean two networks, so hub, spoke, and on-premises ranges have to be disjoint before any of this works. The VNets may also sit in different subscriptions or different tenants; that is not a prohibition, but the identity creating or updating each peering needs the required permissions on that network. Cross-subscription changes commonly fail on permission, and the error is easy to misread as a topology problem.
Write the ranges and the owners down before the change. Guessing at either produces a peering that connects and routes nothing.
Verify with effective routes, not with peering status
Look at the effective routes on a spoke workload's network interface and find the actual on-premises prefix. Check the subnet's route table and whether gateway route propagation is disabled, because a user-defined route or an inspection appliance can override the path the peering flags suggest. Then confirm the other direction: on-premises has to know how to reach the spoke prefix through the site-to-site connection, whether by learned advertisements or by an explicit route and matching protected-network entry on the customer device. If the prefix is missing on either side, the peering flags are not the thing to change.
Test one service from a spoke workload and follow the reply. A test from the VPN gateway or from a hub VM exercises a different source prefix and a different path.
If the topology also serves point-to-site clients, validate their installed routes separately. Windows client packages can need regeneration after a topology change, and that is a client-routing task rather than evidence that gateway sharing failed.
What sharing a gateway does not grant
Gateway transit is a routing convenience, not an authorization. Network security groups, on-premises filters, and service-level rules still decide what a spoke workload may reach, so enable the specific source-to-destination service instead of assuming the shared tunnel permits everything behind it.
Peering is also not transitive in the way people hope. Adding another spoke, or a private endpoint, introduces its own routing and access requirements that the existing transit setting does not cover.