VNet-to-VNet connectivity in Azure - Step-by-Step Execution

Process Flow - VNet-to-VNet connectivity

Create VNet1

↓

Create VNet2

↓

Create VPN Gateway in VNet1

↓

Create VPN Gateway in VNet2

↓

Create Connection from VNet1 Gateway to VNet2 Gateway

↓

Create Connection from VNet2 Gateway to VNet1 Gateway

↓

Verify Connectivity

↓

Traffic flows securely between VNets

This flow shows setting up two virtual networks, adding gateways, connecting them, and enabling secure traffic flow.

Execution Sample

Azure

az network vnet create --name VNet1 --resource-group RG --address-prefix 10.1.0.0/16
az network vnet create --name VNet2 --resource-group RG --address-prefix 10.2.0.0/16
az network public-ip create --name GW1IP --resource-group RG --allocation-method Dynamic
az network public-ip create --name GW2IP --resource-group RG --allocation-method Dynamic
az network vnet-gateway create --name GW1 --vnet VNet1 --public-ip-address GW1IP --resource-group RG --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1
az network vnet-gateway create --name GW2 --vnet VNet2 --public-ip-address GW2IP --resource-group RG --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1
az network vpn-connection create --name Conn1 --resource-group RG --vnet-gateway1 GW1 --vnet-gateway2 GW2 --shared-key abc123
az network vpn-connection create --name Conn2 --resource-group RG --vnet-gateway1 GW2 --vnet-gateway2 GW1 --shared-key abc123

Commands to create two VNets, public IPs, gateways, and VPN connections between them.

Process Table

Step	Action	Resource Created/Updated	State/Result
1	Create VNet1	VNet1 with 10.1.0.0/16	VNet1 ready
2	Create VNet2	VNet2 with 10.2.0.0/16	VNet2 ready
3	Create Public IP GW1IP	Public IP GW1IP	GW1IP ready
4	Create Public IP GW2IP	Public IP GW2IP	GW2IP ready
5	Create VPN Gateway in VNet1	GW1 with public IP GW1IP	GW1 provisioning started
6	Create VPN Gateway in VNet2	GW2 with public IP GW2IP	GW2 provisioning started
7	Create VPN Connection from GW1 to GW2	Conn1 with shared key	Conn1 connecting
8	Create VPN Connection from GW2 to GW1	Conn2 with shared key	Conn2 connecting
9	Verify Connectivity	Test ping from VNet1 to VNet2	Ping successful, connectivity established

💡 Connectivity established after both VPN connections are active and gateways are provisioned

Status Tracker

Resource	Initial State	After Creation	After Connection	Final State
VNet1	Not exist	Created with 10.1.0.0/16	Connected via GW1	Ready and connected
VNet2	Not exist	Created with 10.2.0.0/16	Connected via GW2	Ready and connected
GW1	Not exist	Provisioning started	Connected to GW2 via Conn1	Provisioned and connected
GW2	Not exist	Provisioning started	Connected to GW1 via Conn2	Provisioned and connected
Conn1	Not exist	Created	Connecting	Connected
Conn2	Not exist	Created	Connecting	Connected

Key Moments - 3 Insights

Why do we need to create two VPN connections (Conn1 and Conn2) instead of just one?

Each VPN gateway requires a connection object to the other gateway. Conn1 connects GW1 to GW2, and Conn2 connects GW2 to GW1. Both are needed for bidirectional communication, as shown in steps 7 and 8 in the execution_table.

What happens if the shared key between the VPN connections does not match?

The VPN connections will fail to establish secure tunnels. This is because the shared key is used to authenticate the connection. The execution_table shows connection states as 'connecting' and then 'connected' only when keys match.

Why do we create VPN gateways after creating VNets?

VPN gateways must be attached to existing VNets to route traffic. Creating VNets first (steps 1 and 2) ensures gateways (steps 5 and 6) have networks to connect to, as reflected in the resource creation order.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the first VPN gateway start provisioning?

A Step 5

B Step 1

C Step 7

D Step 9

💡 Hint

Check the 'Action' and 'Resource Created/Updated' columns in execution_table rows

According to variable_tracker, what is the state of GW2 after connection creation?

A Not exist

B Provisioning started

C Connected to GW1 via Conn2

D Ready and connected

💡 Hint

Look at the 'After Connection' column for GW2 in variable_tracker

If the shared key is incorrect, what would change in the execution_table?

A Steps 7 and 8 would show 'Connected'

B Steps 7 and 8 would show 'Failed to connect'

C Steps 5 and 6 would fail provisioning

D Step 9 would show 'Ping successful'

💡 Hint

Refer to the 'State/Result' column for connection steps in execution_table

Concept Snapshot

VNet-to-VNet connectivity in Azure:
- Create two VNets with distinct address spaces
- Deploy VPN gateways in each VNet
- Create VPN connections between gateways with matching shared keys
- Connections enable secure, bidirectional traffic
- Verify connectivity by testing communication between VNets

Full Transcript

This visual execution shows how to connect two Azure virtual networks (VNets) using VPN gateways. First, two VNets are created with different IP address ranges. Then, public IP addresses are created for the gateways. VPN gateways are deployed in each VNet using those public IPs. Next, two VPN connections are created: one from the first gateway to the second, and another from the second gateway back to the first. Both connections use the same shared key for authentication. After provisioning and connection setup, connectivity is verified by testing network traffic between the VNets. The variable tracker shows the state changes of VNets, gateways, and connections through each step. Key moments clarify why two connections are needed, the importance of matching shared keys, and the order of resource creation. The quiz tests understanding of provisioning steps, resource states, and failure scenarios.

Practice

1. What is the main purpose of VNet-to-VNet peering in Azure?

easy

A. To create a backup of a virtual network

B. To securely connect two virtual networks for resource sharing

C. To connect a virtual network to the internet

D. To increase the size of a single virtual network

Solution

1. Step 1: Understand VNet-to-VNet peering concept

   VNet-to-VNet peering connects two virtual networks securely to allow communication.

2. Step 2: Identify the purpose of peering

   It enables resource sharing between VNets without exposing them to the internet.

3. Final Answer:

   To securely connect two virtual networks for resource sharing -> Option B

4. Quick Check:

   VNet peering = secure VNet connection [OK]

Hint: Peering connects VNets securely, not to internet or backup [OK]

Common Mistakes:

• Confusing peering with internet connectivity
• Thinking peering increases VNet size
• Assuming peering creates backups

2. Which of the following is the correct way to establish VNet peering between two VNets in Azure?

easy

A. Create peering from VNet1 to VNet2 only

B. Create peering from VNet2 to VNet1 only

C. Create peering from both VNet1 to VNet2 and VNet2 to VNet1

D. No peering needed, VNets connect automatically

Solution

1. Step 1: Review peering setup requirements

   Peering must be created from both VNets to allow two-way communication.

2. Step 2: Identify correct peering configuration

   Only creating peering one way does not enable full connectivity.

3. Final Answer:

   Create peering from both VNet1 to VNet2 and VNet2 to VNet1 -> Option C

4. Quick Check:

   Two-way peering needed = Create peering from both VNet1 to VNet2 and VNet2 to VNet1 [OK]

Hint: Peering must be two-way for full VNet connectivity [OK]

Common Mistakes:

• Setting peering only one way
• Assuming VNets connect automatically
• Confusing peering with VPN gateways

3. Given two VNets, VNetA and VNetB, with peering configured correctly, what happens if you try to access a VM in VNetB from VNetA?

medium

A. The VM in VNetB is accessible as if on the same network

B. The VM in VNetB is blocked by default firewall rules

C. The VM in VNetB is unreachable without a VPN gateway

D. The VM in VNetB is accessible only via public IP

Solution

1. Step 1: Understand effect of correct VNet peering

   Peering allows VNets to communicate privately as if on the same network.

2. Step 2: Analyze access to VM in peered VNet

   VMs can be accessed using private IPs without VPN or public IP.

3. Final Answer:

   The VM in VNetB is accessible as if on the same network -> Option A

4. Quick Check:

   Peering enables private access = The VM in VNetB is accessible as if on the same network [OK]

Hint: Peered VNets act like one network for VM access [OK]

Common Mistakes:

• Thinking VPN gateway is always needed
• Assuming public IP is required
• Confusing firewall rules with peering

4. You set up VNet peering from VNet1 to VNet2 but cannot access resources in VNet2 from VNet1. What is the most likely cause?

medium

A. Peering was not created from VNet2 to VNet1

B. VNet1 and VNet2 have overlapping IP address ranges

C. Network Security Groups block traffic between VNets

D. All of the above

Solution

1. Step 1: Check peering configuration

   Peering must be created both ways; missing one side blocks communication.

2. Step 2: Verify IP address ranges and security rules

   Overlapping IPs cause routing conflicts; NSGs may block traffic.

3. Step 3: Combine all issues

   Any of these can cause access failure; all are common mistakes.

4. Final Answer:

   All of the above -> Option D

5. Quick Check:

   Multiple causes block access = All of the above [OK]

Hint: Check peering, IP ranges, and NSGs when access fails [OK]

Common Mistakes:

• Ignoring one-way peering setup
• Overlapping IP ranges unnoticed
• Not checking firewall or NSG rules

5. You have two VNets in different Azure regions that need to communicate privately. Which approach is best to enable this with minimal latency and no internet exposure?

hard

A. Use VNet-to-VNet peering with global peering enabled

B. Set up a VPN gateway connection between the VNets

C. Connect VNets via public IP addresses

D. Use ExpressRoute with public peering

Solution

1. Step 1: Identify connectivity options for cross-region VNets

   Global VNet peering allows private, low-latency connection between VNets in different regions.

2. Step 2: Compare alternatives

   VPN gateways add latency and complexity; public IPs expose traffic; ExpressRoute public peering is not private.

3. Step 3: Choose best practice

   Global VNet peering is recommended for private, fast cross-region VNet communication.

4. Final Answer:

   Use VNet-to-VNet peering with global peering enabled -> Option A

5. Quick Check:

   Global peering = private, low latency cross-region [OK]

Hint: Global peering connects regions privately with low latency [OK]

Common Mistakes:

• Using VPN gateways unnecessarily
• Exposing traffic via public IPs
• Confusing ExpressRoute public peering with private