Azure Virtual Network Peering Step-by-Step

Azure Virtual Network (VNet) peering establishes a private, low-latency, high-bandwidth connection between two Azure VNets. This connectivity operates…

Azure Virtual Network (VNet) peering establishes a private, low-latency, high-bandwidth connection between two Azure VNets. This connectivity operates over the Microsoft backbone network, bypassing the public internet and providing a secure, reliable communication path. VNet peering is crucial for scenarios requiring isolation between environments (e.g., dev/test vs. production), shared services (e.g., central management VNet), or distributed application architectures without incurring egress data transfer costs commonly associated with VPN gateways for VNet-to-VNet traffic.

Understanding VNet Peering Fundamentals

VNet peering connects two VNets directly. Once peered, virtual machines in each VNet can communicate with each other as if they were in the same network. This is achieved through Microsoft's internal network infrastructure, ensuring optimal performance and security. There are two types of peering:

VNet Peering: Connects VNets within the same Azure region.
Global VNet Peering: Connects VNets across different Azure regions.

Key characteristics of VNet peering:

Non-transitive: If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot directly communicate with VNet C unless A and C are also peered.
No overlapping IP address spaces: Peered VNets must have non-overlapping IP address ranges. Azure will prevent peering if address spaces conflict.
Bidirectional: Peering is always between two VNets, and traffic flows in both directions once established.
Private connectivity: Traffic remains within the Microsoft backbone network.

Use Cases for VNet Peering

Hub-and-spoke architectures: A central hub VNet hosts shared services (e.g., DNS, AD DS, NVA) and is peered with multiple spoke VNets containing application workloads.
Environment isolation: Separating development, staging, and production environments while allowing controlled communication between them.
Shared services integration: A VNet dedicated to a specific service (e.g., Azure Kubernetes Service, Azure Virtual Desktop) needs to communicate with other application VNets.
Disaster recovery: Replicating data or services between VNets in different regions using global VNet peering.

Prerequisites and Considerations

Before initiating VNet peering, ensure the following:

Azure Subscription: You need an active Azure subscription.
Virtual Networks: Two existing VNets to be peered. Note their names, resource groups, and regions.
Non-overlapping IP Spaces: Crucially, the address spaces of the two VNets must not overlap. For example, if VNet A uses 10.0.0.0/16, VNet B cannot use 10.0.0.0/24 or 10.0.1.0/24 if it's within the 10.0.0.0/16 range. Azure will block peering if this condition is not met.
Permissions: Appropriate RBAC permissions are required to create and manage VNet peerings (e.g., Network Contributor role).
Gateway Transit (Optional): If one VNet has a VPN Gateway or ExpressRoute Gateway and you want other peered VNets to use it to connect to on-premises networks or other remote networks, you'll need to enable "Allow Gateway Transit" on the VNet with the gateway and "Use Remote Gateways" on the peered VNet(s).
Forwarded Traffic (Optional): If you plan to deploy Network Virtual Appliances (NVAs) in one VNet and want traffic from the peered VNet to flow through the NVA, you must enable "Allow Forwarded Traffic" on both peering links. This allows traffic not originating from an Azure VM to be routed through the peering.

Step-by-Step VNet Peering via Azure Portal

This section details the process using the Azure portal. We'll use two hypothetical VNets:

VNet A: vnet-prod-eastus (10.10.0.0/16) in eastus
VNet B: vnet-dev-westus (10.20.0.0/16) in westus

These VNets are in different regions, requiring Global VNet Peering.

Initiating Peering from VNet A

Navigate to Virtual networks in the Azure portal and select vnet-prod-eastus.
In the left-hand menu, under Settings, click on Peerings.
Click the + Add button at the top.
Configure the peering for vnet-prod-eastus to vnet-dev-westus:
- This virtual network peering name: vnet-prod-to-vnet-dev (this is the name of the peering object on VNet A's side)
- Virtual network deployment model: Resource Manager
- I know my resource ID: Leave unchecked unless you have a specific resource ID for the remote VNet.
- Subscription: Select the subscription where vnet-dev-westus resides (could be different from vnet-prod-eastus's subscription).
- Virtual Network: Choose vnet-dev-westus from the dropdown.
- The remote virtual network peering name: vnet-dev-to-vnet-prod (this is the name of the peering object that will be automatically created on VNet B's side)
Traffic to remote virtual network:
- Allow VNet access: Yes (default and required for connectivity).
- Allow forwarded traffic: Choose Yes if VNet A needs to route traffic to VNet B that didn't originate from a VM within VNet A (e.g., from an on-premises network via a gateway in VNet A, or from an NVA in VNet A).
Traffic from remote virtual network:
- Allow VNet access: Yes (default and required for connectivity).
- Allow forwarded traffic: Choose Yes if VNet B needs to route traffic to VNet A that didn't originate from a VM within VNet B.
Virtual network gateway or Route Server:
- Use remote virtual network's gateway or Route Server: Choose Yes if VNet A needs to use a VPN Gateway or ExpressRoute Gateway deployed in VNet B. Note that only one side can use the remote gateway. If you enable this, the other VNet must have "Allow Gateway Transit" enabled.
- Allow gateway transit: Choose Yes if VNet A has a VPN Gateway or ExpressRoute Gateway, and you want peered VNets (like VNet B) to be able to use it to reach on-premises networks.
Click Add to create the peering.

Azure automatically creates the reverse peering connection on vnet-dev-westus. Both peering statuses will show as "Connected" shortly after creation.

Step-by-Step VNet Peering via Azure CLI

The Azure CLI provides a robust way to automate VNet peering. Ensure you have the Azure CLI installed and authenticated (az login).

Assuming the same VNets:

VNet A: vnet-prod-eastus (Resource Group: rg-prod-eastus)
VNet B: vnet-dev-westus (Resource Group: rg-dev-westus)


# Define variables
VNET_A_NAME="vnet-prod-eastus"
VNET_A_RG="rg-prod-eastus"
VNET_B_NAME="vnet-dev-westus"
VNET_B_RG="rg-dev-westus"
PEERING_A_TO_B_NAME="vnet-prod-to-vnet-dev"
PEERING_B_TO_A_NAME="vnet-dev-to-vnet-prod"

# Get VNet A and VNet B resource IDs
VNET_A_ID=$(az network vnet show --resource-group $VNET_A_RG --name $VNET_A_NAME --query id --output tsv)
VNET_B_ID=$(az network vnet show --resource-group $VNET_B_RG --name $VNET_B_NAME --query id --output tsv)

echo "VNet A ID: $VNET_A_ID"
echo "VNet B ID: $VNET_B_ID"

# Create peering from VNet A to VNet B
az network vnet peering create \
  --name $PEERING_A_TO_B_NAME \
  --resource-group $VNET_A_RG \
  --vnet-name $VNET_A_NAME \
  --remote-vnet $VNET_B_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --allow-gateway-transit \
  --debug # Use --debug for verbose output if troubleshooting

# Create peering from VNet B to VNet A (reverse peering)
# This step is crucial and not always automatically created with the CLI if resource IDs are different subs/RGs.
# The portal handles this automatically. For CLI, explicitly create both sides.
az network vnet peering create \
  --name $PEERING_B_TO_A_NAME \
  --resource-group $VNET_B_RG \
  --vnet-name $VNET_B_NAME \
  --remote-vnet $VNET_A_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --use-remote-gateways \
  --debug # Use --debug for verbose output if troubleshooting

# Verify peering status (wait a few moments for connection)
echo "Checking peering status for VNet A..."
az network vnet peering show --resource-group $VNET_A_RG --vnet-name $VNET_A_NAME --name $PEERING_A_TO_B_NAME --query peeringState

echo "Checking peering status for VNet B..."
az network vnet peering show --resource-group $VNET_B_RG --vnet-name $VNET_B_NAME --name $PEERING_B_TO_A_NAME --query peeringState

# Expected output for peeringState: Connected

Important Note on CLI/PowerShell: While the Azure portal automatically creates the reverse peering, when using CLI or PowerShell, you generally need to create two peering links: one from VNet A to VNet B and another from VNet B to VNet A. This ensures the bidirectional connection is fully established, especially when VNets are in different subscriptions or resource groups. The portal's "remote virtual network peering name" field simplifies this by creating the other side for you.

In the CLI example above, --allow-gateway-transit is set on VNet A's peering, implying VNet A has the gateway. Thus, --use-remote-gateways is set on VNet B's peering. Ensure these are configured logically for your gateway topology.

Verifying and Testing Connectivity

After establishing peering, verify connectivity:

Check Peering Status: In the Azure portal, navigate to both VNets and check their "Peerings" section. Both sides should show a status of "Connected."
IP Route Table: Examine the effective routes for a VM in each VNet. You should see routes for the peered VNet's address space with a "VNet Peering" next hop type.
- Navigate to a VM, then under Networking, select a network interface.
- Under Support + troubleshooting, click Effective routes.
- Look for an entry that corresponds to the peered VNet's address space. The "Next hop type" should be VNetPeering.
Ping/RDP/SSH: Deploy a simple VM (e.g., Windows with ICMP enabled, or Linux) in each VNet. Attempt to ping, RDP, or SSH from a VM in one VNet to a VM in the other VNet using its private IP address. Ensure any Network Security Groups (NSGs) allow the necessary traffic.

Common Pitfalls and Troubleshooting

Overlapping IP Address Spaces: This is the most common reason for peering failure. Azure will explicitly block peering creation if address spaces overlap. Plan your IP addressing carefully.
Non-Transitive Nature: Remember that VNet A peered with B, and B peered with C does NOT mean A can reach C. You must explicitly peer A and C if direct communication is required. For transitive routing, consider NVAs or Azure Route Server in a hub-and-spoke model.
NSG Rules Blocking Traffic: Even with peering established, Network Security Groups (NSGs) attached to subnets or NICs can block traffic. Ensure NSG rules permit traffic between the peered VNet IP ranges. The default "VirtualNetwork" tag covers peered VNets.
Gateway Transit Misconfiguration: If you're using a VPN/ExpressRoute Gateway, only one VNet can have "Allow Gateway Transit" enabled, and the other VNet(s) must have "Use Remote Gateways" enabled. If both enable "Allow Gateway Transit" or if "Use Remote Gateways" points to a non-existent gateway, routing issues will occur.
DNS Resolution: By default, VMs in peered VNets cannot resolve DNS names for VMs in the other VNet using Azure-provided DNS. If you require cross-VNet DNS resolution, you must use Azure Private DNS zones or deploy your own custom DNS servers (e.g., domain controllers) and configure them in your VNet settings.
Missing Peering Link (CLI/PowerShell): If you use automation, always ensure both sides of the peering link are created. A single az network vnet peering create command only establishes one direction; the other side needs a corresponding command.
Resource Group/Subscription Permissions: Ensure the user or service principal creating the peering has sufficient permissions in both resource groups and subscriptions involved, especially in cross-subscription peering scenarios.