Create and Configure VNet Peering in Azure
Pluralsight Hands-On Lab — Networking
At a Glance
| Platform | Pluralsight |
|---|
| Category | Azure Networking |
|---|
| Lab Type | Guided + Challenge Mode |
|---|
| Environment | Azure Portal, Linux VM via SSH, Serial Console |
|---|
| Completed | 2026 |
|---|
Overview
VNet peering connects Azure virtual networks so resources can communicate privately across network boundaries — a foundational pattern for Hub and Spoke architectures and cross-region or cross-subscription deployments. These two Pluralsight labs cover VNet peering at different depths: one focuses on peering pre-built VNets with gateway transit and VPN gateway configuration, while the other covers building VNets and VMs from scratch, enabling peering, and validating private connectivity using SSH, ping, and traceroute to confirm traffic never traverses the public internet.
Lab 1 — VNet Peering with Gateway Transit
- Added a GatewaySubnet to vnet2 and deployed a VPN Gateway (vpngw, VpnGw1AZ SKU) with a dedicated public IP (vpngwip)
- Created bidirectional peering between vnet2 and vnet1 (link names: vnet1-to-vnet2 and vnet2-to-vnet1) and confirmed Connected status
- Validated connectivity from vm2 via Serial Console by pinging vm1's private IP (10.1.1.4) — confirmed 0% packet loss
- Created bidirectional peering between vnet2 and vnet3 with "Use remote gateway" enabled on vnet3 and "Allow gateway transit" enabled on vnet2, routing vnet3 traffic through the VPN gateway
- Validated vnet3 connectivity from vm2's Serial Console by pinging vm3's private IP (10.3.3.4) — confirmed 0% packet loss
Lab 2 — VNet Peering from Scratch with Traceroute Validation
- Created two virtual networks from scratch: vnet-a (10.0.0.0/16, subnet defaultA at 10.0.1.0/24) and vnet-b (10.1.0.0/16, subnet defaultB at 10.1.1.0/24) in East US
- Deployed two Linux VMs: vm-a on vnet-a and vm-b on vnet-b, each with SSH key authentication
- Created bidirectional VNet peering between vnet-a and vnet-b (link name: vnet-a-to-vnet-b) with forwarded traffic allowed on both sides
- SSH'd into vm-a using the downloaded private key and ran ping against vm-b's private IP — confirmed successful responses, validating peered connectivity
- Installed traceroute on vm-a and ran traceroute against vm-b's private IP — confirmed a single direct hop with no internet traversal, proving traffic flows entirely within the Azure backbone
← Back to Pluralsight Labs