Post

Advanced Azure Networking

Posted
By Fábio Ferreira
10 min read
Advanced Azure Networking

Overview

After mastering VNets and NSGs, the next layer involves connecting disparate networks, securely accessing PaaS services, and orchestrating hybrid deployments. This guide covers routing strategies, inter-VNet connectivity, private access patterns, and enterprise-grade hybrid solutions.

Routing & User-Defined Routes (UDR)

System Routes (Azure-Managed)

Azure automatically creates system routes for every VNet:

  • Local VNet: Intra-VNet traffic routed directly
  • VNet Peering: Traffic to peered VNets (if peering is configured)
  • 0.0.0.0/0 → Internet: Default route to the internet
  • Reserved RFC1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 (dropped if not explicitly routed)

Route Tables (UDR)

A Route Table is a regional Azure resource containing custom routes. It associates with subnets (not VNets or NICs), and a single table can apply to multiple subnets.

Route Anatomy:

Component Example
Address Prefix Destination CIDR (e.g., 10.0.3.0/24, 0.0.0.0/0)
Next Hop Type Virtual appliance (NVA), Virtual network gateway, Virtual network, Internet, None (drop)
Next Hop Address IP of the NVA (required only for Virtual appliance type)

Critical: To route traffic through an NVA, enable IP forwarding on the NVA’s NIC—otherwise packets are dropped at the network interface.

Route Precedence (Most-Specific-First)

1
2
3

1. UDR (Custom routes)         ← Always wins
2. BGP (ExpressRoute, dynamic VPN)
3. System routes               ← Azure fallback

Common Pattern: Force all outbound traffic through a Firewall NVA by creating a UDR: 0.0.0.0/0 → 10.0.0.4 (NVA IP) on target subnets.

VNet Peering

VNet Peering connects two VNets privately over the Azure backbone without requiring a gateway.

Core Characteristics

  • ✅ Cross-region, cross-subscription, cross-tenant supported
  • ❌ No IP overlap between peered VNets
  • ❌ Non-transitive: If VNet A peers with B and B peers with C, A cannot reach C directly (requires hub-and-spoke with NVA/Firewall or Virtual WAN)
  • ❌ Not encrypted by default (private on Microsoft backbone, but unencrypted in transit)—optional encryption available
  • Bilateral: Peering must be configured A→B and B→A (both directions required for “Connected” state)

Peering Options

Option Effect
Allow virtual network access Enables L3 traffic between peered VNets (default: enabled)
Allow forwarded traffic Peered VNet accepts traffic transited via an NVA from the peer
Allow gateway transit Hub VNet shares its VPN/ExpressRoute gateway with the peer
Use remote gateways Spoke VNet uses the hub’s gateway (only one peer can be configured this way)

⚠️ Gateway transit is incompatible with VPN Gateway Basic SKU. Each spoke can consume only one remote gateway at a time.

Private Access to PaaS Services

Service Endpoints (Subnet-Level)

Service Endpoints allow a subnet to reach public PaaS services (Storage, SQL, KeyVault) via the Microsoft backbone without requiring a public IP.

  • Configured at subnet level: Subnet > Service endpoints > Microsoft.Storage
  • Affects all resources of a given type (granularity limited to service type)
  • Resource-side configuration: Service > Networking > Selected networks > Add virtual network
  • Optional Service Endpoint Policy: restricts access to specific resources (e.g., only mystorageaccount is accessible)
  • ❌ Does not work for on-premises (the endpoint subnet must be Azure-based)

Private Endpoints & Private Link

A modern, more powerful approach offering resource-level, identity-aware access:

  • Private Link: The underlying technology enabling Azure services to expose a private IP in your VNet
  • Private Endpoint: The actual NIC deployed in your subnet, carrying the private IP to the service

Comparison:

  Service Endpoint Private Endpoint
Scope Subnet Individual resource
Granularity All service accounts of type One specific resource
Private IP ❌ ✅
On-premises Access (via VPN/ExpressRoute) ❌ ✅
DNS Integration ❌ ✅ (via Private DNS Zone)
Cost Free Paid per endpoint + data egress
Microsoft Recommendation Legacy Modern, preferred

Critical: When using Private Endpoints, integrate a Private DNS Zone (e.g., privatelink.blob.core.windows.net, privatelink.database.windows.net) so the public FQDN resolves to the private IP. Without it, resolution returns the public IP.

Resource Firewalls

PaaS resources with public endpoints (Storage, SQL, KeyVault, App Service) can restrict access on the resource side:

Configuration Path: Resource > Networking > Public network access

Options:

  • Disabled: Only Private Endpoint access allowed
  • Enabled from selected virtual networks and IP addresses: Whitelist specific VNets (via Service Endpoint) and IP/CIDR ranges
  • Enabled from all networks: Open to the internet (default historically; avoid in production)

Private Endpoint access bypasses this restriction and always works if the resource allows it.

Hybrid Connectivity

VPN Gateway

A managed gateway enabling IPsec/IKE tunnels between on-premises and Azure, or between VNets and remote clients.

Site-to-Site (S2S)

Connects an on-premises VPN device (router, firewall) to Azure:

Required Components (deployment order matters):

  1. GatewaySubnet (exact name, /27 minimum) in the VNet
  2. VPN Gateway (VpnGw1AZ+ SKU, route-based, Standard Public IP)
  3. Local Network Gateway (represents on-premises: public IP + LAN address ranges)
  4. VPN Connection (links VPN Gateway to Local Network Gateway with shared key)

Deployment Mnemonic: GatewaySubnet → VPN Gateway → Local Network Gateway → Connection. The Local Network Gateway is created after the VPN Gateway because the connection requires both endpoints.

Enable BGP on the VPN Gateway for dynamic routing (automatically adapts to topology changes at the branch office).

Point-to-Site (P2S)

Enables individual users to connect from workstations via a VPN client:

  • Authentication: Certificate, Microsoft Entra ID (OpenVPN), RADIUS
  • Protocols: OpenVPN (TCP/UDP, recommended), IKEv2, SSTP

⚠️ Client Update Trap: When VNet topology changes (new peering, gateway transit, new routed subnets), existing P2S client configurations do not automatically include new routes. Mandatory action: VPN Gateway > Point-to-site configuration > Download VPN client and reinstall on all workstations. The tunnel works for the original VNet but not newly peered VNets until the client is updated.

Policy-Based vs. Route-Based

Type Protocol Supports P2S? Multi-Tunnel S2S? BGP?
Policy-based IKEv1 ❌ NO ❌ Single tunnel ❌
Route-based ⭐ IKEv2 ✅ YES ✅ Multi-tunnel ✅

Critical: P2S requires route-based type. If a gateway is policy-based, it must be deleted and recreated as route-based (no in-place conversion). The type is immutable at creation.

SKUs (2026 Update)

SKU Capability Status
Basic Dev/test ❌ No BGP, no Availability Zones, no gateway transit
VpnGw1AZ–VpnGw5AZ Production ✅ Recommended (Availability Zone support, BGP, active-active capable)
Standard, High Performance Legacy 🚨 Retired June 30, 2026 (auto-upgrade to VpnGw1AZ or VpnGw2AZ)
VpnGw1–5 (non-AZ) Legacy 🚨 Creation blocked since Nov 1, 2025 (deprecation after Sept 2026)

High Availability

  • Active-Standby (default): One active instance, one passive; ~10-second failover
  • Active-Active: Two active instances, two tunnels; doubled bandwidth and improved resilience

ExpressRoute

Dedicated, private connectivity between on-premises and Azure via a connectivity partner—never traverses the public internet.

Key Components:

  • ExpressRoute Circuit: Logical link (bandwidth tier, billing model)
  • Peering (BGP required):
    • Private Peering: Access to Azure VNets (most common)
    • Microsoft Peering: Access to public PaaS services (Microsoft 365, public SQL Database, etc.)
  • ExpressRoute Gateway: Deployed in GatewaySubnet, attached to the circuit

Billing Models:

  • Metered: Fixed rate + egress traffic charges
  • Unlimited: Fixed flat rate, unlimited traffic
  • Local: Lower cost, limited to regions near peering location

Advanced Variants:

  • ExpressRoute Direct: Direct connection (10/100 Gbps) without partner intermediary
  • ExpressRoute Global Reach: Interconnects two on-premises sites via the Azure backbone
  • FastPath: Gateway bypass for data plane, reducing latency

Virtual WAN (vWAN)

A managed, global service simplifying large-scale hub-and-spoke deployments across multiple regions and sites.

Architecture:

  • 1 Virtual WAN resource (global scope)
  • 1+ Virtual Hubs per region (Microsoft-managed, contains integrated VPN/ExpressRoute gateways)
  • Hub-to-hub connectivity automatically established
  • Connection support: VNets, S2S VPN, P2S VPN, ExpressRoute, inter-hub

SKUs:

  • Basic: S2S VPN only
  • Standard: Full-featured (P2S, ExpressRoute, inter-hub, custom routing, secured hub with Azure Firewall)

Use Case: Enterprise with multi-region/multi-site infrastructure avoids manually configuring 50+ peerings and 10+ VPN Gateways.

DNS Resolution

Public DNS Zone

Host and resolve your public domain within Azure DNS:

Process:

  1. Register domain at a registrar (GoDaddy, OVH, Azure App Service Domains)
  2. Create a DNS Zone in Azure (DNS zones > Create)
  3. Azure provides 4 NS records
  4. Update registrar nameservers to point to these 4 NS records
  5. Add records (A, CNAME, MX, TXT, SRV) to the zone

Zone File Import (BIND):

  • ✅ Supported: Azure CLI (az network dns zone import) or Azure Portal
  • ❌ Not supported: Azure PowerShell, ARM templates, Cloud Shell as separate tool

Private DNS Zone

Internal name resolution for VNets without maintaining your own DNS server:

Integration:

  • Virtual Network Link: Connects a Private DNS Zone to one or more VNets
  • Registration enabled: VMs auto-register their records (only one VNet per zone can auto-register)
  • Resolution-only: VMs resolve but don’t auto-register

Common Use Case: Integration with Private Endpoints. Create zones named privatelink.<service> depending on resource type:

  • privatelink.blob.core.windows.net (Storage)
  • privatelink.database.windows.net (SQL Database)
  • privatelink.azurewebsites.net (App Service)

Azure DNS Private Resolver

Managed hybrid DNS forwarding service (replaces custom DNS forwarder VMs):

Two Endpoint Types (deployed in dedicated /28 subnet):

Endpoint Direction Purpose
Inbound On-prem → Azure Private IP in Azure; on-prem DNS servers forward queries to it. Resolves Private DNS Zones.
Outbound Azure → On-prem Azure VMs forward queries to on-prem DNS servers via a Ruleset.

DNS Forwarding Ruleset:

  • Container of rules (up to 1000): domain → target DNS server IP
  • Example: corp.contoso.com → 10.1.0.10 (on-prem domain controller)
  • Links to outbound endpoints and VNets

Hybrid Architecture Example:

1
2

On-prem DNS  ──forward──>  Inbound endpoint (private IP)  →  resolves privatelink.* zones
Azure VM   ──query──>  Outbound endpoint  ──ruleset──>  on-prem DNS (corporate domains)

Portal Examples

Create UDR with NVA

  1. Create Route Table: Route tables > Create (select VNet region)
  2. Add Route: Address prefix = 0.0.0.0/0, Next hop = Virtual appliance, enter NVA IP
  3. Enable IP Forwarding: NVA NIC → IP configurations > Enable IP forwarding
  4. Associate Subnet: Route table > Subnets > Associate → select target subnet

Configure VNet Peering

  1. VNet A: Peerings > Add peering
  2. Fill Details: Configure peering (portal may create both directions if you have permissions on both VNets)
  3. Enable Options as needed:
    • Allow forwarded traffic (if NVA in spoke)
    • Allow gateway transit (on hub)
    • Use remote gateways (on spoke)

Service Endpoint Setup

  1. Subnet: Service endpoints > Add Microsoft.Storage
  2. Storage Account: Networking > Selected networks > Add existing virtual network

Private Endpoint & Integration

  1. Storage Account: Networking > Private endpoint connections > Create private endpoint
  2. Configuration: Select VNet, subnet, sub-resource (blob, file, etc.)
  3. DNS Integration: ✅ Check “Integrate with private DNS zone”
  4. Verification: From VM in VNet: nslookup mystorageaccount.blob.core.windows.net → should return private IP

S2S VPN Gateway

  1. VPN Gateway: Create (GatewaySubnet required first, SKU VpnGw1AZ+, Standard Public IP)
  2. Local Network Gateway: Create (on-prem public IP + LAN address ranges)
  3. Connection: VPN Gateway > Connections > Add (Site-to-site, shared key, enable BGP if desired)
  4. On-Prem Configuration: Configure matching IPsec parameters on the firewall/router

Storage Firewall Configuration

  1. Storage Account: Networking > Public network access > Enabled from selected VNets and IPs
  2. Add VNet: Enables Service Endpoint automatically
  3. Authorized IPs: Add corporate IP ranges
  4. Exceptions Tab: “Allow trusted Microsoft services” → leave enabled for Backup/Monitoring
  1. Create Private DNS Zone: Private DNS zones > Create (e.g., privatelink.blob.core.windows.net)
  2. Virtual Network Link: Virtual network links > Add → select VNet
  3. Auto-Registration: Check only if this VNet should auto-register VM records
  4. Records: Private Endpoint automatically populates records in the zone

Summary: Advanced networking goes beyond basic VNets and NSGs to encompass multi-site routing, inter-VNet connectivity, secure PaaS access, and hybrid architectures. Master UDRs, peering, Private Endpoints, VPN/ExpressRoute, and DNS for enterprise deployments.

Cloud, Azure-104
azure networking routing vpn expressroute DNS hybrid
This post is licensed under CC BY-NC-ND 4.0 by the author.