4 min read
AzureAzure HybridNetworkingVNet PeeringVPN GatewayBGPBicep
Created on

Azure hub-spoke networking: when Use remote gateway is required, and when Advertised gateway prefixes is better

Intro

In many hub-spoke Azure designs, we are told to always enable Use remote gateway on spoke peerings when the hub contains a VPN gateway. That guidance is correct in classic setups, but it is not always required in environments where we manage subnet routing fully with IaC and user-defined routes (UDRs).

The important caveat is BGP. If we disable Use remote gateway in a spoke that still needs to be represented through BGP advertisement to on-premises peers, we end up with missing routes and broken connectivity.

With the Advertised gateway prefixes capability (released in May 2026 in public preview), we can now control summarized prefixes directly on the hub virtual network and avoid enabling Use remote gateway on every spoke peering while still advertising clean routes through BGP.

Here is a picture of my BGP peer advertisement before making the changes:

The behavior that causes confusion

In a hub-spoke setup with VPN gateway transit, we typically configure:

  • Hub peering to spoke: Allow gateway transit = enabled
  • Spoke peering to hub: Use remote gateway = enabled

When this is enabled, spoke address spaces are learned and can be advertised through the hub gateway path.

In environments with IaC-managed UDRs on every subnet, traffic forwarding can still work without Use remote gateway, because route tables already point traffic to the correct next hop (for example firewall/NVA or gateway path).

So data plane routing might still look fine at first glance, but route advertisement behavior to BGP peers is where things will fail.

Why traffic breaks when BGP is in scope

If you have BGP-enabled S2S connectivity to on-premises and you remove Use remote gateway from spoke peering:

  1. Spoke prefixes stop being represented in the effective route advertisement path.
  2. On-premises BGP peers no longer learn those prefixes.
  3. Return traffic to spokes fail because on-premises devices do not have valid routes anymore.

That is why teams sometimes see “it worked yesterday, then suddenly some spoke networks became unreachable” right after peering clean-up.

The newer approach: Advertised gateway prefixes

With Advertised gateway prefixes, configured on the hub where the VPN gateway is attached, we can explicitly control which summarized prefixes are advertised through BGP.

This gives us two practical benefits:

  • We can keep peering configuration cleaner (without depending on Use remote gateway on every spoke for advertisement behavior).
  • We can advertise summarized, intentional prefixes instead of relying on implicit route propagation patterns.

Here is a before/after architecture drawing showing the difference:

Configuration flow (IaC-focused)

Below is a practical flow I use.

1. Keep gateway transit enabled from hub to spoke

On the hub peering toward each spoke, keep Allow gateway transit enabled.

resource hubToSpokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2025-07-01' = {
  name: '${hubVnet.name}/hub-to-spoke-a'
  properties: {
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: true
    useRemoteGateways: false
  }
}

2. Disable Use remote gateway on spoke peering (when intended)

In this pattern, spoke peerings can be kept with Use remote gateway disabled.

resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2025-07-01' = {
  name: '${spokeVnet.name}/spoke-a-to-hub'
  properties: {
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
  }
}

HINT

Do this only when you are intentionally controlling routing and advertisement behavior. If your design still relies on traditional gateway transit propagation from the spoke peering, keep Use remote gateway enabled.

3. Keep UDR routing managed in IaC

Ensure subnet route tables in spokes are explicitly attached and maintained through IaC. I am not including route table/subnet Bicep in this post, and instead focusing on peering and gateway advertisement behavior.

4. Configure Advertised gateway prefixes on the hub VNet

Use a Microsoft.Network/virtualNetworks API version that includes support for Advertised gateway prefixes and define summarized prefixes on the hub VNet where the VPN gateway is attached.

@description('Summarized prefixes to advertise from hub gateway to BGP peers')
param summarizedGatewayPrefixes array = [
  '10.40.0.0/16'
  '10.50.0.0/16'
]

resource hubVnet 'Microsoft.Network/virtualNetworks@2025-07-01' = {
  name: hubVnetName
  location: location
  properties: {
    // Keep your existing hub VNet settings here (address space, subnets, etc.)
    // and add advertised prefixes on this VNet resource.
    summarizedGatewayPrefixes: summarizedGatewayPrefixes
  }
}

Validation checklist after change

After moving to this model, validate these points:

  1. Hub-spoke traffic still follows intended UDR next hops.
  2. On-premises BGP peers receive the summarized prefixes you configured.
  3. Effective routes on spoke NICs and subnets still align with your intended data paths.
  4. No legacy automation re-enables Use remote gateway unexpectedly.

Useful references