VNet-to-VNet: Connecting Virtual Networks in Azure across Different Regions

Overview

At TechEd 2014, we released Multi-Site VPNs, in-region VNet-to-VNet, and cross-region VNet-to-VNet features. This blog is the first of a mini-series to walk you through the configuration steps and examples of how you can connect your virtual networks together using the VNet-to-VNet feature.
VNet-to-VNet connectivity utilizes the Azure VPN gateways to connect two or more virtual networks together securely with IPsec/IKE S2S VPN tunnels. Together with the Multi-Site VPNs, you can connect your virtual networks and on-premises sites together in a topology that suits your business need. The diagram below shows a simple example of a fully connected topology between virtual networks and on premises sites.
There are several scenarios this connectivity can enable. Below is just a partial list:

1. Cross region geo-redundancy and geo-presence; e.g., SQL AlwaysOn across different Azure regions
2. Cross subscription, inter-organization communication in Azure
3. Regional multi-tier applications with strong isolation boundary; or connecting existing workloads in different VNets together to form new applications

Considerations

There are a number requirements and considerations on the VNet-to-VNet feature documented here. Below is a short list of the key points:

1. You MUST create or use the Azure Dynamic Routing VPN gateways to connect your virtual networks. Static Routing VPN gateways are NOT supported for VNet-to-VNet.
2. For each virtual network, you can connect up to 10 “networks”; i.e., both virtual networks and on premises sites combined cannot exceed 10.
3. You need to ensure that the address prefixes don’t overlap among all the connected networks.
4. VNet-to-VNet feature works across regions and subscriptions – same or different regions, single or across subscriptions.

With that in mind, let’s build a simple example from scratch to connect the VNets!

Connecting Two VNets in the Same Subscription

From an Azure virtual network, connecting to another virtual network is essentially the same as connecting to an on premises network via site-to-site (S2S) VPN. In this blog, we will start from scratch to create the virtual networks, the VPN gateways, and then connect them together, all within the same Azure subscription. Below lists the steps you will go through:

1. Create the virtual networks and matching local networks with cross premises connectivity
2. Create the Azure Dynamic Routing VPN gateways for the virtual networks
3. Connect the virtual networks together

Using the following diagram as an example, we will create and connect the two virtual networks, VNet1 and VNet2, together:

• VNet1: Address Space = 10.1.0.0/16; Affinity Group = WestUS
• VNet2: Address Space = 10.2.0.0/16; Affinity Group = NorthEurope

In the example below, we will be using the Azure PowerShell cmdlets. Please refer to the Azure PowerShell instruction pages to install and configure your PowerShell environments:

• Azure PowerShell on MSDN: http://msdn.microsoft.com/en-us/library/azure/jj156055.aspx
• How to install and configure Windows Azure PowerShell: http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

Please note that for a simple VNet-to-VNet setup as described here, you can use the Azure Management Portal to carry out steps 1 and 2 below. We use PowerShell because as we continue to add more connections to the VNet (e.g., Multi-Site VPNs), Azure PowerShell cmdlets or REST APIs are the only options to configure these features currently.

[Step 1] Create VNet1 and VNet2 and the Corresponding Local Networks

The first step is to create the two virtual networks, and the matching local networks. From the perspective of each virtual network, e.g., VNet1, the other virtual network, VNet2, is just another VPN connection defined in the Azure platform. As a result, customers must create and define the following connections:

Virtual Network	Virtual Network Site Definition	Local Network Site to Connect
VNet1	VNet1 (10.1.0.0/16)	VNet2 (10.2.0.0/16)
VNet2	VNet2 (10.2.0.0/16)	VNet1 (10.1.0.0/16)

Please note that you will need to define each virtual network twice: first as an Azure virtual network, then as a local network site connected to the other virtual network. You must ensure the Address Space elements specified in both definitions are the same, or the communication will not work correctly between the two virtual networks. To make things easy to read, the example uses the same name for both definitions of the virtual network and the local network. This is not a requirement, but will make reading the definitions easier.
The following PowerShell cmdlets create the two Affinity Groups for the two virtual networks. Note that you can re-use existing Affinity Groups of the same regions if you prefer:

PS D:\> New-AzureAffinityGroup -Name WestUS -Location "West US"
PS D:\> New-AzureAffinityGroup -Name NorthEurope -Location "North Europe"

Once the Affinity Groups are created, you can export the current network configuration file (NETCFG.XML) with following cmdlet:

PS D:\> Get-AzureVNetConfig -ExportToFile "D:\MyCurrentNETCFG.XML"

To create the two new virtual networks and the corresponding local networks, use a text editor such as Notepad.exe to insert the following segment into the NETCFG file, in this case, MyCurrentNETCFG.XML:

   name="VNet1">
    
      10.1.0.0/16

1.0.0.1 name="VNet2"> 10.2.0.0/16 2.0.0.2 name="VNet1" AffinityGroup="WestUS"> 10.1.0.0/16 name="Subnet-1"> 10.1.0.0/24 name="GatewaySubnet"> 10.1.200.0/29 name="VNet2"> type="IPsec" /> name="VNet2" AffinityGroup="NorthEurope"> 10.2.0.0/16 name="Subnet-1"> 10.2.0.0/24 name="GatewaySubnet"> 10.2.200.0/29 name="VNet1"> type="IPsec" />
The segment above defines two virtual networks, VNet1 and VNet2, and two local networks, also called VNet1 and VNet2. Please note the following before we proceed further:

1. For simplicity, there is only one subnet (“Subnet-1”) besides the “GatewaySubnet” in each virtual network, and the DNSServersRef element is skipped in the example above. We also skip the “VPNClientAddressPool” element. You can add those elements to your NETCFG as needed.
2. If you already have “LocalNetworkSites” and “VirtualNetworkSites” sections in your NETCFG, please copy the corresponding “LocalNetworkSite” elements and the “VirtualNetworkSite” elements into those two sections.
3. The “VPNGatewayAddress” for the LocalNetworkSite is the VIP (Public IP) address of the corresponding Azure VPN gateway for the virtual network. The actual address will not be available until the Azure VPN gateway is created. Right now, we use “1.0.0.1” and “2.0.0.2” as the temporary placeholders for the two addresses.

Once this is done, save the new NETCFG as “MyNewNETCFG.XML”, and use the following PowerShell cmdlet to upload the updated NETCFG file to your Azure subscription:

PS D:\> Set-AzureVNetConfig -ConfigurationPath D:\MyNewNETCFG.XML

This step will take a couple of minutes to complete. Once completed, you will be able to see the virtual networks and the local networks from the Azure Portal.

[Step 2] Create the Dynamic Routing VPN gateways for each virtual network

Once the virtual networks are created with the corresponding VPN connections, the next step is to create the Azure VPN gateway for each virtual network. This can be done through either Azure Management Portal, or Azure REST APIs. Only the Dynamic Routing gateway type is supported. Please note that currently, Azure PowerShell cmdlet “New-AzureVNetGateway” does NOT support creating a dynamic routing gateway. (We are working on filling this gap in Azure PowerShell. Please stay tuned …)
From the Azure Portal, navigate to the “Networks” page, then go to the “Dashboard” page of both VNet1 and VNet2. At the bottom of each page, click “Create Gateway” and select “Dynamic Routing” as shown below:

[Step 3] Connect the VPN gateways

After both gateways are created, you will be able to get the public IP addresses of these two VPN gateways either from the Portal or with the following cmdlets:

PS D:\> Get-AzureVNetGateway -VNetName VNet1 | ft VIPAddress
VIPAddress
----------
191.xxx.82.62

PS D:\> Get-AzureVNetGateway -VNetName vnet2 | ft VIPAddress
VIPAddress 
---------- 
191.yyy.135.20

The xxx and yyy are real numbers masked out for obvious security reason. Once the gateway public IP addresses are available, update the NETCFG segments for VNet1 and VNet2 LocalNetworkSite definitions to match the IP addresses in your NETCFG file, MyNewNETCFG.XML:

   name=“VNet1”>
    10.1.0.0/16

191.xxx.82.62 name=“VNet2”> 10.2.0.0/16 191.yyy.135.20 The upload the updated NETCFG file again:

PS D:\> Set-AzureVNetConfig -ConfigurationPath D:\MyNewNETCFG.XML

The last step is to set the IPsec/IKE pre-shared keys to be the same. This can be done via Azure REST API or Azure PowerShell cmdlet. The example below uses PowerShell cmdlet to set the key value to A1b2C3d4:

PS D:\> Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey A1b2C3d4
PS D:\> Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName VNet1 -SharedKey A1b2C3d4

Once these steps are completed, VNet1 and VNet2 will be connected together after the IPsec/IKE establishes the S2S VPN tunnel. The following cmdlets will show the connectivity status:

PS D:\> Get-AzureVNetConnection -VNetName VNet1 | ft LocalNetworkSiteName, ConnectivityState

LocalNetworkSiteName                       ConnectivityState 
--------------------                       ----------------- 
VNet2                                      Connected

PS D:\> Get-AzureVNetConnection -VNetName VNet2 | ft LocalNetworkSiteName, ConnectivityState
LocalNetworkSiteName                       ConnectivityState 
--------------------                       ----------------- 
VNet1                                      Connected

This shows that VNet1 is now connected to VNet2! The traffic will start flowing between the two virtual networks if you already have VMs inside the virtual networks.
Please note that the Connectivity State is only refreshed every 5 minutes from the Azure platform. So it may take up to 5 to 7 minutes to have the connectivity state updated to show the “Connected” states even though the connection will be established typically within a minute after the keys are set correctly.
Source:

www.technet.microsoft.com

Published By

S.G.Godwin Dinesh.MCA
Sr.System Administrator