Virtual network peering is…

Correct: b. Architecture Center.

Correct: b. Two connectivity types.

Microsoft · Azure security · Lesson 8 of 10

Hub-spoke: spokes peer the hub, not each other

On-prem FortiGate 203.0.113.10 must reach pay-api in 10.41.0.0/16. The hub 10.40.0.0/16 holds Azure Firewall 10.40.0.4 and the VPN gateway (public 203.0.113.50). Spokes peer the hub. They do not mesh to each other unless you designed that. The gateway subnet name is not a suggestion: it must be GatewaySubnet.

Updated 2026-08-18·19 min read·L2 primary·Quiz at end

After this page you can

Place Firewall + VPN/ER in the hub, workloads in the spoke.
Set peering: gateway transit on hub, use remote gateway on spoke.
Contrast ExpressRoute (private circuit) with VPN (IPsec over Internet).
Prove FortiGate ↔ pay-api with the route table, not a green tunnel icon.

The ticket

Phase-1 to 203.0.113.50 is up. Priya still cannot hit pay-api. Spoke is not peered. There is a VPN gateway in the spoke because “every VNet needs one.” The subnet is named Gateway. Azure will not put a gateway there.

Quick interview answer

CAF / Architecture Center hub-spoke: the hub is shared networking (Firewall, Bastion, VPN Gateway and/or ExpressRoute gateway). Spokes hold workloads and peer to the hub. Peering is non-transitive — spoke-to-spoke needs the Firewall/NVA (UDR) or an extra peering you meant to create. Enable Allow gateway transit on the hub peering and Use remote gateway on the spoke. The gateway subnet must be named GatewaySubnet. VPN = IPsec over the Internet to 203.0.113.50. ExpressRoute = private connectivity via a provider, not the public Internet. They can coexist; VPN is the usual lab / backup path.

On-prem FortiGate to Azure hub to spoke pay-api — One gateway in the hub. Spokes borrow it. They do not grow their own.

Lab data · dummy only

Tenant techclick-lab.in · MG tc-root / tc-landing / tc-workloads · subs sub-hub sub-spoke-app · hub VNet 10.40.0.0/16 · spoke 10.41.0.0/16 · Azure Firewall 10.40.0.4 · VPN GW public 203.0.113.50 · on-prem FortiGate WAN 203.0.113.10. Not a live tenant.

Mental model

Piece	Where	This lab
Azure Firewall	Hub `AzureFirewallSubnet`	10.40.0.4
VPN Gateway	Hub `GatewaySubnet`	Public 203.0.113.50
ExpressRoute GW (when you buy the circuit)	Same hub GatewaySubnet	Not in the dummy unless added
pay-api	Spoke, peer to hub	10.41.0.0/16 in sub-spoke-app
On-prem	FortiGate	WAN 203.0.113.10 · LAN 10.20.30.0/24

Non-transitive peering

A second spoke does not see the first unless you send it via the Firewall or add a peering you meant.

How to choose

Need	Pick	Not
Lab / backup / encrypted over Internet	VPN Gateway ↔ FortiGate	A gateway in every spoke
Private connectivity, provider circuit	ExpressRoute (+ VPN as failover if designed)	“ER is just a faster VPN”
Spoke → Internet / spoke → spoke inspect	UDR to 10.40.0.4	Default system routes and hope

https://portal.azure.com

Training mock · not live

Azure portal

HomeMicrosoft Entra IDVirtual networksAzure Firewall

Virtual networks → vnet-hub → Peerings

hub-to-spoke-app

Hub peering

Allow gateway transit = Enabled

Spoke peering

Use remote gateway = Enabled

Forwarded traffic

Allowed

Gateway subnet

GatewaySubnet · hub 10.40.0.0/16

Remote peer

FortiGate 203.0.113.10 ↔ 203.0.113.50

GatewaySubnet is the name. Spokes borrow the hub gateway. Training mock.

Runbook

Side A — hub
Hub VNet 10.40.0.0/16 in sub-hub. Subnets named GatewaySubnet and AzureFirewallSubnet. VPN GW public 203.0.113.50. Firewall 10.40.0.4. No VMs in those two subnets.
Side B — spoke + on-prem
Peer spoke 10.41.0.0/16. Transit + remote gateway. FortiGate Phase-2 selectors: 10.20.30.0/24 ↔ 10.40.0.0/16 and 10.41.0.0/16 (or the summary you actually advertised). UDRs so spoke → on-prem does not SNAT to the Internet.
Side C — prove
Effective routes on pay-api NIC: 10.20.30.0/24 via VPN/Firewall as designed. Ping/TCP from Priya 10.20.30.80. Tunnel green + no route = still down.

az · dummy

az network vnet subnet list -g rg-hub --vnet-name vnet-hub --query "[].name" -o tsv
# AzureFirewallSubnet
# GatewaySubnet
# AzureBastionSubnet

az network vnet peering show -g rg-spoke --vnet-name vnet-spoke -n spoke-to-hub --query "[allowForwardedTraffic, useRemoteGateways, remoteAddressSpace.addressPrefixes]" -o tsv
# True
# True
# 10.40.0.0/16

az network nic show-effective-route-table -g rg-spoke -n nic-pay-api -o table
# Source   Prefix         NextHopType        NextHopIP
# User     0.0.0.0/0      VirtualAppliance   10.40.0.4
# VNetPeering  10.40.0.0/16  VNetPeering

Four failures

1 · Subnet named Gateway

Not GatewaySubnet. Gateway will not deploy. Rename is not a live merge — plan the prefix.

2 · Spoke-to-spoke expectation

Peering is not transitive. Send via Firewall or peer them on purpose.

3 · Gateway in the spoke

You just paid twice and broke transit. One gateway in the hub.

4 · Green IKE, black hole route

Selectors, BGP, or UDR sent 10.20.30.0/24 to 10.40.0.4 SNAT. Read effective routes.

How to prove it

Close only when

1) Subnet name is GatewaySubnet. 2) Spoke uses the remote gateway. 3) Effective route to 10.20.30.0/24 is the path you designed. 4) Priya’s packet reaches pay-api, not only IKE.

Traps

Said	Missing
ExpressRoute is a VPN SKU	ER is a private circuit; VPN is IPsec on the Internet
NSG on AzureFirewallSubnet	Not supported — do not put one there
Two spokes are “connected via the hub”	Only if UDR/NVA or extra peering exists

Azure security class series: Shared + Entra · Landing zone · NSG vs Firewall vs WAF · Conditional Access · Key Vault + MI · Private Link · Defender + Sentinel · Hub-spoke · Identity path · Interview