In an Azure hub-and-spoke, what do allow forwarded traffic, gateway transit and use remote gateways do?
Show the answer
Say this first
Allow forwarded traffic lets a VNet accept packets that did not originate in the peer, such as traffic routed through a firewall in the hub. Allow gateway transit on the hub side and use remote gateways on the spoke side let spokes use the hub's VPN or ExpressRoute gateway. Spoke-to-spoke traffic still needs UDRs pointing at a firewall or NVA in the hub, because peering is not transitive.
Go deeper
Peering settings, set on each side
| Setting | Where | Effect |
|---|---|---|
| Allow virtual network access | Both | Basic reachability between the two VNets |
| Allow forwarded traffic | Both, as needed | Accept traffic forwarded by an NVA in the peer |
| Allow gateway transit | Hub to spoke peering | Offer the hub's gateway to the spoke |
| Use remote gateways | Spoke to hub peering | Use the hub's gateway; the spoke cannot have its own |
Spoke-to-spoke routing
Spoke 1 and spoke 2 are peered only with the hub. To connect them:
- Route table on spoke 1 subnets:
10.2.0.0/16next hopVirtualApplianceat the firewall IP (for example10.0.1.4). - Route table on spoke 2 subnets:
10.1.0.0/16to the same firewall. - Firewall policy allows the flow. Forwarded traffic allowed on the peerings.
Gateway route propagation
A route table has a "propagate gateway routes" setting. Turning it off on spoke subnets stops on-prem routes learned by the gateway from bypassing the firewall; a UDR then sends on-prem traffic to the firewall instead.
They will ask next
Why can a spoke with use remote gateways not have its own VPN gateway?
Azure allows one gateway path per VNet in that setup. The spoke delegates its hybrid routing to the hub, which keeps on-prem routing in one place.
What replaces all these UDRs at scale?
Azure Virtual WAN with routing intent, or Azure Virtual Network Manager to generate the hub-and-spoke peerings and route tables for you.
Traps
- Expecting spoke-to-spoke traffic to flow through the hub just because both are peered to it.
- Forgetting the return UDR on the second spoke, which causes asymmetric routing around the firewall.