Azure VNet Peering Implementation Guide

Table of Contents

VNet Peering Overview

Azure Virtual Network (VNet) peering enables seamless connectivity between Azure virtual networks. Traffic between virtual machines in peered virtual networks is routed through the Microsoft backbone infrastructure, similar to traffic routed between virtual machines in the same virtual network, through private IP addresses only.

Key Benefits:
  • Low latency, high bandwidth connections
  • Traffic stays on Microsoft backbone network
  • No gateways or public internet required
  • Cross-region and cross-subscription support

Architecture Diagrams

Basic VNet Peering Architecture

graph TB subgraph "Resource Group: rg-networking" subgraph "VNet-A (10.1.0.0/16)" subgraph "Subnet-A-Web (10.1.1.0/24)" VM1[VM-Web-01
10.1.1.4] VM2[VM-Web-02
10.1.1.5] end subgraph "Subnet-A-DB (10.1.2.0/24)" VM3[VM-DB-01
10.1.2.4] end end subgraph "VNet-B (10.2.0.0/16)" subgraph "Subnet-B-App (10.2.1.0/24)" VM4[VM-App-01
10.2.1.4] VM5[VM-App-02
10.2.1.5] end subgraph "Subnet-B-Services (10.2.2.0/24)" VM6[VM-Services-01
10.2.2.4] end end end VNet-A -.->|Peering Connection| VNet-B VNet-B -.->|Peering Connection| VNet-A style VNet-A fill:#e1f5fe style VNet-B fill:#f3e5f5 style VM1 fill:#81c784 style VM2 fill:#81c784 style VM3 fill:#ffb74d style VM4 fill:#64b5f6 style VM5 fill:#64b5f6 style VM6 fill:#f06292
Architecture Explanation:

This diagram shows a basic VNet peering setup between two virtual networks (VNet-A and VNet-B) in the same resource group. Each VNet has multiple subnets with different purposes:

  • VNet-A: Contains web tier (10.1.1.0/24) and database tier (10.1.2.0/24)
  • VNet-B: Contains application tier (10.2.1.0/24) and services tier (10.2.2.0/24)
  • Peering Connection: Bidirectional connection allowing VMs in both VNets to communicate directly
  • Address Spaces: Non-overlapping CIDR blocks ensure proper routing

Hub and Spoke Architecture

graph TB subgraph "Hub VNet (10.0.0.0/16)" subgraph "GatewaySubnet (10.0.1.0/24)" VGW[VPN Gateway
10.0.1.4] end subgraph "AzureFirewallSubnet (10.0.2.0/24)" FW[Azure Firewall
10.0.2.4] end subgraph "SharedServices (10.0.3.0/24)" DNS[DNS Server
10.0.3.4] DC[Domain Controller
10.0.3.5] end end subgraph "Spoke-1 VNet (10.1.0.0/16)" subgraph "Production (10.1.1.0/24)" PROD[Production VMs] end end subgraph "Spoke-2 VNet (10.2.0.0/16)" subgraph "Development (10.2.1.0/24)" DEV[Development VMs] end end subgraph "Spoke-3 VNet (10.3.0.0/16)" subgraph "Testing (10.3.1.0/24)" TEST[Testing VMs] end end OnPrem[On-Premises
192.168.0.0/16] Hub -.->|Peering| Spoke-1 Hub -.->|Peering| Spoke-2 Hub -.->|Peering| Spoke-3 OnPrem -->|VPN Connection| VGW style Hub fill:#e8f5e8 style Spoke-1 fill:#fff3cd style Spoke-2 fill:#e3f2fd style Spoke-3 fill:#fce4ec style OnPrem fill:#f5f5f5
Hub and Spoke Architecture Explanation:

The hub and spoke model is a common network topology in Azure that centralizes shared services and connectivity:

  • Hub VNet: Central point containing shared services like VPN Gateway, Azure Firewall, and DNS
  • Spoke VNets: Individual workload networks that peer with the hub
  • Centralized Connectivity: On-premises connection through the hub VNet
  • Network Segmentation: Each spoke represents a different environment or business unit
  • Shared Services: DNS, domain controllers, and security services centralized in the hub

Traffic Flow Patterns

Direct VNet-to-VNet Communication

sequenceDiagram participant VM1 as VM in VNet-A
(10.1.1.4) participant Azure as Azure Backbone
Network participant VM2 as VM in VNet-B
(10.2.1.4) VM1->>Azure: TCP SYN to 10.2.1.4:80 Note over Azure: Route lookup via
VNet peering Azure->>VM2: Forward TCP SYN VM2->>Azure: TCP SYN-ACK Azure->>VM1: Forward TCP SYN-ACK VM1->>Azure: TCP ACK Azure->>VM2: Forward TCP ACK Note over VM1,VM2: Established connection
Direct communication VM1->>Azure: HTTP Request Azure->>VM2: Forward HTTP Request VM2->>Azure: HTTP Response Azure->>VM1: Forward HTTP Response
Direct Communication Flow:

This sequence diagram shows how traffic flows between VMs in peered VNets:

  • Route Resolution: Azure automatically creates routes for peered VNet address spaces
  • Backbone Network: Traffic stays on Microsoft's private backbone network
  • No Gateway Required: Direct VM-to-VM communication without NAT or gateways
  • Bi-directional: Both VNets can initiate connections to each other

Hub-Spoke Traffic Flow with Firewall

sequenceDiagram participant S1 as Spoke-1 VM
(10.1.1.4) participant FW as Azure Firewall
(10.0.2.4) participant S2 as Spoke-2 VM
(10.2.1.4) S1->>FW: Traffic to 10.2.1.4 Note over FW: Apply firewall rules
Network/Application rules alt Traffic Allowed FW->>S2: Forward traffic S2->>FW: Response traffic FW->>S1: Forward response else Traffic Blocked FW->>S1: Drop/Deny packet Note over S1: Connection timeout
or explicit deny end
Hub-Spoke with Firewall Flow:

When using Azure Firewall in a hub-spoke model, traffic between spokes is controlled:

  • Forced Tunneling: User Defined Routes (UDR) force traffic through the firewall
  • Centralized Security: All inter-spoke traffic is inspected and filtered
  • Rule Processing: Network rules, application rules, and NAT rules are evaluated
  • Logging: All traffic decisions are logged for compliance and monitoring

Transitive Routing Limitation

graph LR subgraph "VNet-A (10.1.0.0/16)" VMA[VM-A] end subgraph "VNet-B (10.2.0.0/16)" VMB[VM-B] end subgraph "VNet-C (10.3.0.0/16)" VMC[VM-C] end VNet-A -.->|Peering| VNet-B VNet-B -.->|Peering| VNet-C VNet-A -.->|No Direct Route| VNet-C style VNet-A fill:#e3f2fd style VNet-B fill:#fff3cd style VNet-C fill:#fce4ec classDef blocked fill:#ffcdd2,stroke:#d32f2f class VNet-A,VNet-C blocked
Transitive Routing Limitation:

VNet peering is not transitive, meaning:

  • No Automatic Routing: VNet-A cannot reach VNet-C through VNet-B automatically
  • Direct Peering Required: Each VNet pair must be explicitly peered
  • Hub-Spoke Solution: Use a hub VNet with NVA or Azure Firewall for transitive routing
  • Route Tables: Custom routes can be configured to enable transitive routing through an NVA

Implementation Steps

Prerequisites

Before You Begin:
  • Ensure you have appropriate permissions (Network Contributor or higher)
  • VNets must have non-overlapping address spaces
  • VNets can be in same or different subscriptions
  • VNets can be in same or different regions

Configuration Commands

Create VNet Peering Connection

az network vnet peering create \
    --name "peer-vnet-a-to-vnet-b" \
    --resource-group "rg-networking" \
    --vnet-name "vnet-a" \
    --remote-vnet "vnet-b" \
    --allow-vnet-access \
    --allow-forwarded-traffic \
    --allow-gateway-transit
Parameter Explanation:
  • --name: Name for the peering connection (must be unique within the VNet)
  • --resource-group: Resource group containing the source VNet
  • --vnet-name: Name of the source VNet
  • --remote-vnet: Name or resource ID of the destination VNet
  • --allow-vnet-access: Enables communication between VNets
  • --allow-forwarded-traffic: Allows traffic forwarded by NVA or gateway
  • --allow-gateway-transit: Allows the remote VNet to use this VNet's gateway
Purpose: This command creates a peering connection from VNet-A to VNet-B. This is a unidirectional peering, meaning traffic can flow from VNet-A to VNet-B, but not the reverse unless a reciprocal peering is created.

Create Reciprocal Peering Connection

az network vnet peering create \
    --name "peer-vnet-b-to-vnet-a" \
    --resource-group "rg-networking" \
    --vnet-name "vnet-b" \
    --remote-vnet "vnet-a" \
    --allow-vnet-access \
    --allow-forwarded-traffic \
    --use-remote-gateways
Parameter Explanation:
  • --use-remote-gateways: Uses the remote VNet's gateway for connectivity
  • Cannot be used with --allow-gateway-transit
  • Remote VNet must have a gateway configured
  • Only one VNet in a peering can use remote gateways
Purpose: This creates the reciprocal peering connection, enabling bidirectional communication. The --use-remote-gateways parameter allows VNet-B to use VNet-A's gateway for external connectivity.

Cross-Subscription Peering

az network vnet peering create \
    --name "peer-to-remote-subscription" \
    --resource-group "rg-networking" \
    --vnet-name "vnet-local" \
    --remote-vnet "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rg-remote/providers/Microsoft.Network/virtualNetworks/vnet-remote" \
    --allow-vnet-access
Parameter Explanation:
  • --remote-vnet: Full resource ID required for cross-subscription peering
  • Format: /subscriptions/{subscription-id}/resourceGroups/{rg-name}/providers/Microsoft.Network/virtualNetworks/{vnet-name}
  • Requires appropriate permissions in both subscriptions
Purpose: Enables peering between VNets in different Azure subscriptions. This is useful for organizations with multiple subscriptions or for connecting to partner networks.

Cross-Region Peering

az network vnet peering create \
    --name "peer-cross-region" \
    --resource-group "rg-networking-eastus" \
    --vnet-name "vnet-eastus" \
    --remote-vnet "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rg-networking-westus/providers/Microsoft.Network/virtualNetworks/vnet-westus" \
    --allow-vnet-access
Parameter Explanation:
  • Cross-region peering has the same syntax as same-region peering
  • Additional egress charges apply for cross-region data transfer
  • Latency will be higher than same-region peering
Purpose: Connects VNets across different Azure regions for disaster recovery, global applications, or data replication scenarios.

Hub-Spoke Configuration

# Create Hub to Spoke-1 peering
az network vnet peering create \
    --name "hub-to-spoke1" \
    --resource-group "rg-hub" \
    --vnet-name "vnet-hub" \
    --remote-vnet "vnet-spoke1" \
    --allow-vnet-access \
    --allow-forwarded-traffic \
    --allow-gateway-transit
# Create Spoke-1 to Hub peering
az network vnet peering create \
    --name "spoke1-to-hub" \
    --resource-group "rg-spoke1" \
    --vnet-name "vnet-spoke1" \
    --remote-vnet "vnet-hub" \
    --allow-vnet-access \
    --allow-forwarded-traffic \
    --use-remote-gateways
Hub-Spoke Configuration Notes:
  • Hub VNet: Uses --allow-gateway-transit to share its gateway
  • Spoke VNet: Uses --use-remote-gateways to access hub's gateway
  • Forwarded Traffic: Enabled on both sides for NVA scenarios
  • Scalability: Hub can peer with multiple spokes
Purpose: Establishes a hub-spoke topology where the hub provides shared services and connectivity to on-premises networks, while spokes host specific workloads.

Verify Peering Status

az network vnet peering show \
    --name "peer-vnet-a-to-vnet-b" \
    --resource-group "rg-networking" \
    --vnet-name "vnet-a" \
    --query "peeringState"
Peering States:
  • Initiated: Peering created but reciprocal peering not yet established
  • Connected: Both peerings are established and functional
  • Disconnected: Peering exists but is not functional
  • Failed: Peering creation failed
Purpose: Verifies that the peering connection is properly established and functional. A "Connected" state indicates successful bidirectional peering.

List All Peerings

az network vnet peering list \
    --resource-group "rg-networking" \
    --vnet-name "vnet-a" \
    --output table
Purpose: Displays all peering connections for a specific VNet, showing their status, remote VNet, and configuration settings.

Command Execution Flow

Implementation Order Diagram

graph TD A[Start: Planning Phase] --> B[1. Verify Prerequisites] B --> C[2. Create Source VNet
az network vnet create] C --> D[3. Create Destination VNet
az network vnet create] D --> E[4. Create First Peering
az network vnet peering create] E --> F[5. Create Reciprocal Peering
az network vnet peering create] F --> G[6. Verify Peering Status
az network vnet peering show] G --> H{Peering State = Connected?} H -->|Yes| I[7. Test Connectivity
ping, telnet, etc.] H -->|No| J[Troubleshoot
Check configuration] J --> E I --> K[8. Configure Route Tables
az network route-table create] K --> L[9. Configure NSG Rules
az network nsg rule create] L --> M[10. Monitor & Maintain
az network watcher] M --> N[Complete] style A fill:#e8f5e8 style N fill:#e8f5e8 style H fill:#fff3cd style J fill:#ffcdd2
Command Execution Flow Explanation:
  1. Prerequisites: Ensure permissions, non-overlapping address spaces, and resource planning
  2. VNet Creation: Create source and destination VNets (assuming not already created)
  3. First Peering: Create initial peering connection (unidirectional)
  4. Reciprocal Peering: Create return peering connection (bidirectional)
  5. Verification: Check peering state to ensure "Connected" status
  6. Connectivity Testing: Test actual network connectivity between VNets
  7. Route Configuration: Configure custom routes if needed
  8. Security Rules: Configure NSG rules for traffic control
  9. Monitoring: Set up monitoring and alerting

Component Dependency Map

graph LR subgraph "Prerequisites" RBAC[RBAC Permissions] SUB[Subscription Access] ADDR[Address Planning] end subgraph "Core Components" RG[Resource Group] VNET1[Source VNet] VNET2[Destination VNet] end subgraph "Peering Components" PEER1[Primary Peering] PEER2[Reciprocal Peering] end subgraph "Optional Components" RT[Route Tables] NSG[Network Security Groups] NVA[Network Virtual Appliances] end RBAC --> RG SUB --> RG ADDR --> VNET1 ADDR --> VNET2 RG --> VNET1 RG --> VNET2 VNET1 --> PEER1 VNET2 --> PEER1 PEER1 --> PEER2 PEER2 --> RT PEER2 --> NSG RT --> NVA style RBAC fill:#ffcdd2 style SUB fill:#ffcdd2 style ADDR fill:#ffcdd2 style PEER1 fill:#e3f2fd style PEER2 fill:#e3f2fd
Component Dependencies:
  • Prerequisites (Red): Must be completed before any Azure resources
  • Core Components: Basic infrastructure required for peering
  • Peering Components (Blue): The actual peering connections
  • Optional Components: Additional networking features that depend on peering

Troubleshooting Common Issues

Peering State Issues

Problem: Peering state shows "Initiated" instead of "Connected"
Solution: Create the reciprocal peering connection in the destination VNet 
# Check peering state
az network vnet peering show \
    --name "peer-vnet-a-to-vnet-b" \
    --resource-group "rg-networking" \
    --vnet-name "vnet-a" \
    --query "{Name:name, State:peeringState, RemoteVnet:remoteVirtualNetwork.id}"

Address Space Conflicts

Problem: Peering creation fails due to overlapping address spaces
Solution: Ensure VNets have non-overlapping CIDR blocks 
# Check VNet address spaces
az network vnet show \
    --name "vnet-a" \
    --resource-group "rg-networking" \
    --query "addressSpace.addressPrefixes"

Cross-Subscription Permissions

Problem: Access denied when creating cross-subscription peering
Solution: Ensure Network Contributor role in both subscriptions 
# Check current permissions
az role assignment list \
    --assignee $(az account show --query user.name -o tsv) \
    --query "[?roleDefinitionName=='Network Contributor'].{Role:roleDefinitionName, Scope:scope}"

Connectivity Testing

# Test connectivity between VNets
az network watcher test-connectivity \
    --source-resource "/subscriptions/{subscription}/resourceGroups/rg-networking/providers/Microsoft.Compute/virtualMachines/vm-a" \
    --dest-resource "/subscriptions/{subscription}/resourceGroups/rg-networking/providers/Microsoft.Compute/virtualMachines/vm-b" \
    --resource-group "rg-networking"
Connectivity Testing: This command uses Azure Network Watcher to test connectivity between VMs in peered VNets, providing detailed information about network paths and any blocking rules.