Gateway Transit

• Reduces the number of VPN gateways you must deploy and manage.
• Centralizes connectivity and routing configuration in a hub.
• Lowers operational complexity and costs.
• Frees up resources in spoke VNets (no gateway required in each spoke).
• Supports hybrid connectivity patterns such as site-to-site and point-to-site through the same hub gateway.

​

Traditional approach vs. gateway transit

• Requires a VPN gateway in each VNet for site-to-site connections.
• Higher cost and more management overhead.
• Greater risk of configuration drift and misconfiguration.

• One centralized gateway in a hub VNet.
• Spokes use the hub gateway through VNet peering.
• Simplified routing, centralized security controls, and cost savings.

• Allow gateway transit: enabled on the hub peering to allow spokes to use the hub’s gateway.
• Use remote gateways: enabled on the spoke peering so the spoke sends gateway-bound traffic to the hub.

​

Hub-spoke configuration and gateway transit

• Centralized routing, inspection, and connectivity.
• Simplified hybrid connectivity (S2S and P2S).
• Easier to apply consistent network security policies.

• Hub VNet contains the virtual network gateway with a P2S configuration.
• Spoke VNet (where a VM resides) is peered to the hub and configured to use the remote gateway.
• A client (laptop) connects via the Azure VPN Client to the hub gateway and accesses a private IP in the spoke VNet.

• On the spoke-to-hub peering: “Use remote gateways” is enabled so the spoke knows to route gateway-bound traffic to the hub.
• On the hub-to-spoke peering: “Allow gateway transit” is enabled to let the hub’s gateway be used by the spoke.
• If you have network virtual appliances (NVAs) in-line, you may also need “Allow forwarded traffic.”

​

Demo: P2S VPN client → access VM in peered spoke

1. Configure P2S on the hub gateway with Azure AD authentication and an address pool.
2. Install and configure the Azure VPN Client on your laptop and authenticate via Microsoft Entra ID.
3. Connect the client; the client will receive routes for the hub and peered spoke VNets (for example, the spoke address space 192.168.0.0/24).
4. From your laptop, SSH to the private IP of the VM in the spoke VNet. Traffic will traverse the P2S connection to the hub gateway, then follow the peering to the spoke.

# From Windows PowerShell on the client machine
ssh kodekloud@192.168.0.4
The authenticity of host '192.168.0.4 (192.168.0.4)' can't be established.
ED25519 key fingerprint is SHA256:t0XtSK535TnKuzrM5PHX5zTozvQskMjJ4VZLnFdjv/70.
This host key is known by the following other names/addresses:
    C:\Users\RithinSkaria/.ssh/known_hosts:54: 172.191.37.104
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.0.4' (ED25519) to the list of known hosts.
kodekloud@192.168.0.4's password:
# Once connected or after authentication, verify connectivity:
ping 192.168.0.4

Pinging 192.168.0.4 with 32 bytes of data:
Reply from 192.168.0.4: bytes=32 time=199ms TTL=64
Reply from 192.168.0.4: bytes=32 time=198ms TTL=64
Reply from 192.168.0.4: bytes=32 time=197ms TTL=64

Ping statistics for 192.168.0.4:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 197ms, Maximum = 199ms, Average = 198ms

​

When to use gateway transit

• Use gateway transit when you have multiple VNets that must access the same on-premises network or shared services and you want to centralize connectivity.
• Avoid placing gateways in every VNet when you want to reduce cost and simplify management.
• If you need isolation (separate gateways per VNet for security or performance reasons), consider per-VNet gateways instead.

​

Links and references

• Azure Virtual Network Peering overview
• Use remote gateways and allow gateway transit
• Point-to-site VPN overview (Azure VPN Gateway)
• Azure VPN Client overview
• Hub-spoke architecture (Azure reference)