Skip to main content

Create and Configure VNet Peering in Azure

Hands-On Lab


Photo of

Training Architect





Welcome to this Azure hands-on lab. We will be creating and testing Virtual Network (VNet) peering connections, and advanced peering options. The goal of this lesson is to gain knowledge and experience with VNet peering, Gateway Transit peering mode, and VPN gateways. VNet peering is important in many scenarios. For example when your organization has resources in different regions or subscriptions. This is also used in many common Azure architecture patterns, such as Hub and Spoke. Good luck and enjoy the lab!

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Create and Configure VNet Peering in Azure

<!-- This file has the lab guide as it sits in CloudCraft at the moment (10-10-19), but it also contains the text James had in it initially. The lab is getting revamped, to account for Azure interface changes, so just make sure when it does that this file looks spiffy when everything is said and done. -->


Welcome to this Azure hands-on lab. We will be creating and testing Virtual Network (VNet) peering connections, and advanced peering options.

The goal of this lab is to gain knowledge and experience with:

  • VNet Peering
  • Gateway Transit peering mode
  • VPN Gateways

VNet Peering is important in many scenarios (for example, when your organization has resources in different regions or subscriptions). This is also used in many common Azure architecture patterns, such as Hub and Spoke.

Good luck and enjoy the lab!

Logging In

Use the provided username and password for logging into the Azure portal.

Starting Cloud Shell

Once we're logged in, open up Cloud Shell (the >_ button at the top of the screen) and choose Bash at the window that pops up toward the screen's bottom. Now click on Show advanced settings. The Subscription and Resource group should both be populated with what we need already. But make sure Cloud Shell region is set to South Central US. We're going to create a new storage account. The name we give it has to be unique across Azure.

Next, select Create new under File share, set a new name, and click the Create storage button. We'll have to sit back and wait a bit for this to take effect. Once it's ready, a good idea might be to maximize that terminal, and log into the Azure portal again in a new browser tab. Then we can flip back and forth between the two.

Resource Group

Before we can create any resources, we need to have a group to place them in. We should have one already. Run this to see:

az group list

We'll get output similar to this:

    &quot;id&quot;: &quot;/subscriptions/0f39574d-d756-48cf-b622-0e27a6943bd2/resourceGroups/;,
    &quot;location&quot;: &quot;southcentralus&quot;,
    &quot;managedBy&quot;: null,
    &quot;name&quot;: &quot;;,
    &quot;properties&quot;: {
      &quot;provisioningState&quot;: &quot;Succeeded&quot;
    &quot;tags&quot;: null,
    &quot;type&quot;: &quot;Microsoft.Resources/resourceGroups&quot;

The name line is what we're most concerned with here.

Create the Gateway Subnet

az network vnet subnet create -g &lt;RGNAME&gt; --vnet-name vnet2 --name GatewaySubnet --address-prefix

In this command, &lt;RGNAME&gt; is what showed up in the name line of the az group list command's output.


Just to make sure, hop over to the Azure portal. On the main page, click on vnet2, then Subnets, and we should see that new one we just created listed there.

Create a Public IP Address

We'll need a public IP in order this to work. Set it with this (again, replacing &lt;RGNAME&gt; with what we used in the last command):

az network public-ip create -g &lt;RGNAME&gt; --name vpngwip --allocation-method Dynamic --sku Basic --version IPv4


To check on whether the command was effective or not, get back into the portal for a second. Go to All resources, click on vpngwip

Create a VNet Gateway

Now we have to create the gateway. This command, like the last two, needs the actual &lt;RGNAME&gt; plugged in:

az network vnet-gateway create --name vpngateway --public-ip-address vpngwip --resource-group &lt;RGNAME&gt; --vnet vnet2 --gateway-type Vpn --vpn-type RouteBased --sku Basic --no-wait

Checking Our Work

Back in the portal, in All resources, we should now see that vpngateway showing up in the list. Click on it, and we'll see a status of Updating. It may not be ready to go for up to a half hour, so now is a good time to take a break.

Logging Into vm1

Before we can actually log into vm1, we need its public IP address. Navigate to All resources again, and click on vm1. Now we can copy the public IP and use it in conjunction with the SSH setup that's coming.

The Key


We can't log into our virtual machine until we've downloaded a private key. In a Linux, Mac, or WSL terminal, simply run:


Change the permissions so we can use it:

chmod 400 ubuntu

Then we can just log in with no password, using:

ssh azureuser@PUBLIC_IP -i ubuntu

PUBLIC_IP here is what we got from the portal a minute ago.

For Windows users that utilize PuTTY, download this key instead. We can launch PuTTY like we normally would, and once we've got the Host Name (or IP Address) filled in, click the + next to SSH in the left Category tree, then click Auth. Browse for the downloaded file in the Private key for authentication section.

Once we hit the Open button, we'll start the SSH session.

Pinging Private VM Addresses

Back in the portal, navigate to All resources again, and find vm2 in the list. We need its private IP address, so we'll have to further navigate to Networking. Copy the private IP address. As an example, we'll use

Now back in the terminal, run:


Grab the private IP for vm3, just like we did for vm2, and try to ping it as well (using here for example):


Both of these tests should fail. It's because we have to edit our virtual networks.

Configure vnet1

Back in the portal, get into All resources again, and select vnet1. Click Peerings in the left pane, and we can set this up. Click Add, then set the following values in the working pane:

  • Name: vnet1-to-vnet2-peer (anything is fine, but it's a good idea to give it an appropriate and descriptive name)
  • Peer details: Set this to Resource manager
    • I know my resource ID: Leave this unchecked.
    • Subscription: Make sure ours is selected. It should be, by default.
    • Virtual network: Select the vnet2 choice from the dropdown.
  • Configuration:
    • Make sure it's set to Enabled

Click Ok, and we'll land back out on the Peering page. Once the one we just set up completes, let's make another one.

Configure vnet2

Click on vnet2 in the left pane. We're going to repeat the process we just finished for vnet1, with a couple of minor differences. Our Name here will be vnet2-to-vnet1-peer (if we're sticking with the previous type of naming convention). Select vnet1 in the Virtual network dropdown. Everything else should be the same as what we set in vnet1.

Click Ok, and we'll land back out on the Peering page. If we wait a bit, we can go check both vnets and see that the PEERING STAUS is Connected in both cases.

Testing Again

Now if we get back into our shell (where we should still be sitting in vm1. Let's try pinging vm2 again (and remember here that this is just a sample IP):


This should be configured properly now, so we'll get responses this time around. We now have verified connectivity between vnet1 and vnet2.

Configure vnet3

To bring vnet3 into the mix, we've got to create peering between vnet2 and vnet3. Complete all of the same steps that we did for vnet1 to vnet2 peering (and vice-versa), but plug in some different values. Click Add from the Peerings working pane. For our vnet2 to vnet3 peering, there will be just a few differences. As a Name, we'll call it vnet2-to-vnet3-peer and set the Virtual network dropdown to vnet3. The last difference will be that here we're going to check the Allow gateway transit box down in the Configuration section.

And for our vnet3 to vnet2 peering, name it vnet3-to-vnet2-peer. Then set the Virtual network dropdown to vnet2. In this configuration, we're going to check the Use remote gateways box.

After a few seconds, we will be able to see a PEERING STAUS of Connected in each one's (vnet2 and vnet3) overview page.

Testing Again

Our shell should still be open, with us sitting in vm1. With the new peering setup, let's try pinging vnet3 from here (using as an example vnet3 private IP address):


We get nothing. vm1 can not talk to vm3 because of what's called "non-transitive routing." Traffic can not pass from one paired vnet to another paired vnet. To test whether of not the vnet2 to vnet3 peering is working, we'd have to log into either vnet2 or vnet3 and ping the other in that pair.


We configured vnet pairing between vnet1 and vnet2, then configured it between vnet2 and vnet3. On the latter, we enabled "Gateway Transit" and set it to use a remote gateway.

> # Questions/comments

Need more explanation about why vnet1 can't ping vnet3. Maybe the students get it, I just don't. Maybe I don't need to?

What are Gateway Transit and remote gateway doing in the vnet2 to vnet3 peering? Why didn't we set them up in vnet1 to vnet2.

Instructions (tasks, really) on the lab page are sparse, and don't have the same names for things as in the video. Have to look again and either incorporate spoke/hub into the lab guide (more likely), or nix it from the lab page.


NOTE: Please be aware that the VNet Peering creation experience has changed within the Azure Portal. An updated video will be provided as soon as possible. In the meantime, the concepts taught within this lesson still apply, and the instructions have been updated below.

Please go ahead and log in to the live environment with the Azure Labs credentials provided.

Make sure you are using the southcentralus region throughout the learning activity.

Follow the steps below. Try them without the videos first, and then use the videos to verify your solution.

In order to connect to the VMs for testing, please use the following information:

  • Use SSH to log into into the VM.
  • Linux, Mac, or users with Windows Subsystem for Linux (WSL) can use SSH.
    • Other users may wish to use PuTTY (for example on Windows when WSL is not installed).
  • Download the files below
    • Linux users may use wget
    • Windows users can right click the link and "Save as"
  • See Task 2 - Configure VNet Peering between spoke and hub VNets for detailed instructions.

Linux, Mac, and WSL users can run:


Windows/PuTTY users can use this download link:

Click the question marks below to view more details for each task.

Make sure to wait 20-30 minutes after creating the Virtual Network Gateway before going to Video 3. Some of the tasks in the third video are dependent on the virtual Network Gateway being deployed. If an error occurs saying "Failed to add virtual network peering" when you try to add VNet3 to VNet2 peering, this is the result of the Virtual Network Gateway not being finished deploying.

As a note: when creating the VNet, peers are now created on the same blade.

Configure a VPN Gateway in the hub VNet

Configure a VPN Gateway using the Azure CLI using the following settings:

  • VPN Gateway Public IP
    Resource Group: Existing resource group
    Name: vpngatewayip
    SKU: Basic
    IP Version: IPv4
    Address Assignment: Dynamic

  • VPN Gateway
    Resource Group: Existing resource group
    Name: vpngateway
    SKU: Basic

Use These Instructions as a Guide:

> Note: The resource group has already been created for you.

  1. Connect to the environment: az login
  2. Identify the existing Resource Group: az group list
  3. Create the Gateway Subnet: az network vnet subnet create -g rgname --vnet-name vnet2 --name GatewaySubnet --address-prefix
  4. Create a public IP address: az network public-ip create -g rgname --name vpngwip --allocation-method Dynamic --sku Basic --version IPv4
  5. Create a VPN Gateway: az network vnet-gateway create --name vpngateway --public-ip-address vpngwip --resource-group YourResourceGroupName --vnet vnet2 --gateway-type Vpn --vpn-type RouteBased --sku Basic --no-wait

> We are not going to complete the configuration of the VPN Gateway, as this it is just being used to help demonstrate Gateway Transit configuration.

Configure VNet Peering Between spoke and hub VNets

Important notes:

  • In the architecture of this hands-on-lab, we consider 'vnet1' and 'vnet3' to be "spoke VNets". Both of these VNets connect to 'vnet2' which is considered the "hub VNet".
  • The VNet Peering creation process has been simplified by Microsoft and both outbound and inbound peerings can be created in a single step within the portal, as below.
  • Ensure your VNet Gateway creation is complete (does not show "updating" status) before creating the final VNet Peering using Gateway Transit.

Configure VNet Peering through the Azure Portal using the following settings. The steps are provided below.

VNet Peering Settings:

  • VNet 1 - VNet 2 Peering
    VNet: vnet1 > Add Peering
    Name: vnet1-to-vnet2-peer
    Peer details: Resource manager
    Subscription: Select your current subscription
    Virtual network: Select vnet2
    Return peer: vnet2-to-vnet1-peer
    Configuration/Forwarding/Gateway: Leave unchanged
  • VNet 2 - VNet 1 Peering
    This is now created in a single step when creating the VNet 1 to VNet 2 peering

  • VNet 2 - VNet 3 Peering (with transit)
    VNet: vnet2 > Add Peering
    Name: vnet2-to-vnet3-peer
    Peer details: Resource manager
    Subscription: Select your current subscription
    Virtual network: Select vnet3
    Return peer: vnet3-to-vnet2-peer
    Configuration: Leave unchanged
    Forwarding: Leave unchanged
    Configure gateway transit: Tick the tickbox

>Note: If you receive a "retryable error" when creating this peering, you may not have finished creating your VNet Gateway.

How to create VNet Peers in the portal:

  1. Login to the Azure Portal.
  2. Click on Virtual Networks.
  3. Select the VNet.
  4. Click on Peerings, within the Settings section.
  5. Click on the + Add button.
  6. Configure according to the settings above.
  7. Create both the outbound and inbound peer (e.g. vnet1-to-vnet2-peer and vnet2-to-vnet1-peer)

>When you click OK after adding the VNet Peer, you will see two jobs are submitted, and appear in the Notifications section of the Azure portal.

Test the Peering Connectivity:

  1. Connect to a VM to perform some network tests:
    • For Linux, Mac, or Windows Subsystem for Linux
      • Download the private key ("ubuntu") from the instructions using wget
      • Open the shell or terminal
      • Change permissions of the key: chmod 400 &lt;name of downloaded key&gt;
      • Connect using ssh and the downloaded key: ssh azureuser@&lt;vm public ip&gt; -i &lt;name of downloaded key&gt;
    • When using PuTTY (commonly used on Windows)
      • Download/install PuTTY
      • Download the PuTTY private key from the instructions ("puttyKey.ppk")
      • Open Putty
      • Click Connection > Data, and set the Auto-login username to azureuser
      • Click Connection > SSH > Auth
      • Click Browse next to the Private key file for authentication setting
      • Choose the puttyKey.ppk file you downloaded earlier
      • Click Session on the settings menu at the top left
      • Next to Host Name enter the public IP address of the VM
      • Ensure SSH is selected
      • Click on Open
  2. Perform a test ping from spoke1_vnet to hub_vnet:
    • What does this tell you?
    • Why does this work or not work?
  3. Perform a test ping from spoke1_vnet to spoke2_vnet:
    • What does this tell you?
    • Why does this work or not work?
  4. If you had a VPN gateway connected, which spoke vnet could use it? Why?