Ever built a beautiful pair of Azure VNets, peered them, and then … nothing. One side can’t talk to the other. It’s like building two suburbs with no connecting roads nobody’s able to drop around for a brew.

This post is your roadmap for how routing works in VNet peering, both within a region and globally. We’ll look at how route propagation works (and where it doesn’t), plus those subtle peering settings that make the difference between smooth traffic and a silent timeout.

Whether you’re building a hub-and-spoke architecture or just linking services across VNets, this is the guide to help you avoid routing pitfalls and get your packets home safe.

What is VNet Peering?

VNet peering connects two Azure virtual networks, letting resources talk to each other over the Microsoft backbone network, fast and low-latency.

There are two flavours:

• Intra-region peering (within the same Azure region)
• Global VNet peering (across different regions)

Peering is non-transitive which means VNets don’t automatically route through each other so routing must be deliberate. It doesn’t involve public IP traffic, just private addressing and internal routing.

How Routing Works with VNet Peering

When VNets are peered, Azure automatically adds system routes so that each VNet can route traffic to the other’s address space.

But there’s nuance, especially when it comes to gateways, UDRs, and route propagation.

Peering Options That Matter:

• Allow forwarded traffic
  → Required if traffic is coming from a third VNet, or through a NVA (like a firewall).

• Use remote gateway
  → Lets a spoke VNet use the hub’s VPN/ExpressRoute Gateway.

Routing Propagation:

• System routes between peered VNets are added automatically.
• UDRs (User Defined Routes) override system routes as expected.
• Propagation from a remote gateway works only if:
  • The hub VNet has a gateway.
  • The spoke peering has Use remote gateway: Enabled.
  • The hub peering has Allow gateway transit: Enabled.

Real-World Use Case: Hub and Spoke Starter

You’ve got:

• Hub VNet with a VPN Gateway and an Azure Firewall
• Spoke VNet hosting workloads
• You want spoke traffic to route via the firewall for internet or VPN for on-prem traffic

Here’s where the peering/router settings get real handy.

Implementation: Peering & Routing via Bicep

Let’s walk through Bicep templates to:

1. Deploy a Hub and Spoke VNet
2. Peer them correctly
3. Route spoke traffic through the firewall in the hub

Architecture Overview

1. Define VNets

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

resource hubVnet 'Microsoft.Network/virtualNetworks@2022-07-01' = {
  name: 'hub-vnet'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'AzureFirewallSubnet'
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
    ]
  }
}

resource spokeVnet 'Microsoft.Network/virtualNetworks@2022-07-01' = {
  name: 'spoke-vnet'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.1.0.0/16']
    }
    subnets: [
      {
        name: 'AppSubnet'
        properties: {
          addressPrefix: '10.1.0.0/24'
        }
      }
    ]
  }
}

2. Peer Hub ↔ Spoke

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

resource spokeToHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
  name: 'spoke-to-hub'
  parent: spokeVnet
  properties: {
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: true
  }
}

resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
  name: 'hub-to-spoke'
  parent: hubVnet
  properties: {
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
    allowForwardedTraffic: true
    allowGatewayTransit: true
    useRemoteGateways: false
  }
}

3. Add Route Table in Spoke

You’ll need to push a UDR to the AppSubnet so that traffic destined for 0.0.0.0/0 routes to the Azure Firewall Private IP (assume 10.0.0.4 here).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

resource routeTable 'Microsoft.Network/routeTables@2022-07-01' = {
  name: 'spoke-udr'
  location: resourceGroup().location
  properties: {
    routes: [
      {
        name: 'default-route-to-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.0.4'
        }
      }
    ]
  }
}

resource subnetUpdate 'Microsoft.Network/virtualNetworks/subnets@2022-07-01' = {
  parent: spokeVnet
  name: 'AppSubnet'
  properties: {
    addressPrefix: '10.1.0.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

Gotchas & Edge Cases

• Black holes from partial peering config: If Use remote gateway is enabled on one side but Allow gateway transit is not enabled on the other, your routes won’t propagate, and the traffic goes nowhere.
• UDRs always win: If you set a UDR on a subnet, it overrides any propagated system or BGP routes—even if that UDR is broken.
• Global peering latency: Still fast, still private, but slightly higher latency than intra-region.
• No transitive peering: If VNet A peers with B, and B with C, A can’t reach C unless directly peered.

Best Practices

• Always validate both sides of a peering connection. Peering is a two-way street.
• Use Allow forwarded traffic when routing via network virtual appliances or needing spoke-to-spoke via hub routes.
• For hub-and-spoke with VPN/ER gateways, Enable one, Use on the other.
• Document peering topologies—spaghetti peerings are hard to unravel later.

Learn More

• Configure VNet Peering
• Route traffic between VNets using peering
• Virtual Network Peering Bicep Resource