Connecting Multiple Networks in Microsoft Azure

In a previous article, I explained how to create a 1:1 connection between two Azure virtual networks (VNETs) using VNET-to-VNET VPN. In this article, I will show you how to connect multiple networks together in Microsoft Azure.

When Should I Connect Multiple Azure Networks?

There are many situations where you might need to connect more than two VNETs together using VPN connections. Some of these might include:

• A disaster recovery scenario with on-permises network for Active Directory replication, an Azure VNET for failing over machines using Azure Site Recovery (ASR), and another VNET for RemoteApp.
• Achieving geo-distribution or fault tolerance for a service by placing it in more than two regions, as shown in the following diagram.

Prerequisites

There are a number of prerequisites for connecting more than two networks in Azure:

IP Addressing

Each network, on-premises or an Azure VNET, must have a unique network address in your finished solution. For example, you cannot connect an on-premises network with an address of 10.0.0.0/8 to an Azure VNET with the same address. Plan your addressing for site expansion. In the previous example, an Azure VNET with a network address of 10.2.0.0/16 might be used to connect to an on-premises network of 10.1.0.0/16.

Dynamic Routing Gateway

Azure VNETs support static routing and dynamic routing gateways, where each network must be deployed with a dynamic routing gateway if more than two networks will be connected. Make sure that your on-premises VPN device (such as edge firewall) supports connections to dynamic routing gateways.

Temporary Local Network

You must have a local network to enable a gateway in an Azure VNET, but you cannot create your required local networks until you have the necessary public IP addresses of the gateways. This chicken and egg scenario requires the usage of a temporary local network.
Create a temporary local network that has:

• A random and valid public IP address
• A random, but valid network address

Deploy the Solution

Create the necessary networks in Azure. In this example, I am going to connect three Azure VNETs, as shown in the above diagram.

Create the Gateways

Edit the settings of your Azure VNETs, check the box to Connect To The Local Network, and select the temporary local network that you have already created.

Browse back to the Dashboard of each VNET, click Create Gateway, and select Dynamic Routing. It will take around 25 to 45 minutes for the gateway to be created. You cannot proceed until this is completed. Once completed, browse to the dashboard of each VNET and note down the gateway IP address.

Create Local Networks

The role of a local network in Azure is to allow a VNET gateway to know:

• The public IP address of the other network(s) to connect to via VPN
• What network addresses should be routed via the VPN connection

Each VNET will be connecting to each other VNET in this design. This means that you need to create a local network for each VNET. Net1 will connect to the local networks of Net2 and Net3, and so on. I find it useful to write down the details of the networks before deploying anything:

Local Network Name	Gateway IP Address	Starting IP	CIDR (Address Count)
Net1LocalNetwork	23.100.XX.XX	10.1.0.0	/16
Net2LocalNetwork	23.100.XX.XX	10.2.0.0	/16
Net3LocalNetwork	23.101.XX.XX	10.3.0.0	/16

Click New > Network Services > Virtual Network > Add Local Network to launch the wizard to create each local network in turn.

Configuring Local Networks

In a 1:1 site-to-site VPN connection, we normally would set the local network of a VNET to point at the other network. However, the drop-down select box only allows you to select one item, and we need each VNET to have two local networks.
We can accomplish this requirement by:

1. Exporting the Azure subscription network settings to an XML file
2. Editing the XML file
3. Importing the XML file to apply the changes

Launch an Azure PowerShell window, and run the following snippet:

Get-AzureVNetConfig -ExportToFile "C:\Temp\MyAzureVNetConfig.XML"

Edit a copy of the XML file using a text editor, such as Notepad, and search for <VirtualNetworkSites>. Here’s where you will find the definition for each VNET, the gateway for the VNET, and the local network that the gateway is configured to connect to. Search for <ConnectionsToLocalNetwork>; each local network requires the following:

<LocalNetworkSiteRef name="NameOfLocalNetwork">
              <Connection type="IPsec" />
</LocalNetworkSiteRef>

Edit the existing line for the temporary local network and replace the name (shown as Temp) with the required local network. You can then copy and paste the lines to add additional local networks.

Each VNET should be edited to connect to the local networks of the other VNETs. Here is an example of Net1 connecting to Net2 and Net3:

You can import the XML file once you save it. Browse to New > Network Services > Virtual Network > Import Configuration and select the edited XML file. The management portal is poor at reporting syntax errors in the XML file. Instead, use PowerShell to import the network configuration XML file — you will be told exactly where formatting errors are if there are any:

Set-AzureVNetConfig -ConfigurationPath "C:\Temp\MyAzureVNetConfigCopy.XML"

Set the Shared VPN Keys

Each VNET gateway now knows which network it needs to connect to; however, they do not have a shared key to enable a secure connected. Create a long passphrase or random string that will be used for each connection:

• Net1 to Net2
• Net2 to Net3
• Net1 to Net3

Then run this PowerShell script, substituting the shared key as required:

Set-AzureVNetGatewayKey -VNetName Net1 -LocalNetworkSiteName Net2LocalNetwork -SharedKey $Secret12
Set-AzureVNetGatewayKey -VNetName Net2 -LocalNetworkSiteName Net1LocalNetwork -SharedKey $Secret12
Set-AzureVNetGatewayKey -VNetName Net2 -LocalNetworkSiteName Net3LocalNetwork -SharedKey $Secret23
Set-AzureVNetGatewayKey -VNetName Net3 -LocalNetworkSiteName Net2LocalNetwork -SharedKey $Secret23
Set-AzureVNetGatewayKey -VNetName Net1 -LocalNetworkSiteName Net3LocalNetwork -SharedKey $Secret13
Set-AzureVNetGatewayKey -VNetName Net3 -LocalNetworkSiteName Net1LocalNetwork -SharedKey $Secret13

Verify the Connections

The dashboard of each VNET should start to show a connection coming online within a few minutes of setting the shared keys. You can then verify communications. In my lab, I deployed a VM to each VNET, enabled ICMP in the Windows Firewall, and ran some tests: