Microsoft Azure — VNet Peering & VPN Gateway

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers vnet peering & vpn gateway with production-ready configurations, best practices, and hands-on examples.

Why VNet Peering and VPN Gateway Exist

In Azure, VNet Peering and VPN Gateway solve two distinct connectivity problems. VNet Peering connects virtual networks within the same Azure region (or across regions with Global Peering) using Microsoft's backbone — no internet, no encryption, but low latency and high bandwidth. VPN Gateway connects on-premises networks or other clouds to Azure over the public internet via IPsec tunnels. Confusing the two leads to outages: peering doesn't encrypt traffic, and VPN Gateway can't peer VNets without a gateway transit. Use peering for intra-Azure traffic; use VPN Gateway for hybrid connectivity. Never use VPN Gateway to connect two Azure VNets in the same region — that's what peering is for.

#!/bin/bash
# Create two VNets and peer them
az network vnet create --resource-group rg-prod --name vnet-eastus --address-prefix 10.0.0.0/16 --location eastus
az network vnet create --resource-group rg-prod --name vnet-westus --address-prefix 10.1.0.0/16 --location westus

# Peer eastus to westus
az network vnet peering create --resource-group rg-prod --name eastus-to-westus --vnet-name vnet-eastus --remote-vnet vnet-westus --allow-vnet-access

# Peer westus to eastus
az network vnet peering create --resource-group rg-prod --name westus-to-eastus --vnet-name vnet-westus --remote-vnet vnet-eastus --allow-vnet-access

VNet Peering: Configuration and Gotchas

VNet Peering requires two peerings (one in each direction) to allow bidirectional traffic. You must set allowVirtualNetworkAccess to true on both sides. Key gotchas: overlapping address spaces cause peering to fail — Azure validates no overlap at creation time. Also, peering does not automatically route traffic through a firewall unless you configure user-defined routes (UDRs). For production, always use a hub-spoke model: hub VNet contains shared services (firewall, VPN gateway), spoke VNets peer to hub. Enable allowGatewayTransit on hub and useRemoteGateways on spokes to route spoke traffic through the hub's VPN gateway. This avoids deploying a gateway per spoke.

#!/bin/bash
# Hub VNet with gateway subnet
az network vnet create --resource-group rg-prod --name hub-vnet --address-prefix 10.0.0.0/16 --location eastus
az network vnet subnet create --resource-group rg-prod --vnet-name hub-vnet --name GatewaySubnet --address-prefix 10.0.1.0/27

# Spoke VNet
az network vnet create --resource-group rg-prod --name spoke-vnet --address-prefix 10.1.0.0/16 --location eastus

# Peer spoke to hub with gateway transit
az network vnet peering create --resource-group rg-prod --name spoke-to-hub --vnet-name spoke-vnet --remote-vnet hub-vnet --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways

# Peer hub to spoke
az network vnet peering create --resource-group rg-prod --name hub-to-spoke --vnet-name hub-vnet --remote-vnet spoke-vnet --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit

VPN Gateway: SKUs, Throughput, and SLA

Azure VPN Gateway comes in three SKU families: Basic, VpnGw1-5, and VpnGw1-5AZ (Availability Zone). Basic is for dev/test only — no BGP, no active-active, no SLA. For production, use VpnGw1AZ or higher. Throughput ranges from 100 Mbps (Basic) to 10 Gbps (VpnGw5AZ). The SLA is 99.95% for active-active deployments, 99.9% for active-standby. Always deploy active-active for production: two instances in different zones (if using AZ SKU) or different fault domains. This halves failover time from ~30 seconds to near-zero. Also, choose policy-based vs. route-based: route-based (IKEv2) is required for BGP and most modern scenarios. Policy-based is legacy and limited to one tunnel.

#!/bin/bash
# Create a VNet with GatewaySubnet
az network vnet create --resource-group rg-prod --name vnet-hub --address-prefix 10.0.0.0/16 --location eastus
az network vnet subnet create --resource-group rg-prod --vnet-name vnet-hub --name GatewaySubnet --address-prefix 10.0.1.0/27

# Create public IP for active-active
az network public-ip create --resource-group rg-prod --name gw-pip1 --sku Standard --allocation-method Static --zone 1 2 3
az network public-ip create --resource-group rg-prod --name gw-pip2 --sku Standard --allocation-method Static --zone 1 2 3

# Create VPN gateway (active-active, VpnGw1AZ)
az network vnet-gateway create --resource-group rg-prod --name vpn-gw --vnet vnet-hub --public-ip-addresses gw-pip1 gw-pip2 --sku VpnGw1AZ --gateway-type Vpn --vpn-type RouteBased --active-active --enable-bgp

Site-to-Site VPN: On-Premises to Azure

Site-to-Site (S2S) VPN connects your on-premises network to Azure via IPsec. You need a VPN device on-premises that supports IKEv1 or IKEv2. Azure supports both, but IKEv2 is preferred for stability and BGP support. Configure the connection with a shared key (PSK) and specify the on-premises VPN device's public IP. For production, use BGP to exchange routes dynamically — this avoids static route maintenance and enables automatic failover if you have multiple tunnels. Also, enable custom IPsec/IKE policies to match your on-premises device's settings; mismatched parameters cause tunnel drops.

#!/bin/bash
# Local network gateway (on-premises)
az network local-gateway create --resource-group rg-prod --name onprem-gw --gateway-ip-address 203.0.113.1 --local-address-prefixes 192.168.0.0/16

# Create VPN connection
az network vpn-connection create --resource-group rg-prod --name s2s-connection --vnet-gateway1 vpn-gw --local-gateway2 onprem-gw --shared-key 'MySuperSecretKey123!' --enable-bgp

# View connection status
az network vpn-connection show --resource-group rg-prod --name s2s-connection --query 'connectionStatus'

Point-to-Site VPN: Remote User Access

Point-to-Site (P2S) VPN allows individual clients (Windows, macOS, Linux) to connect to Azure VNets. Azure supports SSTP, OpenVPN, and IKEv2. For production, use OpenVPN or IKEv2 — SSTP is Windows-only and has throughput limits. Deploy Azure AD authentication for P2S to avoid managing certificates. P2S is ideal for remote developers or administrators who need temporary access. However, for large-scale remote access, consider Azure Virtual Desktop or a third-party VPN solution. P2S scales to 128 concurrent connections per gateway instance (active-active doubles that).

#!/bin/bash
# Enable P2S on existing VPN gateway
az network vnet-gateway update --resource-group rg-prod --name vpn-gw --vpn-client-configuration '{"vpnClientProtocols":["OpenVPN"],"vpnClientAddressPool":{"addressPrefixes":["172.16.0.0/24"]}}'

# Generate VPN client configuration
az network vnet-gateway vpn-client generate --resource-group rg-prod --name vpn-gw --authentication-method EapTls

# Download the package (outputs URL)
az storage blob download --account-name mystorage --container-name vpnconfig --name openvpn.zip --file ./openvpn.zip

BGP with VPN Gateway: Dynamic Routing and Redundancy

BGP (Border Gateway Protocol) enables dynamic route exchange between Azure VPN Gateway and on-premises routers. Without BGP, you must define static routes in local network gateways — any change requires manual updates. With BGP, Azure advertises VNet prefixes and learns on-premises prefixes automatically. BGP also enables active-active failover: if one tunnel drops, BGP withdraws routes and traffic shifts to the other tunnel. To use BGP, enable it on the VPN gateway and assign a custom Azure ASN (private ASN range 64512-65534). On-premises must also support BGP.

#!/bin/bash
# Enable BGP on existing gateway
az network vnet-gateway update --resource-group rg-prod --name vpn-gw --enable-bgp --asn 65000

# Create local gateway with BGP
az network local-gateway create --resource-group rg-prod --name onprem-gw --gateway-ip-address 203.0.113.1 --local-address-prefixes 192.168.0.0/16 --asn 65001 --bgp-peering-address 192.168.0.1

# Update connection to use BGP
az network vpn-connection update --resource-group rg-prod --name s2s-connection --enable-bgp

Monitoring and Troubleshooting Connectivity

Azure provides several tools to monitor VNet Peering and VPN Gateway health. For peering, check peeringState — it should be Connected. If it's Initiated, the reverse peering is missing. For VPN, use az network vnet-gateway show to check provisioning state and az network vpn-connection show for connection status. Enable diagnostic logs for VPNGateway to capture IKE negotiations and tunnel drops. Use Network Watcher's VPN troubleshoot feature to run diagnostics on a connection. For peering, use IP flow verify to test traffic between VMs. Common issues: NSG blocking traffic, UDR misconfigurations, and address space overlap.

#!/bin/bash
# Check VPN connection status
az network vpn-connection show --resource-group rg-prod --name s2s-connection --query '{status: connectionStatus, egressBytes: egressBytesTransferred, ingressBytes: ingressBytesTransferred}'

# Run VPN troubleshoot (requires Network Watcher)
az network watcher troubleshoot start --resource-group rg-prod --resource vpn-gw --resource-type VnetGateway --storage-account mystorage --storage-path https://mystorage.blob.core.windows.net/vpnlogs

# Check peering state
az network vnet peering show --resource-group rg-prod --vnet-name vnet-eastus --name eastus-to-westus --query 'peeringState'

Cost Optimization: Peering vs. VPN Gateway

VNet Peering is free for traffic within the same region (only egress charges apply). Global Peering incurs egress costs similar to inter-region traffic. VPN Gateway costs include hourly gateway hours (even when idle) and data transfer out. For production, a VpnGw1AZ gateway costs ~$0.28/hour (~$200/month) plus data egress. Peering is cheaper for high-volume intra-Azure traffic. Use VPN Gateway only for hybrid connectivity. To optimize, consolidate multiple VPN connections into a single gateway using BGP and multiple local gateways. Also, consider Azure Virtual WAN for large-scale hub-spoke topologies — it can reduce costs by centralizing routing.

#!/bin/bash
# Estimate monthly cost for VpnGw1AZ active-active
az consumption prices list --query "[?contains(productName, 'VPN Gateway') && contains(skuName, 'VpnGw1AZ')].{price: unitPrice, currency: currencyCode}" --output table

# Estimate egress costs for peering (per GB)
az consumption prices list --query "[?contains(productName, 'Virtual Network Peering')].{price: unitPrice, currency: currencyCode}" --output table

Security: Network Segmentation and Encryption

VNet Peering traffic stays within Azure's backbone and is not encrypted by default. For sensitive workloads, use application-level encryption (TLS) or deploy Azure Firewall to inspect traffic. VPN Gateway encrypts traffic with IPsec (AES-256, SHA-256). For P2S, use OpenVPN with TLS 1.2+. Always use NSGs and Azure Firewall to restrict traffic between peered VNets. Never rely solely on peering for security — it's a routing construct, not a security boundary. Also, enable DDoS Protection Standard on hub VNets to protect against volumetric attacks.

#!/bin/bash
# Create NSG to restrict traffic from spoke to hub
az network nsg create --resource-group rg-prod --name spoke-nsg --location eastus
az network nsg rule create --resource-group rg-prod --nsg-name spoke-nsg --name deny-hub --priority 100 --direction Inbound --source-address-prefixes 10.0.0.0/16 --destination-port-ranges '*' --access Deny

# Associate NSG with spoke subnet
az network vnet subnet update --resource-group rg-prod --vnet-name spoke-vnet --name default --network-security-group spoke-nsg

Global VNet Peering: Cross-Region Connectivity

Global VNet Peering connects VNets across Azure regions. It uses Microsoft's backbone, so latency is lower than internet-based VPNs. However, there are limitations: you cannot use remote gateways across global peering (no gateway transit). Also, you cannot peer VNets in the same region if they are in different deployment models (classic vs. ARM). Global peering supports transitive routing only if you use a hub in one region and spokes in others, but the hub's gateway cannot be used by spokes in other regions. For cross-region connectivity with gateway transit, use VPN Gateway or ExpressRoute.

#!/bin/bash
# Peer VNets in different regions
az network vnet peering create --resource-group rg-prod --name eastus-to-westeurope --vnet-name vnet-eastus --remote-vnet /subscriptions/.../resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/vnet-westeurope --allow-vnet-access

# Note: remote gateway transit is not supported for global peering
az network vnet peering create --resource-group rg-prod --name westeurope-to-eastus --vnet-name vnet-westeurope --remote-vnet /subscriptions/.../resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/vnet-eastus --allow-vnet-access

ExpressRoute vs. VPN Gateway: When to Use Which

ExpressRoute provides a private, dedicated connection to Azure with higher bandwidth (up to 100 Gbps) and lower latency than VPN. It's ideal for large-scale hybrid deployments, mission-critical workloads, and compliance requirements. VPN Gateway is cheaper and faster to deploy but limited by internet bandwidth and reliability. Use ExpressRoute for production data centers; use VPN for branch offices, dev/test, or as a backup link. You can combine both: ExpressRoute as primary, VPN as failover (using BGP route preference). ExpressRoute requires a connectivity provider and longer provisioning time (weeks vs. hours).

#!/bin/bash
# Create ExpressRoute gateway (same VNet as VPN gateway? Not recommended)
# Instead, use separate VNets for ExpressRoute and VPN, then peer them.
# Configure BGP to prefer ExpressRoute (lower MED)
az network vnet-gateway update --resource-group rg-prod --name er-gw --asn 65000
az network local-gateway create --resource-group rg-prod --name onprem-er --gateway-ip-address 203.0.113.2 --asn 65001 --bgp-peering-address 192.168.0.2
az network vpn-connection create --resource-group rg-prod --name er-connection --vnet-gateway1 er-gw --local-gateway2 onprem-er --shared-key 'secret' --enable-bgp --routing-weight 100

# VPN connection with higher weight (less preferred)
az network vpn-connection create --resource-group rg-prod --name vpn-backup --vnet-gateway1 vpn-gw --local-gateway2 onprem-gw --shared-key 'secret' --enable-bgp --routing-weight 10

Production Patterns: Hub-Spoke with Hybrid Connectivity

The recommended production pattern is a hub-spoke topology with a VPN Gateway (or ExpressRoute) in the hub. Spoke VNets peer to the hub and use remote gateways for hybrid connectivity. This centralizes egress, security (Azure Firewall), and monitoring. For high availability, deploy active-active VPN gateways and use BGP with multiple tunnels. For disaster recovery, replicate the hub in a secondary region and use global peering or VPN between hubs. Use Azure Policy to enforce peering configurations (e.g., deny peering without gateway transit). This pattern scales to hundreds of spokes.

#!/bin/bash
# Primary hub in eastus, secondary hub in westus
az network vnet create --resource-group rg-prod --name hub-eastus --address-prefix 10.0.0.0/16 --location eastus
az network vnet create --resource-group rg-prod --name hub-westus --address-prefix 10.1.0.0/16 --location westus

# Peer hubs for DR
az network vnet peering create --resource-group rg-prod --name eastus-to-westus --vnet-name hub-eastus --remote-vnet hub-westus --allow-vnet-access
az network vnet peering create --resource-group rg-prod --name westus-to-eastus --vnet-name hub-westus --remote-vnet hub-eastus --allow-vnet-access

# Spoke peers to both hubs (for DR)
az network vnet peering create --resource-group rg-prod --name spoke-to-eastus --vnet-name spoke-vnet --remote-vnet hub-eastus --allow-vnet-access --use-remote-gateways
az network vnet peering create --resource-group rg-prod --name spoke-to-westus --vnet-name spoke-vnet --remote-vnet hub-westus --allow-vnet-access --use-remote-gateways

Azure Virtual WAN: Managed Global Transit Network Architecture

Azure Virtual WAN is a managed networking service that brings together networking, security, and routing functionalities into a single operational hub. It replaces the manual hub-spoke setup with a Microsoft-managed virtual hub that automatically connects branches (via S2C VPN), remote users (P2S VPN), ExpressRoute circuits, and VNets. Virtual WAN eliminates the need to configure VNet peering, UDRs, and VPN tunnels manually. In production, Virtual WAN is ideal for large enterprises with dozens of VNets and branches. It supports up to 2000 VNet connections per hub and can scale to hundreds of gigabits. Key features: automatic routing, built-in Azure Firewall integration, encrypted ExpressRoute, and any-to-any connectivity. Deploy Virtual WAN in regions where you have major workloads, then connect spoke VNets and branches. Use BGP for dynamic routing and set routing preferences (ExpressRoute > VPN). Virtual WAN also provides centralized diagnostics: enable diagnostic logs for virtual hubs, VPN gateways, and ExpressRoute gateways. Monitor hub routing tables, BGP peer status, and gateway metrics. For disaster recovery, deploy Virtual WAN hubs in multiple regions and configure inter-hub routing. However, Virtual WAN adds cost over manual hub-spoke — evaluate the operational overhead savings vs. additional cost before migrating.

#!/bin/bash
# Create Virtual WAN
az network vwan create \
  --resource-group rg-prod \
  --name prod-vwan \
  --location eastus \
  --type Standard

# Create virtual hub
az network vhub create \
  --resource-group rg-prod \
  --name hub-eastus \
  --vwan prod-vwan \
  --location eastus \
  --address-prefix 10.0.0.0/24 \
  --sku Standard

# Connect spoke VNet to hub
az network vhub connection create \
  --resource-group rg-prod \
  --vhub-name hub-eastus \
  --name spoke-connection \
  --remote-vnet /subscriptions/.../resourceGroups/rg-prod/providers/Microsoft.Network/virtualNetworks/spoke-vnet

# Create S2S VPN gateway in hub
az network vpn-gateway create \
  --resource-group rg-prod \
  --name vpn-gw \
  --location eastus \
  --vhub hub-eastus \
  --sku VpnGw1AZ

# Enable diagnostics on hub
az monitor diagnostic-settings create \
  --name vhub-diag \
  --resource /subscriptions/.../virtualHubs/hub-eastus \
  --workspace /subscriptions/.../workspaces/law-prod \
  --logs '[
    {"category": "GatewayDiagnosticLog", "enabled": true},
    {"category": "TunnelDiagnosticLog", "enabled": true},
    {"category": "RouteDiagnosticLog", "enabled": true},
    {"category": "IKEDiagnosticLog", "enabled": true}
  ]'

VPN Gateway Diagnostic Logs and BGP Monitoring Deep Dive

Azure VPN Gateway provides comprehensive diagnostic logs that are essential for troubleshooting tunnel drops, BGP peering issues, and performance problems. Key log categories include GatewayDiagnosticLog (gateway operations), TunnelDiagnosticLog (IPsec tunnel events), RouteDiagnosticLog (routing changes), and IKEDiagnosticLog (IKE handshake details). In production, enable all diagnostic categories and send them to Log Analytics. Use KQL queries to correlate events across categories — for example, an IKE negotiation failure followed by a tunnel disconnect. Monitor BGP peering status using Azure Monitor metrics: BGP Peer Status, Routes Advertised, and Routes Learned. Set up alerts for BGP session drops and route flapping. Use the BGP diagnostics page in the portal to view learned routes, advertised routes, and BGP peers — export to CSV for analysis. Common issues detected via logs: mismatched IKE parameters (check IKEDiagnosticLog), BGP ASN conflicts (check RouteDiagnosticLog), and tunnel flapping due to packet loss (check TunnelDiagnosticLog). Use Network Watcher's VPN troubleshoot feature to run automated diagnostics on connections. For proactive monitoring, set up alerts on TunnelEgressPacketDropCount and TunnelIngressPacketDropCount metrics to detect packet loss early.

#!/bin/bash
# Enable all VPN Gateway diagnostic logs
az monitor diagnostic-settings create \
  --name vpn-diag \
  --resource /subscriptions/.../vpnGateways/vpn-gw \
  --workspace /subscriptions/.../workspaces/law-prod \
  --logs '[
    {"category": "GatewayDiagnosticLog", "enabled": true},
    {"category": "TunnelDiagnosticLog", "enabled": true},
    {"category": "RouteDiagnosticLog", "enabled": true},
    {"category": "IKEDiagnosticLog", "enabled": true}
  ]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

# Query IKE failures from past 24 hours
az monitor log-analytics query \
  --workspace law-prod \
  --query "IKEDiagnosticLog | where TimeGenerated > ago(24h) | where ResultType != 'Succeeded' | project TimeGenerated, ResultType, RemoteIP, CorrelationId"

# View BGP peer status
az network vnet-gateway list-bgp-peer-status \
  --resource-group rg-prod \
  --name vpn-gw

Azure Route Server: Dynamic Routing Without a Gateway

Azure Route Server enables dynamic route exchange between network virtual appliances (NVAs) and your virtual networks using BGP — without deploying a VPN gateway or ExpressRoute circuit. It acts as a BGP route reflector, learning routes from NVAs and injecting them into the VNet's routing table. This is particularly useful for hub-spoke topologies where an NVA firewall (e.g., Palo Alto, Check Point) needs to advertise routes to spokes. Route Server replaces complex UDR management: instead of manually updating route tables when NVAs are added or removed, the NVA advertises routes via BGP and Route Server propagates them. In production, deploy Route Server in the same VNet as your NVA. It supports up to 10 BGP peers and can advertise up to 1000 routes. Route Server is regional and must be deployed in a dedicated subnet named 'RouteServerSubnet' (size /27 or larger). It does not encrypt traffic — use IPsec between NVAs if encryption is needed. Combine Route Server with Virtual WAN for large-scale deployments. Key use case: an active-active NVA pair where each NVA advertises its own routes, and Route Server automatically updates the VNet routing when one NVA fails.

#!/bin/bash
# Create RouteServerSubnet
az network vnet subnet create \
  --name RouteServerSubnet \
  --resource-group rg-prod \
  --vnet-name hub-vnet \
  --address-prefix 10.0.6.0/27

# Create Azure Route Server
az network routeserver create \
  --name hub-routeserver \
  --resource-group rg-prod \
  --location eastus \
  --hosted-subnet /subscriptions/.../subnets/RouteServerSubnet

# Peer with NVA
az network routeserver peering create \
  --name nva-peering \
  --routeserver hub-routeserver \
  --resource-group rg-prod \
  --peer-ip 10.0.4.4 \
  --peer-asn 65001

# View learned routes
az network routeserver show-advertised-routes \
  --name hub-routeserver \
  --resource-group rg-prod \
  --peer nva-peering