AZ-104 Deep Dive: VNet Peering and Transit Routing with Azure Firewall · CloudEngineerHub
Azure10 min read8 views
AZ-104 Deep Dive: VNet Peering and Transit Routing with Azure Firewall
Hub-and-spoke on Azure: non-transitive peering, gateway transit, UDR-driven transit routing through Azure Firewall, global vs regional peering, and the AZ-104 exam traps.
C
CloudEngineerHub Team
Published: August 20, 2026· Last Updated: September 24, 2026·10 min read
VNet Peering & Transit Routing (AZ-104)
VNet peering is non-transitive — Spoke A cannot reach Spoke B through a Hub without a route table override. This is a guaranteed AZ-104 exam question, and in production it is the reason half of all Azure hub-and-spoke designs break on day two. This deep dive covers how peering actually behaves in the Azure fabric, how to build transit routing through Azure Firewall, and the gateway-transit settings that plug hybrid networks into the topology.
Visual Walkthrough
Trace one packet through peering, UDRs and the security appliance.
Interactive FlowHub-Spoke Routing — Follow the Packet6/6
1
Spoke workload sends
VM forwards to its default route (0.0.0.0/0 → NVA).
route
2
UDR steers traffic
Route table points inter-spoke and egress via hub appliance.
transit
3
Peering transits hub
VNet peering carries the packet into the hub VNet.
inspect
4
Firewall/NVA inspects
Rules allow, log or drop — this is your chokepoint of truth.
egress
5
Egress or on-prem
Via S2S VPN / ExpressRoute to the destination.
return
6
Return path symmetrical
Asymmetric routing is the classic failure — keep routes paired.
Hub-Spoke Routing — Follow the Packet. 1. Spoke workload sends: VM forwards to its default route (0.0.0.0/0 → NVA). — 2. UDR steers traffic: Route table points inter-spoke and egress via hub appliance. — 3. Peering transits hub: VNet peering carries the packet into the hub VNet. — 4. Firewall/NVA inspects: Rules allow, log or drop — this is your chokepoint of truth. — 5. Egress or on-prem: Via S2S VPN / ExpressRoute to the destination. — 6. Return path symmetrical: Asymmetric routing is the classic failure — keep routes paired.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Permissions — Network Contributor (or Microsoft.Network/virtualNetworks/peer/write) on both VNets; peering is a two-sided operation.
Address space — the VNets must not have overlapping CIDR ranges. Azure rejects the peering on overlap, which is why address planning precedes everything else.
Regional support — virtual network peering connects VNets in the same region; global virtual network peering connects VNets across regions (at different pricing and without some latency guarantees).
For firewall transit — a dedicated AzureFirewallSubnet (/26 or larger) and a deployed Azure Firewall with a known private IP.
For gateway transit — a VPN or ExpressRoute gateway in the hub's GatewaySubnet (/27 minimum).
How VNet Peering Works
Peering is a control-plane instruction to the Azure software-defined network: once both sides are connected, traffic flows privately over the Microsoft backbone and never traverses the public internet. There is no gateway in the data path, so latency is VM-to-VM and bandwidth is effectively the NIC limit. Two properties matter for design:
Non-transitive by design. A peering connects exactly two VNets. Spoke A peered to Hub and Hub peered to Spoke B gives you A→Hub and Hub→B, but A→B is blackholed because the hub does not forward transit packets by default.
DNS does not auto-extend. Peered VNets do not automatically resolve each other's private names; link private DNS zones to every VNet that needs them (and use autoregistration only where VMs should self-register).
Billing is per GB in both directions, and global (cross-region) peering costs more than regional. That is where transit-through-firewall designs show up on the invoice: every spoke-to-spoke byte crosses the firewall plus two peering boundaries, so route only the traffic you actually want inspected.
Deploy the hub VNet with AzureFirewallSubnet and (if hybrid) GatewaySubnet.
Deploy Azure Firewall — Standard for L3/L4 filtering and FQDN rules, Premium when you need TLS inspection and IDPS — and record its private IP (10.0.1.4 in this layout).
Peer hub→spoke and spoke→hub (both directions, every time).
Attach a user-defined route to each spoke subnet pointing transit traffic at the firewall.
Add allow rules to the Azure Firewall policy for the spoke-to-spoke and spoke-to-internet flows you intend to permit — the default posture is deny, so transit fails closed until rules exist.
The Route Table Trick
On each spoke subnet, create a UDR (User Defined Route):
Destination
Next Hop
10.0.0.0/8
Azure Firewall IP
0.0.0.0/0
Azure Firewall IP
This forces spoke-to-spoke traffic through the firewall, enabling transitive routing + centralized inspection. The 0.0.0.0/0 entry also captures internet-bound traffic, which is the point: centralized egress through the firewall, with SNAT to its public IP. A subtlety that earns exam points and saves outages — traffic within the spoke's own VNet stays direct because the system route for the local VNet address space is more specific than 0.0.0.0/0 and always wins.
Gateway Transit: One Hub Gateway for Every Spoke
Deploying a VPN gateway in every spoke is the classic scaling mistake. Gateway transit lets spokes share the hub's gateway:
On the hub side peering, enable Allow gateway transit.
On the spoke side peering, enable Use remote gateways.
With BGP enabled on the gateway, on-premises routes propagate to peered spokes automatically; without BGP you maintain them in route tables by hand. A VNet with its own gateway should not simultaneously consume a remote one, and only the hub allows transit — spokes never re-export it.
Transit Routing Options Compared
Option
Transitivity
Inspection
Best For
Full-mesh peering
Direct per link, non-transitive
NSGs only
Few spokes, no inspection requirement
VPN gateway + BGP
Transitive via gateway
No
Labs, small estates, throughput-tolerant flows
Azure Firewall + UDRs
Transitive via firewall
Yes — L3–L7, IDPS (Premium)
Enterprise hub-and-spoke default
Virtual WAN hub
Transitive, managed
Secured virtual hub
Many branches/spokes, global estates
Option (c) — Azure Firewall + UDRs — is the 2026 best practice for enterprises, with Virtual WAN as the growth path when branches multiply.
Exam Tip
Remember: VNet peering is not transitive. The fix is either (a) full-mesh peering, (b) a VPN gateway with BGP, or (c) Azure Firewall + UDRs. Expect scenario questions that test which of the three fits the requirement — inspection capability is the usual discriminator.
Real-World Enterprise Scenario
An insurance group onboards an acquired company roughly every quarter as a new spoke. Before standardization, one acquisition arrived with an overlapping 10.0.0.0/16 address space and had to be re-IPed — six weeks of work triggered by a two-hour design skip. The standardized runbook now fits in a morning: verify no CIDR overlap, create two peerings (hub↔spoke), attach the standard spoke UDR, add the spoke's CIDR to the IP group consumed by the firewall policy, and link the private DNS zone. Total elapsed time, including validation pings through the firewall: under an hour. The lesson is that peering is cheap to create and expensive to undo — the address plan is the actual deliverable.
Deploying with Azure PowerShell
Peering is bidirectional — create both sides, with the gateway flags on the right sides:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
Connect-AzAccount
Set-AzContext -Subscription"Platform-Hub-Prod"$hub = Get-AzVirtualNetwork -Name vnet-hub -ResourceGroupName rg-hub
$spoke = Get-AzVirtualNetwork -Name vnet-app -ResourceGroupName rg-app
# Hub side: allow the spoke to consume the hub's gateway
New-AzVirtualNetworkPeering -Name hub-to-app -VirtualNetwork$hub -RemoteVirtualNetworkId$spoke.Id -AllowGatewayTransit# Spoke side: consume the hub gateway
New-AzVirtualNetworkPeering -Name app-to-hub -VirtualNetwork$spoke -RemoteVirtualNetworkId$hub.Id -UseRemoteGateways# Expected output (both): Name, ProvisioningState : Succeeded, PeeringState : Initiated until the remote side exists
Then the transit UDR and verification:
PowerShell
1
2
3
4
5
6
7
8
9
$routeTable = New-AzRouteTable -Name rt-spoke-app -ResourceGroupName rg-app -Location eastus
Add-AzRouteConfig -Name to-firewall -RouteTable$routeTable -AddressPrefix 0.0.0.0/0 -NextHopType VirtualAppliance -NextHopIpAddress 10.0.1.4 | Set-AzRouteTable
# Associate the route table with the spoke subnet
Set-AzVirtualNetworkSubnetConfig -Name snet-app -VirtualNetwork$spoke -AddressPrefix 10.1.1.0/24 -RouteTable$routeTable | Set-AzVirtualNetwork
# Prove the data plane learned the routes
Get-AzEffectiveRouteTable -NetworkInterfaceName vm-app-nic -ResourceGroupName rg-app
# Expected output: rows showing 0.0.0.0/0 -> VirtualAppliance 10.0.1.4 and the local VNet system route
Troubleshooting
Symptom
Likely Cause
Fix
Spoke A → Spoke B times out
Non-transitive peering with no UDR override
Add the firewall route table or peer the spokes directly
Traffic reaches the firewall but is dropped
Firewall policy has no allow rule for the spoke range
Add a network/application rule; check the IP group membership
SYN succeeds, no SYN-ACK (asymmetric)
UDR attached on one end only
Attach matching UDRs so both directions traverse the firewall
Peering shows Initiated forever
Only one side of the peering was created
Create the remote-side peering; states then become Connected
On-premises cannot reach the spoke
Hub peering lacks gateway transit or spoke lacks use-remote-gateways
Re-create both peerings with the correct flags
Effective routes show Invalid next hop
Firewall private IP changed or typoed
Re-pin the UDR next hop to the firewall's current private IP
Visual Walkthrough
Policy, RBAC and cost roll downward — design the stack before workloads.
Layered StackAzure Scope Hierarchy — Inheritance Down the Stack5/5
PerimeterCore asset
1
Management groups
Enterprise agreement topology: platform vs landing zones.
layer 1
2
Subscriptions
Billing + policy boundary; one workload per subscription pattern.
layer 2
3
Resource groups
Lifecycle boundary — deploy, tag, and delete as a unit.
layer 3
4
Resources
VMs, storage, networking — the only layer that serves traffic.
Each layer assumes the previous one failed — depth is the strategy.
Azure Scope Hierarchy — Inheritance Down the Stack. 1. Management groups: Enterprise agreement topology: platform vs landing zones. — 2. Subscriptions: Billing + policy boundary; one workload per subscription pattern. — 3. Resource groups: Lifecycle boundary — deploy, tag, and delete as a unit. — 4. Resources: VMs, storage, networking — the only layer that serves traffic. — 5. Inheritance rule: Everything above flows down; nothing below flows up — design accordingly.
Common Errors
Overlapping address space — the peering request is rejected outright; re-plan CIDRs before anything else.
PeeringExists — someone already created that side; inspect before creating a duplicate.
AuthorizationFailed — you hold rights on one VNet only; peering needs permission on both (or use a cross-tenant process for external VNets).
RequestDisallowedByPolicy — an Azure Policy assignment blocks the write; read the policy reference embedded in the error body.
UDR next hop rejected — a VirtualAppliance next hop must resolve to an IP inside the VNet or a peered VNet.
Best Practices
One hub per region, connected by global peering or Virtual WAN; never let a hub grow past a /16 without a documented IP allocation plan.
Reserve the address pyramid top-down (management groups → subscriptions → VNets) so acquisitions land in pre-carved space.
Use IP groups in the Azure Firewall policy so spoke CIDR changes are a one-line edit, not a policy rewrite.
Route bulk flows (backup, replication) around the firewall where compliance allows — inspection transit is paid twice in peering plus firewall processing.
Treat the firewall private IP as a parameter in every template and module, never a literal.
Security Considerations
The firewall's default-deny posture is your east–west control; keep it that way and grow allow rules deliberately.
Azure Firewall Premium adds TLS inspection and IDPS for regulated flows — validate certificate distribution before enabling inspection broadly.
NSGs still apply on spoke subnets; the firewall is not a substitute for subnet-level segmentation.
Do not attach UDRs to AzureFirewallSubnet (except for documented forced-tunneling designs), and never route the firewall to itself.
Centralize egress so outbound internet from spokes is SNAT'd, logged, and filterable by FQDN instead of scattered public IPs.
FAQ
Is peered traffic encrypted?
It travels privately over the Microsoft backbone, but Azure does not encrypt it for you. Applications should use TLS end to end; add IPsec where the compliance regime demands network-layer encryption.
Does global peering work across subscriptions and tenants?
Yes. Cross-subscription peering is routine; cross-tenant peering additionally needs a user with appropriate permissions in the remote tenant during creation.
Can I peer two VNets with the same CIDR?
No. Overlapping address space makes routing ambiguous and Azure blocks it. Non-overlapping planning is non-negotiable.
Is there a bandwidth cap on peering?
No gateway sits in the path, so throughput follows the VM NIC limits — one of peering's key advantages over VPN transit.
Does a 0.0.0.0/0 UDR break VNet-internal traffic?
No. System routes for the local VNet are more specific than 0.0.0.0/0 and always take precedence; only off-VNet traffic follows the UDR.
Conclusion
Peering itself is trivial; the architecture around it is not. Non-transitivity, gateway transit flags, and UDR next hops are the three levers that turn a mesh of VNets into a governed hub-and-spoke with centralized inspection. Get the address plan right, standardize the runbook, and the topology scales one spoke at a time.
Comments
0No comments yet — be the first to share your thoughts.