Why Your Azure VM Can't Reach On-Premises: VPN vs ExpressRoute, Packet by Packet

October 6, 2026 · Azure Networking, Packet by Packet: NSGs, Route Tables, ASGs and Azure Firewall (part 6)

▶ Watch on YouTube & subscribe to The Stack Underflow

In the foundation video, a packet from app-1 to a server in the office was dropped: the route 10.0.0.0/8 said None. This video teaches Azure a route to the office: a site-to-site VPN, then ExpressRoute next to it, and then ExpressRoute becomes unavailable. There are no NSGs or firewall here, so every decision is routing. This page walks the same four packets with every route and the documentation behind it.

The one-line version: a gateway puts the office’s prefix into your effective routes, and the longest prefix wins. When the VPN and ExpressRoute advertise the same prefix, Azure prefers ExpressRoute. Private isn’t encrypted.

Last verified against Microsoft Learn: 5 October 2026. Prices are a snapshot read on 4 October 2026; this page is where they get updated.

New to GatewaySubnet, the local network gateway, MSEEs or BGP? The primer explains each word first: The Local Network Gateway Isn’t a Gateway: Azure Hybrid Networking Terms.

Different parts of one path

Fiber, MPLS, IPsec, VPN Gateway and ExpressRoute describe different parts of the end-to-end path, not five interchangeable products:

The same medium, often fiber, can carry internet access, Carrier Ethernet, MPLS or an ExpressRoute link. So ask four questions: what carries the packet, who transports it, is it protected, and how does it enter Azure?

The lab

The same virtual network and packet as the foundation video, written by hand for this video (not a Microsoft template). 198.51.100.10 is a documentation address.

A site-to-site VPN needs four objects: GatewaySubnet (/27 or larger; the lab plans a /26, as Microsoft’s hybrid design guide suggests when an ExpressRoute gateway will join), a VPN gateway with an AZ SKU and a Standard public IP, a local network gateway describing the office device (public IP or FQDN) and its prefixes, and a connection with the authentication and tunnel settings. The office device may sit behind NAT if it starts the tunnel.

Four packets, step by step

Every packet is the same: app-1 10.20.4.25 → 10.30.5.10, TCP 443. Only the gateways change.

Packet 1: no gateway, no route. With neither gateway in place, the app subnet has no route table, so only Azure’s system routes apply. Two routes contain 10.30.5.10: 10.0.0.0/8 → None (a reserved range that goes nowhere) and 0.0.0.0/0 → Internet. The /8 is more specific, so it wins. Dropped. To reach the office, something has to teach Azure a route.

Packet 2: through the site-to-site VPN. Only the VPN gateway exists. Azure uses the NIC’s effective routes: the system routes plus the routes learned through the gateway. Three routes contain 10.30.5.10: 10.30.0.0/16 → the VPN gateway (from the local network gateway’s prefixes), 0.0.0.0/0 → Internet, and 10.0.0.0/8 → None. The /16 is the most specific, so it wins. The gateway wraps the packet in IPsec, with keys that IKE negotiated, and sends it across the public internet to the office’s VPN device at 198.51.100.10, which unwraps it and passes it on. Allowed, through an encrypted tunnel. The way back: the reply needs a route back to Azure too, and on-premises routing decides it; here, the VPN again. Keep both directions on the same path.

Packet 3: VPN and ExpressRoute, same prefix. Both gateways exist. Four routes contain 10.30.5.10: 10.30.0.0/16 learned by the ExpressRoute gateway over BGP, 10.30.0.0/16 through the VPN gateway, 0.0.0.0/0 and 10.0.0.0/8. Both gateways learned the same prefix, and for the same prefix, Azure prefers ExpressRoute. The packet travels on Microsoft’s backbone to a Microsoft Enterprise Edge router (MSEE) at the Amsterdam peering location, then over your connectivity provider’s connection to your edge router. It doesn’t cross the public internet, but it isn’t encrypted by default. Allowed, over the private circuit. The VPN stays as the backup path.

Packet 4: ExpressRoute unavailable. ExpressRoute becomes unavailable, and Azure withdraws the routes it learned from the circuit. Three routes contain 10.30.5.10, as in packet 2, and 10.30.0.0/16 through the VPN gateway wins. Allowed, through the VPN’s IPsec tunnel. Same destination, different network path: the application didn’t change; the effective routes did.

VPN sizing and SKUs

• Microsoft recommends AZ SKUs for all new VPN gateways.
• Published aggregate benchmarks run from 650 Mbps (VpnGw1AZ) to 10 Gbps (VpnGw5AZ). They’re aggregates, not per tunnel.
• Up to 30 site-to-site tunnels, or 100 on VpnGw4AZ and VpnGw5AZ.
• The older non-AZ family, VpnGw1–5, is legacy: new creation has been blocked since 1 November 2025, and its published retirement date was 30 September 2026. The Basic SKU isn’t retiring; it’s for dev/test.
• Point-to-site is for individual users or devices; site-to-site, for a whole network.

ExpressRoute: the path

• VM → ExpressRoute gateway (in GatewaySubnet) → Microsoft’s backbone → an MSEE, a Microsoft Enterprise Edge router at the peering location → the provider → your edge router. Routes are exchanged over BGP.
• It never uses the public internet.
• Each circuit has two connections to two MSEEs, which Microsoft runs active-active, spreading flows across both. If one connection fails, the other keeps the circuit up.
• Bandwidth: provider circuits run from 50 Mbps to 10 Gbps; ExpressRoute Direct offers 10, 100 or 400 Gbps ports (400 Gbps in limited locations, enrollment required).
• Reach: a Standard circuit reaches every Azure region in its geopolitical area; Premium reaches all regions.

Four ways to plug into ExpressRoute

MPLS is one way a provider can carry your traffic. It isn’t ExpressRoute, and it isn’t encryption.

Private is not encrypted

ExpressRoute traffic isn’t encrypted by default; it just avoids the public internet.

• Use TLS in the application, always.
• If the network must encrypt too: MACsec (ExpressRoute Direct only, off by default) or IPsec over private peering (through Virtual WAN or a VPN gateway). Both can be used together.

Two kinds of redundancy

1. Inside the circuit: two links to two MSEEs, active-active. If one link fails, ExpressRoute keeps working on the other, and the VPN doesn’t take over.
2. A separate path: a site-to-site VPN can back up ExpressRoute private peering (with a route-based VPN gateway, not the Basic SKU). It takes over when the whole ExpressRoute path is unavailable and its routes are withdrawn.

Which path wins is still routing: longest prefix first, then ExpressRoute for the same prefix. Advertise a more specific prefix over the VPN, and the VPN carries that range (Pause & Prove 3).

Both directions

Routing is decided on both sides. If requests leave over ExpressRoute and replies return over the VPN, a stateful firewall can drop them, so make on-premises prefer the ExpressRoute routes too.

For maximum resiliency, Microsoft recommends two ExpressRoute circuits in two peering locations. And a general physical-diversity principle, not a Microsoft rule: two circuits sharing one duct can fail together.

DNS crosses the boundary too

On-premises DNS servers can’t reach Azure’s resolver at 168.63.129.16 over VPN or ExpressRoute. DNS Private Resolver fixes both directions: its inbound endpoint gives on-premises servers a private IP in the VNet to forward Azure names to, and its outbound endpoint with a forwarding ruleset sends Azure’s questions about on-premises names back.

Hundreds of sites: Virtual WAN

A regular VPN gateway supports up to 100 site-to-site tunnels on the largest SKUs. A Virtual WAN hub takes up to 1,000 branch connections (2,000 IPsec tunnels), and brings site-to-site, point-to-site, ExpressRoute, supported SD-WAN partner devices and Azure Firewall into one hub. Basic Virtual WAN is site-to-site VPN only.

What it costs

In the video: a VPN gateway runs hundreds to low thousands of dollars a month, and ExpressRoute into many thousands. The figures:

Pricing snapshot, read 4 October 2026, in US dollars. For ExpressRoute Direct, the circuit, gateway, data transfer and provider or colocation costs are extra. The fiber from your building to a peering location is a separate bill from a carrier. Check the current pricing page before you budget.

Which option fits?

Then come back to the four questions: what carries the packet, who transports it, is it protected, and how does it enter Azure? To go deeper: Azure Route Server, Global Reach and Microsoft peering. The video names them but doesn’t teach them.

Pause & Prove: the questions from the video

1. Overlapping ranges

The office is 10.20.0.0/16. The proposed Azure VNet is 10.20.10.0/24. What happens if you connect them with a site-to-site VPN and plain routing?

• A. Works: different sizes. The tempting one. A different prefix length isn’t a different network: every address in the /24 is also in the /16.
• B. Works over ExpressRoute only. The transport doesn’t matter. Both sides still claim the same addresses.
• C. Overlap: re-address first. ✓ The /24 sits inside the /16, so an address like 10.20.10.5 would mean two places. Pick a range used nowhere else. VPN Gateway NAT (VpnGw2AZ and up) can translate as a workaround, not a plan; peering can’t.
• D. Works if BGP is on. BGP advertises prefixes; it can’t make one address mean two places.

2. Is ExpressRoute encrypted? (also the Community poll)

Compliance asks: is traffic over our ExpressRoute circuit encrypted?

• A. No: add encryption. ✓ ExpressRoute isn’t encrypted by default. Use TLS in the application, and MACsec (ExpressRoute Direct) or IPsec over private peering if the network must encrypt too.
• B. Yes: it’s private. The tempting one. Private means it avoids the public internet, not that it’s encrypted.
• C. Yes: MACsec is the default. MACsec is only on ExpressRoute Direct, and it’s off by default.
• D. Only with Premium. The Premium add-on adds global reach and more routes, not encryption.

3. Which path wins? (the pinned question)

ExpressRoute advertises 10.10.0.0/16 to Azure. The backup VPN advertises 10.10.5.0/24. Which path does a packet to 10.10.5.10 take?

• A. ExpressRoute, always preferred. The tempting one. Azure prefers ExpressRoute only when both paths advertise the same prefix; the longest prefix is compared first.
• B. Both, load-balanced. Azure picks one best route per destination. Different prefixes are never treated as equal.
• C. Dropped. Two routes match, so the packet has somewhere to go.
• D. The VPN: longer prefix. ✓ The /24 is more specific than the /16, so it wins. Your backup is now the primary path for that range.

4. 400 stores

A retailer must connect 400 stores, each with an SD-WAN appliance, to Azure. What do you use?

• A. One VPN gateway. The tempting one, but the biggest VPN gateway SKUs top out at 100 site-to-site tunnels.
• B. A Virtual WAN hub. ✓ Built for many branches: up to 1,000 connections per hub, with integration for supported SD-WAN partner devices.
• C. ExpressRoute per store. Technically possible, but a circuit per store is far beyond what a store needs or costs.
• D. Point-to-site VPN. Point-to-site is for individual users and devices, not sites with routers.

Related Shorts

• This packet used to be dropped. What taught Azure a route to the office? (packet 2)
• The VPN and ExpressRoute both reach the office. Which one carries the packet? (packet 3)
• ExpressRoute is unavailable. How does the packet still reach the office? (packet 4)

Before / after this video

• Words first: The Local Network Gateway Isn’t a Gateway: Azure Hybrid Networking Terms
• Where this packet was dropped: Azure CIDR & Subnets (system routes, longest prefix, DNS)
• Earlier in the series: How Azure NSGs Allow or Deny a Packet, Azure Route Tables and NVAs, Azure Subnet NSG vs NIC NSG and How Azure Firewall Decides
• This is the last video in the series.

Sources

Read on 4 October 2026, and on 5 October 2026 where noted:

• Virtual network traffic routing: system routes and None, longest prefix match, user > BGP > system, gateway-learned routes with source “Virtual network gateway”
• About VPN Gateway configuration settings: GatewaySubnet name and size, the local network gateway
• What is Azure VPN Gateway?: site-to-site objects, IPsec/IKE over the public internet, Standard public IP
• VPN Gateway FAQ: public IPv4 for the on-premises device, NAT traversal when it starts the tunnel
• Site-to-site certificate authentication (read 5 October): the alternative to a pre-shared key
• About gateway SKUs: AZ SKUs, aggregate benchmarks, tunnel limits
• Gateway SKU consolidation: non-AZ VpnGw1–5 creation blocked since 1 Nov 2025, retirement date 30 Sep 2026, Basic not retiring
• About VPN Gateway NAT: overlapping address spaces on route-based connections, VpnGw2AZ and up
• ExpressRoute overview: two connections to two MSEEs, bandwidths, two circuits in two peering locations
• Designing for high availability with ExpressRoute (read 5 October): active-active, per-flow
• ExpressRoute circuits and peering (read 5 October): the circuit, its provider and peering location
• ExpressRoute connectivity models: not over the public internet, the four models
• ExpressRoute routing requirements: BGP with the MSEEs, Standard vs Premium reach
• ExpressRoute encryption: not encrypted by default, MACsec, IPsec over private peering
• Configure ExpressRoute and site-to-site coexisting connections: VPN as a failover path, private peering only, not Basic, prefer the ExpressRoute routes on-premises
• Use S2S VPN as a backup for ExpressRoute private peering: “Azure will prefer routing over ExpressRoute” for the same route
• What is Azure DNS Private Resolver? and What is IP address 168.63.129.16?: inbound and outbound endpoints, Azure-provided DNS
• Virtual WAN FAQ: 1,000 connections / 2,000 IPsec tunnels per hub, what a hub integrates, Basic is site-to-site only
• Hybrid connectivity design guide: /26 GatewaySubnet when both gateways coexist, point-to-site, typical monthly ranges
• ExpressRoute pricing: ExpressRoute Direct port-pair fees, Zone 1
• Virtual network FAQ: peered VNets can’t overlap
• IETF: RFC 4301 (IPsec), RFC 7296 (IKEv2), RFC 3031 (MPLS), RFC 4364 (BGP/MPLS IP VPNs), RFC 4271 (BGP)

Change notes

• 6 Oct 2026: first published.

Not affiliated with or endorsed by Microsoft. Azure is a trademark of Microsoft Corporation. SKUs, limits and prices can change. Found a mistake? Tell us in the video’s comments and we’ll correct this page.