Azure Virtual Network Peering Explained: Non-Transitive by Design

Virtual network peering is Azure’s mechanism for connecting two VNets so their resources reach each other using private IP addresses over Microsoft’s own backbone, with no gateway, no VPN tunnel, and no public internet path involved. It’s fast to configure and cheap to run, but it comes with one behavior that trips up almost everyone the first time they design a multi-VNet topology: peering does not chain. Getting that non-transitive rule straight, along with the settings that modify what a peering relationship actually permits, is one of the most reliably tested corners of the AZ-104 networking domain.

How peering works

A peering connection is created as a pair: one peering resource on each VNet, pointing at the other. Once both sides are established and connected, resources in either VNet can reach resources in the peered VNet directly, at the same latency you’d see between two resources inside a single VNet, and at whatever throughput the VM size on either end supports. There’s no bandwidth penalty from the peering relationship itself. Traffic never touches the public internet and doesn’t require encryption, because it’s already confined to Microsoft’s private network backbone.

Azure supports two flavors:

• Virtual network peering connects two VNets in the same Azure region.
• Global virtual network peering connects VNets across different Azure regions, over the same backbone, with the same basic behavior.

By default, a VNet can be peered with up to 500 other VNets, which is enough to support a hub with hundreds of spokes; that ceiling can be raised further using Azure Virtual Network Manager’s connectivity configuration.

Why peering is non-transitive

This is the detail the exam returns to again and again. If VNet A is peered with VNet B, and VNet B is separately peered with VNet C, A cannot reach C through B. Peering is a direct, point-to-point relationship between exactly two VNets, and it does not extend automatically across a chain of peerings, no matter how many hops are involved. A and C need their own direct peering, or another mechanism entirely, to talk to each other.

This trips people up because it feels like it should behave like transitive routing on a traditional network, where reachability propagates through connected hops. Azure deliberately doesn’t work that way. If your design needs A to reach C by way of B, you have two real options: peer A directly with C, or route that traffic through a network virtual appliance (NVA) sitting in B, using user-defined routes to force the path (more on that below).

Allow forwarded traffic and Allow gateway transit

Every peering connection has a set of configurable properties, and two of them are exactly what you need to work around the limits of a simple peering pair.

Allow forwarded traffic controls whether a peered VNet accepts traffic that didn’t originate inside the peered VNet itself, in other words, traffic that arrived by way of a route (like a UDR pointing at an NVA) rather than being sourced directly from a VM there. This setting is off by default. If you’re building a hub-and-spoke design where spoke-to-spoke traffic routes through a network virtual appliance in the hub, enable Allow forwarded traffic on the peering connections between the hub and each spoke, or the forwarded packets get dropped at the peering boundary even though the peering itself is healthy.

Allow gateway transit lets a VNet with its own VPN Gateway or ExpressRoute gateway share that connection with a peered VNet, so the peered VNet reaches on-premises resources through the gateway owner’s connection instead of deploying and paying for a second gateway. This is the standard hub-and-spoke pattern: the hub owns the gateway, enables gateway transit on its peering to each spoke, and every spoke reaches on-premises without a gateway of its own. A VNet can only have one gateway (local or remote via transit), and both regular and global peering support gateway transit.

Setting	Default	What it does
Allow forwarded traffic	Off	Lets the peered VNet accept traffic that arrived via a route rather than originating locally
Allow gateway transit	Off	Lets a peered VNet use this VNet’s VPN Gateway or ExpressRoute gateway instead of its own
Full connectivity	On	Baseline peering behavior; you layer network security groups on top to restrict specific traffic

Working around non-transitivity: hub NVA plus UDRs

The standard fix for “A needs to reach C, and both are only peered with hub B” is a hub-and-spoke topology with a network virtual appliance in the hub doing the routing work that peering itself won’t do automatically.

The pattern: deploy an NVA (a third-party firewall appliance, or Azure Firewall itself) in the hub VNet. Peer each spoke with the hub, and enable Allow forwarded traffic on those peerings so the hub can relay traffic that didn’t originate there. Then configure user-defined routes (UDRs) on each spoke’s subnets that send traffic destined for other spokes to the NVA’s private IP address as the next hop, instead of the default system route. The NVA receives that traffic, applies whatever inspection policy you’ve configured, and forwards it to the destination spoke over the hub’s own peering connection.

This works because the NVA in the hub is directly peered with every spoke; it isn’t relying on transitivity through an intermediate VNet the way A-to-C traffic would if routed straight through B without an appliance actively forwarding it. The NVA does the forwarding, not the peering relationship. One detail worth remembering: you cannot use a UDR that points to an ExpressRoute gateway as the next hop type; that gateway type doesn’t support being used as a routing next hop the way an NVA’s IP address or a VPN gateway does.

This hub-and-spoke pattern is also what makes centralized traffic inspection possible in the first place. Instead of every spoke needing its own security appliance, all spoke-to-spoke and spoke-to-internet traffic funnels through the hub, where a single Azure Firewall instance can apply consistent filtering and threat intelligence across the entire topology.

Requirements and limits worth knowing

• Address spaces can’t overlap. Azure rejects a peering request between VNets with conflicting IP ranges. Plan non-overlapping address spaces up front if VNets might eventually need to peer.
• You can resize a peered VNet’s address space without downtime, for both IPv4 and IPv6, though peers need to resync afterward. This doesn’t work if either side is a classic (non-Resource Manager) VNet.
• Global peering has extra load balancer restrictions. Resources in one VNet can’t reach the front-end IP of a Basic-SKU load balancer in a globally peered VNet, and some Basic-load-balancer-based services don’t work across global peering at all.
• Peering can cross subscriptions and Microsoft Entra ID tenants, which matters for landing-zone designs that separate workloads across subscriptions.
• NSGs still apply. Peering opens full connectivity by default, but you layer network security groups on either side to restrict what’s actually allowed to cross.

How the AZ-104 exam tests this

• A scenario describes A peered with B, and B peered with C, then asks why A can’t reach C. This is the non-transitivity rule, tested directly. The fix is a direct A-to-C peering or a hub NVA with UDRs, not “wait for the peering to propagate.”
• A scenario describes hub-and-spoke traffic through a central firewall appliance that’s being silently dropped. The likely missing piece is Allow forwarded traffic not being enabled on the hub-to-spoke peerings.
• A scenario wants spoke VNets to reach on-premises without deploying a gateway in every spoke. That’s Allow gateway transit on the hub’s peering connections.
• A scenario tries to peer two VNets and the operation fails. Overlapping address spaces is the most common cause the exam tests; check for conflicting IP ranges before assuming a permissions or region issue.
• A scenario asks how to inspect or filter traffic between spokes. The answer combines a hub NVA (or Azure Firewall), UDRs on the spoke subnets, and Allow forwarded traffic enabled on the relevant peerings, not one setting alone.

Once the non-transitive rule is second nature, the rest of VNet peering questions on AZ-104 become a matter of recognizing which setting (forwarded traffic, gateway transit, or a UDR-driven NVA) closes the specific gap the scenario describes. For the broader connectivity picture peering sits inside, see Azure Load Balancer vs Application Gateway vs Traffic Manager for how traffic gets distributed once it’s inside a peered topology, and work through AZ-104 practice questions that mix peering, routing, and hub-and-spoke scenarios together.