Joe Poyzer

Specializing in networking, systems, cloud, and automation.

📌 Overview

This was the hands-on project completed after earning the Microsoft Certified: Azure Network Engineer Associate (AZ-700) certification — a full hub-spoke Azure network built from scratch with hybrid connectivity back to a home lab environment, rather than a purely isolated cloud exercise.

Environment:

  • 3 Azure VNets: JPHubVNet (hub), JPSpoke1VNet, and JPSpoke2VNet (spokes)
  • Virtual Network Gateway hosted in JPHubVNet
  • Site-to-Site VPN connecting JPHubVNet to an on-prem FortiGate
  • Point-to-Site OpenVPN with Entra ID authentication, also terminating on JPHubVNet's gateway

🔧 Objectives

  • Design and deploy a hub-spoke VNet architecture with proper peering and gateway transit
  • Establish a Site-to-Site VPN tunnel between Azure and an on-prem FortiGate
  • Configure Point-to-Site VPN access using Entra ID authentication
  • Enable transitive routing between the two spoke VNets, which peering alone doesn't provide
  • Validate routing and connectivity across the full hybrid topology

🔀 Hub-Spoke Topology and Gateway Transit

JPHubVNet held the Virtual Network Gateway and served as the hub. Peering was configured between JPSpoke1VNet and JPHubVNet, and separately between JPSpoke2VNet and JPHubVNet, with traffic allowed across each peering connection. Gateway transit was enabled on both peerings, allowing both spoke VNets to use JPHubVNet's VPN Gateway — which is what let both the Site-to-Site tunnel (to the on-prem FortiGate) and the Point-to-Site VPN reach resources in either spoke, not just the hub.

🔁 Making the Peerings Transitive

VNet peering by itself isn't transitive — JPSpoke1VNet and JPSpoke2VNet being peered to JPHubVNet doesn't automatically let them talk to each other. To solve that, a route table was created for each spoke VNet, with a User-Defined Route (UDR) pointing to the other spoke's subnet, using the Virtual Network Gateway as the next hop. That forced spoke-to-spoke traffic to route through JPHubVNet's gateway rather than having no path at all.

Route Propagation also had to be enabled on each spoke's route table, so that routes learned from on-prem via the Site-to-Site VPN would actually propagate down into the spoke VNets — without it, the spokes would have no route back to the on-prem FortiGate's network even with the UDR and gateway transit in place.

🏠 On-Prem Side

The on-prem side of the Site-to-Site VPN was a FortiGate firewall, terminating the IPsec tunnel back to JPHubVNet's Virtual Network Gateway.

📈 Results

  • Stable Site-to-Site VPN tunnel established between JPHubVNet and the on-prem FortiGate
  • Point-to-Site VPN access working with Entra ID authentication
  • Gateway transit enabled on both spoke peerings, letting both spokes reach on-prem resources through JPHubVNet
  • Spoke-to-spoke routing working via UDRs pointing to the Virtual Network Gateway, with Route Propagation enabled to bring in on-prem routes
  • Full hub-spoke connectivity validated end-to-end

📝 Notes / Lessons Learned

  • VNet peering is not transitive by default — two spokes peered to the same hub still need explicit UDRs (with the gateway as next hop) to route traffic between each other
  • Gateway transit is easy to overlook in hub-spoke designs — without it, spoke VNets have no path to on-prem even if the hub's VPN is fully functional
  • Route Propagation has to be explicitly enabled on spoke route tables for on-prem routes learned to actually reach the spokes — a UDR alone doesn't bring in dynamically learned routes
  • Hybrid connectivity labs are significantly more valuable than isolated cloud-only exercises, since they surface real routing interactions (like transitive routing across a hub-spoke design) that a pure Azure-to-Azure lab never would