Networking: Hybrid Connectivity

Assumes Part 4's VNet, subnet, and GatewaySubnet concepts — every mechanism in this chapter attaches to a VNet through that reserved subnet.

Table of Contents#

1. Hybrid Connectivity — the Three Options at a Glance
2. Site-to-Site VPN — Architecture and Components
3. VPN Gateway SKUs — Choosing the Right Tier
4. Policy-Based vs. Route-Based VPN
5. Local Network Gateways and IPsec/IKE Policies
6. High Availability for Site-to-Site VPN
7. Point-to-Site VPN — Architecture
8. Point-to-Site Authentication Methods
9. Always On VPN and the Azure Network Adapter
10. Diagnosing VPN Gateway Connectivity Issues
11. ExpressRoute — Why It Exists Beyond VPN
12. ExpressRoute Connectivity Models
13. ExpressRoute Direct — Connecting at the Physical Layer
14. ExpressRoute SKU Tiers — Local, Standard, and Premium
15. Azure Private Peering vs. Microsoft Peering
16. Route Filters for Microsoft Peering
17. The ExpressRoute Gateway and Connecting a VNet
18. ExpressRoute FastPath — Bypassing the Gateway
19. ExpressRoute Global Reach
20. ExpressRoute Circuit Bandwidth Scaling
21. Encryption Over ExpressRoute and Bidirectional Forwarding Detection
22. Diagnosing ExpressRoute Connectivity Issues
23. Azure Virtual WAN — Global Transit Architecture
24. Virtual WAN SKUs — Basic vs. Standard
25. Virtual Hubs and Scale Units
26. Secured Virtual Hubs and Routing Intent
27. Integrating a Third-Party Network Virtual Appliance With Virtual WAN
28. Choosing Between VPN, ExpressRoute, and Virtual WAN
29. A Full Worked Hybrid Connectivity Bootstrap for Meridian Freight
30. Part 5 CLI Cheat Sheet
31. Common Mistakes and Interview Traps
32. Worked Practice Problems
33. Summary and What's Next

Hybrid Connectivity — the Three Options at a Glance#

Meridian Freight's legacy on-premises freight-routing servers, introduced back in Part 1, need to keep talking to Azure throughout a multi-year migration — this chapter covers the three mechanisms Azure offers for exactly that, each with genuinely different cost, performance, and reliability characteristics.

Site-to-Site VPN — Architecture and Components#

A Site-to-Site (S2S) VPN builds an encrypted IPsec/IKE tunnel between an on-premises VPN device and an Azure VPN Gateway, over the ordinary public internet.

# Create a VPN Gateway — this alone can take 30-45 minutes to provision
az network vnet-gateway create --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --vnet vnet-meridian-hub --gateway-type Vpn --vpn-type RouteBased \
  --sku VpnGw2AZ --public-ip-address pip-vpngw-meridian

Why the 30-45 minute provisioning time is worth flagging explicitly rather than treating as a minor detail: a VPN Gateway is not an instant, API-driven resource the way most of this series' resources are — it involves standing up real, dedicated gateway infrastructure, and this timeline should be accounted for explicitly in any migration cutover plan, not discovered as a surprise delay during a time-boxed maintenance window.

VPN Gateway SKUs — Choosing the Right Tier#

az network vnet-gateway list-sizes --output table

# Check which SKU is currently deployed before assuming it needs upgrading
az network vnet-gateway show --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --query "sku.name"

A genuinely important, current 2026 fact worth stating explicitly: Microsoft is automatically migrating every remaining legacy Standard and High Performance SKU gateway to a VpnGw1AZ-equivalent after June 2026 — a design still referencing the old SKU names in documentation, IaC templates, or runbooks needs updating regardless, and the AZ-suffixed SKUs (zone-redundant) are the only sensible choice for any new deployment. The Basic SKU carries real functional gaps worth knowing specifically: it doesn't support IKEv2, IPv6, or RADIUS authentication — a design assuming any of those needs at minimum a VpnGw1 tier or higher.

Policy-Based vs. Route-Based VPN#

Worth stating as unambiguous, current guidance: route-based VPN is the correct choice for essentially every new deployment — policy-based VPN exists mainly for compatibility with older on-premises devices that only support that model, and carries real limitations (a single tunnel per connection, no BGP dynamic routing) that route-based VPN doesn't share.

Local Network Gateways and IPsec/IKE Policies#

A Local Network Gateway represents the on-premises side of the connection to Azure — its public IP and the address ranges reachable behind it.

az network local-gateway create --name lng-meridian-onprem --resource-group rg-networking-prod \
  --gateway-ip-address 203.0.113.10 --local-address-prefixes 192.168.0.0/16

# Create the actual connection, with an explicit IPsec/IKE policy
# matching the on-premises device's configuration
az network vpn-connection create --name conn-onprem-to-hub --resource-group rg-networking-prod \
  --vnet-gateway1 vpngw-meridian-hub --local-gateway2 lng-meridian-onprem \
  --shared-key "<pre-shared-key>" \
  --ipsec-encryption AES256 --ipsec-integrity SHA256 --ike-encryption AES256 --ike-integrity SHA256

# Update the Local Network Gateway's IP later if the on-premises
# device's public IP ever changes (a real, common maintenance task)
az network local-gateway update --name lng-meridian-onprem --resource-group rg-networking-prod \
  --gateway-ip-address 203.0.113.99

A genuinely common real-world failure worth naming explicitly: a mismatch between the IPsec/IKE policy configured in Azure and the on-premises device's own configuration (different encryption algorithms, different Diffie-Hellman groups) prevents the tunnel from establishing at all, with an error message that rarely names the specific mismatched parameter directly — confirming both sides use IDENTICAL algorithm choices is the single most common fix for a tunnel that simply won't come up.

High Availability for Site-to-Site VPN#

An AZ-suffixed SKU gateway deploys two instances across Availability Zones by default, in an active-standby configuration — enabling active-active mode makes BOTH instances simultaneously active, doubling aggregate throughput and providing genuinely faster failover than waiting for a standby to activate.

az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --set activeActive=true

# Confirm both gateway instances show as connected after enabling it
az network vnet-gateway show --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --query "{active: activeActive, instances: bgpSettings.bgpPeeringAddresses}"

Point-to-Site VPN — Architecture#

Point-to-Site (P2S) VPN connects an individual device — a field engineer's laptop, not a whole office network — directly to a VNet, without needing a dedicated on-premises VPN appliance at all.

az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --address-prefixes 172.16.0.0/24 --client-protocol OpenVPN

# Download the pre-configured VPN client profile package to distribute
az network vnet-gateway vpn-client generate --name vpngw-meridian-hub \
  --resource-group rg-networking-prod --authentication-method EAPTLS

Point-to-Site Authentication Methods#

# Configure Entra ID authentication for a P2S gateway
az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --aad-tenant "https://login.microsoftonline.com/<tenant-id>" \
  --aad-audience "<azure-vpn-client-app-id>" \
  --aad-issuer "https://sts.windows.net/<tenant-id>/"

Why Entra ID authentication is worth treating as the strongest current option specifically for an organization already invested in this series' Part 2 identity model: it lets Conditional Access policies — device compliance checks, MFA, risk-based access — apply directly to the VPN connection attempt itself, rather than treating VPN authentication as a separate credential system disconnected from the rest of the organization's access governance.

From the Trenches: A field engineer's laptop, lost during travel, still had a valid P2S VPN certificate installed with no expiration set. Because the organization used certificate-based authentication with no centralized revocation process, the lost device retained VPN access for weeks until IT was specifically informed and manually revoked that one certificate. Migrating to Entra ID-based P2S authentication afterward meant a lost or compromised device's access could be revoked the same way any other compromised Entra identity is handled (Part 2's PIM/Conditional Access tooling) — instantly, and centrally, rather than requiring someone to remember which specific certificate belonged to which device.

Always On VPN and the Azure Network Adapter#

Always On VPN (a Windows-specific capability, distinct from Azure's own P2S VPN) automatically establishes a device's VPN connection whenever it has internet access, without requiring a user to manually connect — genuinely useful for a fleet of company-managed laptops that should always be reachable for management purposes.

# Azure's requirements for Always On VPN center on the P2S gateway
# configuration supporting IKEv2 and certificate or Entra ID auth
az network vnet-gateway show --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --query "vpnClientConfiguration.vpnClientProtocols"

The Azure Network Adapter is a related, simpler mechanism — a lightweight, portal-driven way to establish a P2S-style connection specifically from a single Azure VM back to an on-premises network, useful for a quick, one-off diagnostic or migration-support connection without configuring a full gateway-based solution.

Diagnosing VPN Gateway Connectivity Issues#

# Check the current connection status and last-connected timestamp
az network vpn-connection show --name conn-onprem-to-hub --resource-group rg-networking-prod \
  --query "{status: connectionStatus, egressBytes: egressBytesTransferred}"

# Enable detailed diagnostic logging on the gateway itself
az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --enable-bgp true

# Reset a gateway as a last resort for a tunnel stuck in a bad state —
# causes a brief connectivity interruption, so use deliberately, not reflexively
az network vnet-gateway reset --name vpngw-meridian-hub --resource-group rg-networking-prod

Worth stating the diagnostic order explicitly: confirm the on-premises device's public IP hasn't changed (a common, easy-to-miss cause for a previously-working tunnel suddenly failing), then confirm the IPsec/IKE policy still matches on both sides, then check for an expired pre-shared key or certificate, before resorting to a gateway reset — a reset briefly interrupts every connection through that gateway, not just the one being diagnosed, so it shouldn't be the first troubleshooting step reached for.

# Download full diagnostic logs capturing IKE negotiation details —
# genuinely useful when the connection status alone doesn't explain WHY
az network vnet-gateway packet-capture start --name vpngw-meridian-hub \
  --resource-group rg-networking-prod --filter-data "<capture-filter>"

A VPN Gateway health check through Azure Monitor Insights (Part 13 covers the full monitoring integration) surfaces gateway-level metrics — tunnel bandwidth, connection count, gateway CPU — worth checking BEFORE assuming a connectivity issue is purely a configuration problem; a gateway genuinely undersized for its actual traffic volume can show connection instability that looks identical to a misconfiguration until the underlying metrics are actually reviewed.

ExpressRoute — Why It Exists Beyond VPN#

A Site-to-Site VPN, no matter how well configured, still traverses the shared, unpredictable public internet — ExpressRoute provides a dedicated, private connection through a connectivity provider that never touches the public internet at all, with materially better latency consistency, throughput ceilings, and a stronger SLA.

Why this matters concretely for a workload with strict latency-consistency requirements — not just raw bandwidth, worth stating the underlying reasoning: public-internet-routed traffic (as in a Site-to-Site VPN) is subject to unpredictable routing changes and congestion outside either party's control, while ExpressRoute's dedicated path has consistent, predictable latency — a genuinely important distinction for a workload where latency variance itself, not just average latency, causes real problems (real-time coordination between the driver-portal backend and a legacy on-premises dispatch system, for instance).

ExpressRoute Connectivity Models#

ExpressRoute Direct — Connecting at the Physical Layer#

Everything covered so far in this chapter's ExpressRoute discussion connects through a connectivity provider — a carrier operating the physical circuit on an organization's behalf. ExpressRoute Direct skips the provider entirely, connecting an organization's own equipment directly into Microsoft's global network at the physical layer, at either 10 Gbps or 100 Gbps port speeds.

az network express-route port create --name erport-meridian --resource-group rg-networking-prod \
  --peering-location "Washington DC" --bandwidth 100 --encapsulation Dot1Q

# Multiple circuits can then be carved out of ONE ExpressRoute Direct port
az network express-route create --name er-circuit-1 --resource-group rg-networking-prod \
  --express-route-port erport-meridian --bandwidth 10000

Why this is worth knowing exists even though it's genuinely rare in practice, worth stating the actual scale threshold: ExpressRoute Direct only makes economic and operational sense for an organization with a genuine need for very high aggregate bandwidth (multiple ExpressRoute circuits sharing one physical port, or a single workload needing the full 10/100 Gbps) — for Meridian Freight's actual scale, a standard provider-based circuit remains the correct choice, and ExpressRoute Direct would be pure, unjustified over-engineering. Recognizing when NOT to reach for the more elaborate option is as much a real architectural skill as knowing the option exists in the first place.

ExpressRoute SKU Tiers — Local, Standard, and Premium#

az network express-route create --name er-meridian --resource-group rg-networking-prod \
  --peering-location "Washington DC" --provider "<connectivity-provider-name>" \
  --sku-family MeteredData --sku-tier Standard --bandwidth 1000

Why choosing the tier deliberately based on ACTUAL regional footprint matters concretely, rather than defaulting to Premium "to be safe": Premium costs meaningfully more than Standard, and a company like Meridian Freight operating entirely within North America gets no functional benefit from Premium's cross-geography reach — Standard already covers every region within that one geopolitical region, making Premium's extra cost pure waste for a footprint that never needs cross-geography connectivity.

Azure Private Peering vs. Microsoft Peering#

An ExpressRoute circuit supports two distinct peering types, each reaching a different destination.

Why an organization typically needs BOTH, worth stating explicitly rather than assuming one covers everything: Azure Private Peering alone gets Meridian Freight's on-premises network to its VNets, but reaching a PUBLIC PaaS endpoint (an Azure Storage account's public endpoint, without Private Link) or Microsoft 365 services over the private ExpressRoute path instead of the public internet requires Microsoft Peering configured separately.

Route Filters for Microsoft Peering#

Microsoft Peering, by default, would advertise routes for the ENTIRE catalog of Microsoft public services — far more than most organizations actually need or want flowing over their ExpressRoute circuit. A route filter restricts Microsoft Peering to advertise only specific, chosen services.

az network route-filter create --name filter-m365-only --resource-group rg-networking-prod

az network route-filter rule create --filter-name filter-m365-only --resource-group rg-networking-prod \
  --name allow-exchange-sharepoint --access Allow --communities "12076:5010" "12076:5060"

az network express-route peering update --circuit-name er-meridian --resource-group rg-networking-prod \
  --peering-type MicrosoftPeering --route-filter filter-m365-only

# Confirm which routes are actually being advertised after applying the filter
az network express-route peering show --circuit-name er-meridian --resource-group rg-networking-prod \
  --peering-type MicrosoftPeering --query "routeFilter.rules[].communities"

Why deliberately scoping this matters concretely, worth stating explicitly: without a route filter, Microsoft Peering can inject thousands of route prefixes into an on-premises network's routing tables — for many organizations, this is unnecessary noise consuming router resources for services never actually used over that path — a route filter keeps only the specific services (Exchange Online, SharePoint Online, or others by BGP community value) actually needed, rather than accepting the full, undifferentiated route catalog by default.

The ExpressRoute Gateway and Connecting a VNet#

az network vnet-gateway create --name ergw-meridian-hub --resource-group rg-networking-prod \
  --vnet vnet-meridian-hub --gateway-type ExpressRoute --sku ErGw3AZ

az network vpn-connection create --name conn-er-to-hub --resource-group rg-networking-prod \
  --vnet-gateway1 ergw-meridian-hub --express-route-circuit2 er-meridian

# Confirm the VNet-to-circuit connection is actually established
az network vpn-connection show --name conn-er-to-hub --resource-group rg-networking-prod \
  --query connectionStatus

ExpressRoute FastPath — Bypassing the Gateway#

By default, ExpressRoute traffic still passes through the ExpressRoute Gateway before reaching VMs — FastPath sends traffic directly to VMs, bypassing the gateway entirely, for meaningfully better data-path performance.

az network vpn-connection update --name conn-er-to-hub --resource-group rg-networking-prod \
  --express-route-gateway-bypass true

FastPath requires an ErGw3AZ or ErGwScale gateway SKU specifically — worth checking before assuming it's available on a smaller gateway already provisioned for a different reason.

Circuit Redundancy — Why a Single ExpressRoute Circuit Is a Single Point of Failure#

Every ExpressRoute circuit is provisioned with two physical connections into Microsoft's network for redundancy WITHIN that circuit — but the circuit itself still traces back to one connectivity provider and, often, one physical peering location. A genuinely important resilience recommendation worth stating explicitly: a production workload relying entirely on ExpressRoute should provision a SECOND circuit, ideally through a different connectivity provider or peering location, with a Site-to-Site VPN as a lower-cost failover path being the minimum acceptable baseline for anything without a second circuit.

# A VPN connection configured as an automatic failover path if the
# primary ExpressRoute connection becomes unavailable
az network vpn-connection create --name conn-failover-vpn --resource-group rg-networking-prod \
  --vnet-gateway1 vpngw-meridian-hub --local-gateway2 lng-meridian-onprem \
  --shared-key "<pre-shared-key>"

Why relying on a single circuit is a real, non-theoretical risk worth taking seriously, not a paranoid edge case: a connectivity provider outage, a fiber cut affecting the physical path, or a peering-location-level Microsoft issue can take down an entire single circuit, and Meridian Freight's on-premises dependency for the legacy dispatch system this chapter has referenced repeatedly would have NO path to Azure at all during that window without a second circuit or a VPN fallback already configured and tested — testing the failover path periodically (not just configuring it once and assuming it works) is the part organizations most commonly skip.

ExpressRoute Global Reach#

Global Reach connects two ExpressRoute circuits — potentially in entirely different metro areas — directly to each other over Microsoft's own global backbone, without traffic needing to route back through either on-premises location.

Why this is worth stating as effectively making Azure into an organization's own private WAN, worth stating the underlying reasoning: two on-premises sites that would otherwise need their own dedicated WAN link between them can instead route through Microsoft's backbone via Global Reach — often lower latency and cost than a purpose-built inter-site WAN link, since it repurposes connectivity the organization is already paying for anyway.

az network express-route peering connection create \
  --circuit-name er-meridian-eastcoast --resource-group rg-networking-prod \
  --peering-name AzurePrivatePeering --connection-name conn-global-reach \
  --peer-circuit "<west-coast-circuit-resource-id>" \
  --address-prefix-type 10.200.0.0/29

ExpressRoute Circuit Bandwidth Scaling#

A genuinely practical operational question worth covering explicitly: what happens when a circuit's provisioned bandwidth becomes insufficient as Meridian Freight's Azure footprint grows?

# Scale an existing circuit's bandwidth up — this is a NON-disruptive,
# in-place change, not a circuit recreation
az network express-route update --name er-meridian --resource-group rg-networking-prod \
  --bandwidth 2000

# Confirm the change actually applied before assuming it did
az network express-route show --name er-meridian --resource-group rg-networking-prod \
  --query "serviceProviderProperties.bandwidthInMbps"

Worth stating precisely why this matters for migration and capacity planning: increasing bandwidth on an existing circuit does NOT require decommissioning and recreating it — it's an in-place scale operation with no connectivity interruption, though the connectivity provider's own physical circuit still needs to support the new bandwidth tier, which is worth confirming with the provider directly rather than assuming the Azure-side command alone guarantees the change takes effect immediately end-to-end. Downgrading bandwidth, by contrast, is NOT supported — a circuit provisioned at a given tier can only scale up, never back down, without decommissioning and recreating it, which is worth factoring into the initial tier decision rather than treating it as freely reversible in both directions.

Encryption Over ExpressRoute and Bidirectional Forwarding Detection#

A genuinely common misconception worth correcting directly: ExpressRoute's private, dedicated path is NOT automatically encrypted — it's private in the sense of not touching the public internet, but the data itself travels in the clear unless encryption is explicitly layered on top.

# IPsec over ExpressRoute — encrypts private-peering traffic
# for compliance requirements needing encryption in transit
az network vpn-connection create --name conn-er-ipsec --resource-group rg-networking-prod \
  --vnet-gateway1 vpngw-meridian-hub --express-route-circuit2 er-meridian \
  --connection-type ExpressRouteIpsec

Bidirectional Forwarding Detection (BFD) provides fast failure detection for an ExpressRoute connection — without it, detecting a failed link can take significantly longer, since it relies on slower routing-protocol-level timeouts rather than a dedicated, fast heartbeat mechanism. BFD sends lightweight heartbeat packets between both ends of the connection at a sub-second interval, and a design with two circuits for redundancy (covered later in this chapter) specifically benefits from BFD's fast detection — a slow failure detection mechanism would delay failover to the healthy circuit long enough to cause a real, user-visible outage even though redundancy technically existed.

az network vpn-connection update --name conn-er-to-hub --resource-group rg-networking-prod \
  --express-route-gateway-bypass true --enable-bgp true

# Check BFD session state directly on the ExpressRoute gateway
az network vnet-gateway show --name ergw-meridian-hub --resource-group rg-networking-prod \
  --query "bgpSettings.bgpPeeringAddresses[].defaultBgpIpAddresses"

Diagnosing ExpressRoute Connectivity Issues#

# Check circuit provisioning state on BOTH the Microsoft side and
# the connectivity provider's side — a mismatch here is a common cause
az network express-route show --name er-meridian --resource-group rg-networking-prod \
  --query "{serviceProviderState: serviceProviderProvisioningState, circuitState: circuitProvisioningState}"

# Run a connectivity check specifically through the ExpressRoute path
az network express-route show-arp-table --name er-meridian --resource-group rg-networking-prod \
  --peering-name AzurePrivatePeering --path Primary

# Check peering-level BGP session status specifically
az network express-route peering show --circuit-name er-meridian \
  --resource-group rg-networking-prod --peering-type AzurePrivatePeering \
  --query "{state: state, bgpSessions: bgpSettings}"

Worth stating the two-sided nature of ExpressRoute troubleshooting explicitly: a circuit has a provisioning state on BOTH the Microsoft side and the connectivity provider's side, and BOTH must show "Provisioned" for the circuit to actually pass traffic — a circuit stuck showing "Provisioned" on the Azure side but not yet provisioned by the connectivity provider is a genuinely common, easy-to-misdiagnose state during initial setup, since it looks complete from the Azure side alone.

Azure Virtual WAN — Global Transit Architecture#

Virtual WAN is Azure's managed, global transit network overlay — instead of manually building and peering a hub-and-spoke topology per region (Part 4), Virtual WAN provides regional hubs with built-in transitive routing between VPN sites, ExpressRoute circuits, P2S users, and VNets.

Why "automatic transitive routing between hubs" is worth calling out as the single biggest structural difference from manually building hub-and-spoke, worth stating explicitly: Part 4's hand-built hub-and-spoke requires deliberate peering and UDR configuration for any cross-region connectivity — Virtual WAN provides branch-to-branch and hub-to-hub transitive connectivity automatically, which matters most for an organization with genuinely many branch sites or regional hubs, where manually wiring every pair would be a real, growing operational burden.

Virtual WAN SKUs — Basic vs. Standard#

Worth stating unambiguously: Standard is the correct choice for essentially any production deployment — Basic's restriction to single-hub Site-to-Site VPN only makes it suitable purely for the simplest possible topology, and most of what makes Virtual WAN valuable (ExpressRoute integration, transitive routing, firewall hosting) is Standard-only.

Virtual Hubs and Scale Units#

az network vwan create --name vwan-meridian --resource-group rg-networking-prod --type Standard

az network vhub create --name vhub-eastus --resource-group rg-networking-prod \
  --vwan vwan-meridian --address-prefix 10.100.0.0/24 --location eastus \
  --sku Standard

# Connect an existing spoke VNet to the hub — Virtual WAN handles
# the underlying routing automatically, unlike Part 4's manual peering
az network vhub connection create --name conn-shipment-api --resource-group rg-networking-prod \
  --vhub-name vhub-eastus --remote-vnet vnet-shipment-api

A scale unit determines a virtual hub gateway's aggregate throughput capacity — chosen per gateway type (VPN, ExpressRoute) based on expected traffic volume, and can be scaled up later as demand grows without a full topology redesign.

# Scale a virtual hub's VPN gateway up as traffic grows
az network vpn-gateway update --name vpngw-vhub-eastus --resource-group rg-networking-prod \
  --scale-unit 4

Secured Virtual Hubs and Routing Intent#

A secured virtual hub deploys Azure Firewall (Part 7 covers the firewall itself in depth) directly inside a Virtual WAN hub, and routing intent declares, at a policy level, that all internet-bound and/or private traffic passing through the hub should be inspected by that firewall — without hand-crafting the UDRs Part 4 covered for a manually built hub-and-spoke.

az network firewall create --name fw-meridian-hub --resource-group rg-networking-prod \
  --vhub vhub-eastus --sku AZFW_Hub

az network vhub update --name vhub-eastus --resource-group rg-networking-prod \
  --routing-intent '{"internetTraffic": "Enabled", "privateTraffic": "Enabled"}'

# Confirm routing intent is actually enforced for a specific spoke's traffic
az network vhub get-effective-routes --name vhub-eastus --resource-group rg-networking-prod \
  --resource-id "<spoke-vnet-connection-resource-id>"

Why routing intent is worth calling out as a meaningfully simpler mechanism than Part 4's manual UDR-based firewall-forcing pattern, worth stating explicitly: declaring "inspect all internet traffic" and "inspect all private traffic" as a policy statement lets Virtual WAN automatically manage the underlying routing for every spoke connected to the hub — a new spoke added later automatically inherits the same inspection policy, with no per-spoke UDR to remember to create. This is the Virtual WAN-native equivalent of the hand-built hub-and-spoke security pattern this series already covered, trading some of that pattern's granular manual control for materially less ongoing operational overhead as the topology grows.

Integrating a Third-Party Network Virtual Appliance With Virtual WAN#

For an organization with an existing investment in a specific third-party firewall or SD-WAN vendor's appliance, Virtual WAN can host that NVA directly inside the hub, alongside (or instead of) Azure Firewall (Part 7).

az network virtual-appliance create --name nva-partner-firewall --resource-group rg-networking-prod \
  --vhub vhub-eastus --vendor "<nva-vendor-name>" --scale-unit 2

Why this matters for an organization not yet ready to fully standardize on Azure-native security tooling, worth stating explicitly: it lets an existing NVA investment and operational expertise carry forward into a Virtual WAN topology, rather than forcing an all-or-nothing switch to Azure Firewall as the price of adopting Virtual WAN's transit architecture.

A team already deeply invested in a specific vendor's firewall platform, with existing runbooks, alerting integrations, and staff certifications built around it, has a real, legitimate reason to prefer the NVA path even at the cost of a second licensing relationship — this isn't purely a "always pick the Azure-native option" decision.

Choosing Between VPN, ExpressRoute, and Virtual WAN#

For Meridian Freight specifically: a single Site-to-Site VPN connects the current legacy on-premises location today, with a planned move to ExpressRoute once the dispatch-system latency-consistency requirements (flagged earlier in this chapter) become business-critical enough to justify the added cost and provider lead time.

A Worked Cost Comparison#

Bringing the abstract tradeoff down to concrete numbers, worth having ready for a real budget conversation:

Why this comparison is worth presenting with real numbers rather than qualitative "ExpressRoute costs more" language, worth stating explicitly: a genuinely informed business decision weighs ExpressRoute's roughly 5-10x higher monthly cost against the SPECIFIC latency-consistency and reliability benefits a workload actually needs — for Meridian Freight's current state, with no workload yet suffering from VPN's latency variance in a business-critical way, that premium isn't yet justified; the moment the legacy dispatch system's real-time coordination requirements make latency variance a genuine operational problem, the calculus changes and the premium becomes worth paying.

A Full Worked Hybrid Connectivity Bootstrap for Meridian Freight#

# 1. Create the VPN Gateway in the hub's GatewaySubnet
az network vnet-gateway create --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --vnet vnet-meridian-hub --gateway-type Vpn --vpn-type RouteBased --sku VpnGw2AZ \
  --public-ip-address pip-vpngw-meridian

# 2. Define the on-premises side as a Local Network Gateway
az network local-gateway create --name lng-meridian-onprem --resource-group rg-networking-prod \
  --gateway-ip-address 203.0.113.10 --local-address-prefixes 192.168.0.0/16

# 3. Create the Site-to-Site connection with an explicit, matched IPsec/IKE policy
az network vpn-connection create --name conn-onprem-to-hub --resource-group rg-networking-prod \
  --vnet-gateway1 vpngw-meridian-hub --local-gateway2 lng-meridian-onprem \
  --shared-key "<pre-shared-key>" --ipsec-encryption AES256 --ipsec-integrity SHA256

# 4. Enable active-active mode for higher throughput and faster failover
az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --set activeActive=true

# 5. Enable Point-to-Site VPN for field engineers, using Entra ID authentication
az network vnet-gateway update --name vpngw-meridian-hub --resource-group rg-networking-prod \
  --address-prefixes 172.16.0.0/24 --client-protocol OpenVPN

# 6. Verify connection status before considering the bootstrap complete
az network vpn-connection show --name conn-onprem-to-hub --resource-group rg-networking-prod \
  --query connectionStatus

# 7. (Planned, once the ExpressRoute business case matures) —
#    create the circuit and gateway ahead of the actual cutover
az network express-route create --name er-meridian --resource-group rg-networking-prod \
  --peering-location "Washington DC" --sku-tier Standard --bandwidth 1000
az network vnet-gateway create --name ergw-meridian-hub --resource-group rg-networking-prod \
  --vnet vnet-meridian-hub --gateway-type ExpressRoute --sku ErGw2AZ

# 8. Apply a route filter to Microsoft Peering from day one, avoiding
#    the unscoped route flood this chapter flagged as a real gotcha
az network route-filter create --name filter-m365-only --resource-group rg-networking-prod

Part 5 CLI Cheat Sheet#

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian Freight's on-premises Site-to-Site VPN tunnel, which had been stable for months, suddenly stops passing traffic after an unrelated change to the on-premises internet service provider contract. What's the most likely cause, and how would you confirm it?

Answer: The most likely cause is that the on-premises VPN device's public IP address changed as part of the ISP contract change — the Local Network Gateway resource in Azure still references the OLD IP address, so Azure is attempting to establish the tunnel against an address that no longer belongs to the on-premises device. Confirming it is straightforward: check the on-premises device's current public IP and compare it against the gateway-ip-address configured on the Local Network Gateway resource — a mismatch confirms the cause, and the fix is updating the Local Network Gateway's IP to match the new address.

Problem 2: A team configures an ExpressRoute circuit and Azure Private Peering successfully, confirms VNet connectivity works, but finds that traffic to a public Azure Storage account endpoint (not using Private Link) still routes over the public internet instead of the private ExpressRoute path. What's missing?

Answer: Microsoft Peering, configured separately from Azure Private Peering, is missing. Azure Private Peering only provides connectivity to VNets (IaaS resources) — reaching a PUBLIC PaaS endpoint like a Storage account's public endpoint over the private ExpressRoute path (rather than the public internet) requires Microsoft Peering to be configured as an additional, separate peering on the same circuit. This is a genuinely common gap: teams often assume "we have ExpressRoute working" covers all Microsoft connectivity, when in fact Private and Microsoft Peering are independent configurations serving different destination types.

Problem 3: Meridian Freight is evaluating whether to adopt ExpressRoute Premium specifically for its Global Reach capability, planning to connect its East Coast headquarters and a newly opened West Coast distribution center's on-premises networks to each other through Azure. A team member argues this is "using Azure as a workaround instead of a proper WAN link." Evaluate this framing.

Answer: The framing undersells a legitimate, commonly recommended architecture rather than identifying a real flaw. ExpressRoute Global Reach connecting two circuits over Microsoft's own global backbone is a genuine, supported use case specifically designed for this scenario — inter-site connectivity between two locations that both already have ExpressRoute circuits to Azure for their own separate reasons. It's frequently a lower-cost, lower-latency alternative to provisioning and maintaining a dedicated inter-site WAN link purely for site-to-site traffic, since it repurposes connectivity Meridian Freight is already paying for. The "workaround" framing would be fair if the ONLY reason for adopting ExpressRoute was inter-site connectivity — but since both sites need Azure connectivity anyway, Global Reach is additive value from infrastructure already justified on its own merits, not a substitute for a "proper" solution.

Problem 4: An architect recommends Virtual WAN Basic SKU for Meridian Freight's growing branch network, citing lower cost, without confirming the specific capabilities the design will eventually need. Six months later, the team needs ExpressRoute integration and finds Basic doesn't support it at all, requiring a migration to Standard. What should the original evaluation have included?

Answer: The original evaluation should have confirmed the FULL set of capabilities the design would need over its realistic lifetime, not just its capabilities at initial rollout — Basic's restriction to single-hub Site-to-Site VPN only is a hard functional ceiling, not a starting point that grows into Standard's capabilities automatically. Since ExpressRoute integration, transitive VNet-to-VNet routing, and NVA/Firewall hosting are all Standard-only, and these are common, foreseeable needs for a growing branch network (not exotic edge cases), the stronger original recommendation would have been Standard from the start — the cost difference between the two SKUs is a much smaller expense than a forced mid-project migration discovered only once a hard capability gap is hit in production planning.

Problem 5: Meridian Freight enables Point-to-Site VPN for field engineers using certificate-based authentication, issuing one shared root certificate to the whole fleet for simplicity. A laptop is later lost, and the security team is unable to revoke VPN access for that specific device without disabling VPN access for the entire fleet. What was the underlying design mistake, and what's the correct fix?

Answer: The underlying mistake was using one shared certificate (or a shared root without per-device issuance and revocation tracking) across the entire fleet, rather than issuing a distinct certificate per device that can be individually revoked. With a properly designed certificate hierarchy, revoking one lost device's certificate specifically would not affect any other device's access. The more robust fix going forward, though, is migrating to Entra ID-based P2S authentication entirely — it ties VPN access to each individual's Entra identity, letting a lost or compromised device's access be revoked the same way any other compromised credential is handled (disabling the account, revoking sessions via Part 2's Identity Protection), without any certificate-management infrastructure to get wrong in the first place.

Problem 6: Meridian Freight's on-premises network administrators report that their edge router's routing table has grown to contain thousands of routes shortly after Microsoft Peering was enabled on the company's ExpressRoute circuit, causing real performance concerns on aging router hardware. What's the cause, and what's the fix?

Answer: By default, Microsoft Peering advertises routes for the full catalog of Microsoft public services, most of which Meridian Freight likely never uses over that specific path — this is exactly the unscoped-by-default behavior a route filter exists to correct. The fix is creating a route filter that allows only the specific services actually needed (identified by their BGP community values) and applying it to the Microsoft Peering configuration, which reduces the advertised route count to just what's relevant rather than the entire, largely-unused catalog — directly addressing the router performance concern without needing any on-premises hardware upgrade.

Problem 7: A platform team scales up an ExpressRoute circuit's bandwidth ahead of an expected traffic increase, and a few months later, traffic patterns shift such that the higher bandwidth is no longer needed. An engineer attempts to scale the bandwidth back down to reduce cost and finds the operation isn't supported. What should have informed the original bandwidth decision, given this constraint?

Answer: ExpressRoute circuit bandwidth scaling is one-directional — a circuit can be scaled up in place without disruption, but scaling down requires decommissioning and recreating the circuit entirely, which is a genuinely disruptive operation involving new provisioning lead time with the connectivity provider. The original bandwidth decision should have accounted for this asymmetry explicitly: choosing a bandwidth tier based on a reasonably confident MINIMUM sustained need rather than a generous, "just in case" over-provisioning, since scaling up later when growth actually happens is cheap and non-disruptive, while scaling down from an overly generous initial choice is not — the cost of under-provisioning slightly and scaling up later is much lower than the cost of over-provisioning and being stuck with it.

Problem 8: Six months after going live with a single ExpressRoute circuit, Meridian Freight experiences a multi-hour outage of its connectivity provider's network, during which the on-premises legacy dispatch system is completely unreachable from Azure. No VPN fallback had been configured. What single design change would have prevented the business impact, even without eliminating the underlying provider outage itself?

Answer: Configuring a Site-to-Site VPN as a failover path alongside the ExpressRoute circuit, with routing preference set so traffic automatically prefers ExpressRoute when available but fails over to the VPN tunnel when it isn't, would have preserved connectivity (at VPN's lower bandwidth and higher latency, but functioning) throughout the provider outage rather than losing connectivity entirely. The underlying provider outage itself couldn't have been prevented from Azure's side — the achievable fix is architectural redundancy on Meridian Freight's own side, treating a single circuit exactly as the single point of failure this chapter identified, rather than assuming a resource with a strong SLA to Microsoft is inherently immune to failure at the connectivity provider layer, which is genuinely outside Microsoft's own SLA scope.

Summary and What's Next#

• Site-to-Site VPN, ExpressRoute, and Virtual WAN solve overlapping but genuinely distinct problems — cost-sensitive/quick setup, strict latency-consistency/high-bandwidth private connectivity, and global transit at scale, respectively.
• Route-based VPN is the correct default over policy-based for any new deployment — policy-based exists mainly for legacy device compatibility.
• ExpressRoute is private but NOT automatically encrypted — IPsec over ExpressRoute is a separate, explicit layer needed for compliance requiring encryption in transit.
• Azure Private Peering reaches VNets; Microsoft Peering reaches public Microsoft services — most organizations need both, configured as separate peerings on the same circuit.
• FastPath requires ErGw3AZ/ErGwScale gateways specifically, and ExpressRoute Global Reach turns Microsoft's own backbone into a legitimate inter-site WAN link between two circuits.
• Virtual WAN Standard, not Basic, is the correct default for production — Basic's single-hub VPN-only restriction excludes most of what makes Virtual WAN valuable.
• Entra ID-based Point-to-Site authentication is the strongest current option, tying VPN access revocation to the same identity governance (Part 2) already covering every other access decision.
• A route filter scopes Microsoft Peering to only the services actually needed, avoiding the unscoped-by-default flood of Microsoft's full public route catalog.
• ExpressRoute circuit bandwidth scales up non-disruptively but never back down — the initial tier choice should favor a confident minimum over generous over-provisioning.
• A circuit needs BOTH the Microsoft-side and connectivity-provider-side provisioning states to show "Provisioned" before it actually passes traffic end-to-end.
• A single ExpressRoute circuit is a real single point of failure — a second circuit or a tested Site-to-Site VPN failover path is the correct baseline for any critical production dependency, and ExpressRoute Direct exists for the rare case of needing very high bandwidth without a connectivity provider in the path at all.

Continue to Part 6 (06-networking-application-delivery.md) for the load balancing and application delivery layer that sits in front of the VNets this chapter just connected to the outside world.