Understanding the Azure VNet-to-VNet Scenario

Developed with
Microsoft

Lab Steps

lock
Logging into the Microsoft Azure Portal
lock
Understanding the Azure VNet-to-VNet Scenario
lock
Creating an Azure VPN Gateway in the Portal
lock
Starting an Azure Cloud Shell
lock
Creating an Azure VPN Gateway with the Azure CLI
lock
Establishing the VNet-to-VNet VPN Connection
lock
Testing the Vnet-to-VNet VPN Connection
lock
Validate Connect Azure Virtual Networks with VNet-to-VNet VPN Connections
live-help Need help? Contact our support team

Here you can find the instructions for this specific Lab Step.

If you are ready for a real environment experience please start the Lab. Keep in mind that you'll need to start from the first step.

Introduction

Connecting Virtual Networks with VNet-to-VNet Connections

This Lab guides you through establishing a VNet-to-VNet connection between Azure virtual networks (VNets). VNets connected with a VNet-to-VNet connection can communicate through a secure IPSec/IKE encrypted tunnel using Azure's backbone network without ever traversing the public Internet. Each Virtual network connected via a VNet-to-VNet connection includes a VPN gateway resource. VNet-to-VNet connections are one of several approaches to connecting VNets. The following list contrasts VNet-to-VNet and the other approaches:

  • Site-to-Site: Also utilize VPN gateways for connectivity but require configuration of a local network gateway. The local network gateway configuration is handled automatically by Azure and is invisible to clients when using VNet-to-VNet connections. Because you can configure the local gateway for Site-to-Site connections, they can be used for more complicated network configurations. Site-to-Site connections can also be used to connect an Azure VNet to an on-premises network.
  • VNet peering: Connects VNets without requiring a gateway. Traffic also does not route over the public Internet. Because traffic stays on Azure's backbone, no encryption is performed. When VNets are in the same region, the bandwidth and latency between resources are the same as if the resources were in the same VNet. Because no gateway is involved, the pricing model for VNet peering differs from VNet-to-VNet and is entirely based on inbound and outbound data transfer. VNet peerings also have their own constraints

You may consider VNet-to-VNet over the alternatives for:

  • Setting up your own geo-replication or synchronization with secure connectivity over Azure's backbone
  • Setting up multi-tier applications with isolation or administrative requirements determining the boundaries between multiple VNets

It is important to note that the VNet-to-VNet can be combined with multi-site configurations and VNet peering.

Understanding the Lab Environment and Goals

When you started the Lab, the Cloud Academy Lab environment created VNets for you to connect using a VNet-to-VNet connection. The resources are shown in the following diagram:

alt

The VNets in this Lab are in the different regions and the same Azure subscription. VNet-to-VNet connections can also be established if the VNets are in different subscriptions and associated with different Azure Active Directory tenants. The address spaces of the VNets do not overlap. This is a requirement for connecting VNets. The Fabrikam VNet has a Web virtual machine that is running a web server on port 80, The goal of the Lab is to create the VNet-to-VNet connection and test the VNet-to-VNet connection by accessing the web server from the Dev virtual machine in the Cloud Academy Labs VNet. The following diagram depicts the final Lab environment:

 alt

You will learn more about VPN gateways as you continue through the Lab. In the remainder of this Lab Step, you will briefly explore the resources created in the Lab environment.

 

Instructions

1. Enter resource groups in the Portal's search bar and click Resource groups under Services in the drop-down results menu:

alt

 

2. Click the Lab's resource group which begins with cal- (Cloud Academy Labs):

alt

 

3. Click Deployments in the blade's navigation panel and ensure the deployment has reached the Succeeded state:

alt

It takes around four minutes from the time you start the Lab to the time the deployment succeeds. If the deployment hasn't succeeded, periodically refresh the list until you see it has Succeeded.

 

4. Click Overview in the navigation panel and view the table of resources:

alt

The resources correspond to ones in the initial Lab environment diagram. The address ranges for the virtual networks and subnets as well as the private IP addresses of the VMs match those in the diagram. The fabrikam-web VM is running a web server. There is also a storage account to facilitate using Azure Cloud Shell later in the Lab (name beginning with cacloudshell), in addition to two storage accounts for VM boot diagnostics that will facilitate using the VM serial console later in the Lab. 

 

Summary

In this Lab Step, you learned about VNet-to-VNet connections and when you might prefer to use them. You also understood the resources created for you in the Lab environment and the goal of the remaining Lab Steps.