Configuring Azure VNet Peering

This lesson explains how to connect isolated virtual networks using:

Azure Virtual Network VNet Peering

1️⃣ What Is VNet Peering?#

By default:

• VNets are isolated
• No communication between them
• Even within same subscription

VNet Peering enables:

• ✔ Private IP communication ✔ High-speed backbone connectivity ✔ Cross-region connectivity ✔ Cross-subscription connectivity ✔ Cross-tenant connectivity

2️⃣ Requirements for VNet Peering#

✔ Non-overlapping IP address space#

• If CIDR overlaps → Peering fails

Example:

• VNet-A → 172.16.0.0/24
• VNet-B → 10.0.0.0/16
• This works.
• VNet-A → 172.16.0.0/24
• VNet-B → 172.16.0.0/16
• This fails (overlapping).

3️⃣ Key Characteristics#

🔹 Private connectivity only#

Traffic flows over Azure backbone.

🔹 Not encrypted by default#

Unlike VPN (IPsec), peering is not encrypted unless VNet encryption is enabled.

🔹 Non-transitive#

Very important concept:

If:

• VNet-A ↔ VNet-Hub
• VNet-B ↔ VNet-Hub
• VNet-A ❌ cannot talk to VNet-B automatically.
• Each pair requires its own peering.

4️⃣ Types of VNet Peering#

✔ Regional Peering#

Same Azure region

✔ Global Peering#

Across regions

✔ Cross-Subscription Peering#

Different subscriptions

✔ Cross-Tenant Peering#

Different Azure AD tenants

5️⃣ Demonstration Summary#

Environment:

• VNet-Prod-01 → 172.16.0.0/24
• VM: 172.16.0.4
• VNet-Prod-02 → 10.0.0.0/16
• VM: 10.0.0.4

Before peering:

• Ping 10.0.0.4 → ❌ Failed

After peering:

• Ping 10.0.0.4 → ✅ Success

6️⃣ How Peering Is Created#

Peering must be:

• ✔ Configured on both VNets ✔ Azure portal creates both sides automatically

Each side has:

• Peering name
• Remote VNet
• Allow forwarded traffic option
• Gateway usage options

7️⃣ Important Peering Options Explained#

8️⃣ Gateway Transit Scenario (Hub-Spoke)#

Example:

• Hub VNet → Has VPN Gateway
• Spoke VNet → Uses remote gateway

Configuration:

• Hub: ✔ Allow gateway transit
• Spoke: ✔ Use remote gateway
• This allows spokes to use hub’s gateway.

9️⃣ VNet Peering vs VPN#

🔟 Routing with Peering#

When peering is created:

Azure automatically:

• ✔ Adds system routes ✔ Updates effective routes ✔ Enables private communication
• No manual route table required.

11️⃣ Security Considerations#

Peering enables connectivity, but:

• NSGs still apply
• Route tables still apply
• Firewall rules still apply
• Peering ≠ unrestricted access.

12️⃣ Common Exam Concepts (AZ-104 / AZ-700)#

🚩 Peering is transitive → False 🚩 Peering requires same region → False 🚩 Peering requires non-overlapping CIDR → True 🚩 Peering traffic is encrypted by default → False 🚩 Peering works across subscriptions → True

13️⃣ Hub-and-Spoke Architecture Example#

• Hub
• / \
• Spoke1 Spoke2
• Spoke1 ↔ Hub Spoke2 ↔ Hub
• Spoke1 ❌ Spoke2 (unless directly peered)

14️⃣ Troubleshooting Checklist#

If peering not working:

• Check IP ranges overlap?
• Confirm peering status = Connected
• Check NSGs blocking traffic
• Check UDRs overriding routes
• Verify gateway transit settings

15️⃣ Reference Documentation#

• VNet Peering Overview
• Global VNet Peering
• Hub-Spoke Architecture
• Effective Routes

Final Conceptual Summary#

VNet Peering:

• Connects isolated VNets
• Uses Azure backbone
• Requires non-overlapping IPs
• Is non-transitive
• Not encrypted by default
• Supports cross-region & cross-subscription

It is the foundational building block of:

• ✔ Hub-spoke designs ✔ Enterprise multi-VNet environments ✔ Partner connectivity ✔ Mergers & acquisitions scenarios

If you'd like next:

• 🧠 25 VNet peering scenario-based exam questions
• 📊 Hub-spoke visual breakdown
• 🏗 Peering + Gateway Transit deep dive
• 📄 Complete AZ-104 networking recap sheet
• Tell me your target exam (AZ-104, AZ-700, AZ-305?).

Hands-on: Peer Two VNets#

Goal: Connect two VNets over the Azure backbone and validate private IP connectivity.

1. Create VNet az104-vnet-a with address space 10.60.0.0/16.
2. Create VNet az104-vnet-b with address space 10.61.0.0/16.
3. Deploy one test VM in each VNet.
4. Open az104-vnet-a > Peerings > Add.
5. Name the local peering a-to-b and remote peering b-to-a.
6. Select az104-vnet-b as the remote VNet.
7. Enable traffic to the remote virtual network.
8. Create the peering.
9. Confirm both peering objects show Connected.
10. Allow ICMP or a test TCP port in both VM NSGs.
11. Test private IP connectivity between VMs.

Hands-on: Validate Non-Transitive Peering#

1. Create a third VNet az104-vnet-c.
2. Peer A to B and B to C.
3. Do not peer A to C.
4. Try reaching C from A.
5. Confirm traffic does not automatically transit through B.
6. Use this result to remember the exam point: VNet peering is non-transitive unless you introduce routing appliances or hub-spoke services.