Microsoft Azure: Connecting multiple VNET's to a VNET.

Artykuł
07/18/2014

UPDATE: Microsoft has implemented VNET PEERING, which makes this article obsolete. For more information about Azure VNet Peering: /en-us/azure/virtual-network/virtual-network-peering-overview

Introduction

Recently, Microsoft has introduced a new feature in Microsoft Azure to allow a direct VPN connection between multiple Virtual Networks (VNets). In this blog post I will explain how to connect multiple VNets to each other within Microsoft Azure.

A good starting point to read more on how to configure a connection between two VNets can be found here: Configure a VNet to VNet Connection and Creating a Stretched Network on Microsoft Azure. The examples give you great guidance on how to configure VNet <--> VNet connectivity.

From the Virtual Network FAQ we read that we connect multiple VNets to each other:

Q: How many on premises sites and virtual networks can one virtual network connect to?
A: Max. 10 combined; e.g., one Azure virtual network and connect to 6 on premises sites and 4 virtual networks.

Yet, configuring a connection from one VNet to multiple other VNets is not as trivial as it perhaps should be. So what if you want to create some "star" topology? Or you need to connect two VNets to one other VNet? None of the articles mentioned before care to explain how something like that could be configured, but things functionality in Microsoft Azure will unleash new scenario's that previously where only possible using multiple VPN connections to on-premises locations. This is specifically try for people that want to deploy geo-redundant IaaS or PaaS solutions in Azure.

Solution

Let's assume you want to deploy two Cloud Services, in two different Microsoft Azure Datacenters. By using Microsoft Azure Traffic Manager, you can make sure that clients connect to that specific Cloud Service that performs best for their locations. (For any geographically dispersed, geo-redundant, solution, this should be something that you at least take a look at.) A Cloud Service would be deployed in a Virtual Network, and a Virtual Network is tied to Microsoft Azure Datacenter. Hence, both Cloud Services would be deployed in their own Virtual Network. Previously, if these Cloud Services would need to connect to a "shared resource", like a Microsoft SQL Database, the only option would be to connect both Virtual Networks to an on-premises VPN endpoint (for example a Cisco- or Juniper device, or a Windows Server 2012 R2 Routing and Remote Access Server.) Then, the on-premises equipment could route traffic between the two VNets. All traffic between the two VNets would then be routed through the on-premises infrastructure.

So let's assume we have this sort of solution; deployed in two different Microsoft Azure Datacenters, and they both need to connect to a Microsoft SQL Database on the back-end. This Microsoft SQL Database is deployed on Microsoft Azure Infrastructure-as-a-Service, running in a third Microsoft Azure Datacenter, in it's own Cloud Service (Let's call it CSDB) and it's own Virtual Network (Let's call it VNET3). The front-ends are deployed in two Cloud Services (let assume the are named CSINET1 and CSINET2) and their corresponding Virtual Networks (Let's call these VNET1 and VNET2).

The goal here is to enable traffic to flow from VNET1 to VNET3 (and vice-versa) and from VNET2 to VNET3. Hence, we would need to connect VNET3 to two different Vnets; VNET1 as well as VNET2. Something like this: VNET1 <--> VNET3 <--> VNET2.

Here is the configuration of VNET1:

You see that we use the address space 10.1.0.0/16 for this virtual network. The servers live in the Subnet-1 subnet; 10.1.0.0/19. We have created a Gateway Subnet called Gateway with IP network range 10.1.32.0/29.

The configuration for VNET2 is the same, except that we now use the 10.2.x.x address space:

For our last network, VNET3, where the database "lives", we use 10.3.x.x:

Please do keep in mind that connection Azure Virtual Networks to other Azure Virtual Networks ONLY works when the gateway has been setup using Dynamic Routing.

If we want to connect a Virtual Network to another network (whether it be a Virtual Network or an on-premises network) we will have to define the network address range(s) for these networks in Microsoft Azure, under Local Networks. In our demonstration, we will create a Local Network for VNET1, VNET2 and VNET3, with their corresponding network ranges. (If you have not already created your Gateways in the Virtual Networks, simply put a bogus VPN Address in the dialog. We can change that later.)

Now, from the Microsoft Azure Management Portal, we can connect VNET1 to VNET3 and VNET2 to VNET3.

If you need any assistance completing the previous steps, please consult Configure a VNet to VNet Connection. This will guide you through the process of creating the gateways, the local networks and connecting a Virtual Network to another Virtual Network.

Now, the real challenge starts when we want to configure VNET3 to connect to two other Vnets; VNET1 and VNET2. We cannot do this through the current Microsoft Azure Management Portal. Once we "connect" VNET3 to one of the other subnets, through the portal, we can no longer connect this VNet to another VNet. Apparently, what we want is not possible from the portal (currently).

To connect VNET3 to the remaining Vnet:

From the Microsoft Azure Management Portal, download the configuration for your Virtual Network:

Let's assume you save this file as vnet.xml on your local machine.

Alternatively, you can use PowerShell to export the configuration by using this command:

Get-AzureVNetConfig -ExportToFile C:\Temp\VNET.xml

Open the VNET.xml file using notepad (or similar text editor) and locate the VNet configuration part for the VNet that you want to connect to multiple other VNet's. In our example, that is VNET3.

Locate this section:

Under that section, there should be a Gateway section, that shows you the current gateway configuration. This is where need to make our changes.

Locate the Gateway section in the VirtualNetworkSite section:

In this case, our VNET3 already had a connection with VNET1, but we need to add a connection to VNET2. We add the appropriate section to this Gateway section. It should now look like this:

Save this modified xml file, and import it into Azure;

Set-AzureVNetConfig -ConfigurationPath C:\Temp\VNET.xml

Make sure that your command completes successfully:

OperationDescription OperationId OperationStatus
-------------------- ----------- ---------------
Set-AzureVNetConfig 01fc891b-c4a5-ceb3-9a70... Succeeded

The new configuration should now be applied to Azure. When you open the Azure Management Portal and navigate to Virtual Networks, select the network you just modified, you will see that the GUI for the Dashboard has changed. You see that your virtual network is trying to connect to two other virtual networks. From the Azure Management Portal, you are no longer allowed to make any changes: (this screenshot is from a different setup, with different VNet names, but you'll get the idea...)

Although we see that there are now two virtual network connections, Azure is unable to connect the two virtual networks. This is because the shared keys for the gateways have not been (properly) set. We need to fix this. (And we cannot do this through the Azure Management Portal.) So we fix these keys through PowerShell:

Set-AzureVNetGatewayKey -VNetName VNET3 -LocalNetworkSiteName VNET1 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET3 -LocalNetworkSiteName VNET2 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET2 -LocalNetworkSiteName VNET3 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET1 -LocalNetworkSiteName VNET3 -SharedKey SuperSecretKey

In this example, I set the keys for all Gateway connections but that is not required. You can use different keys for different networks and you don't have to change existing keys. Now give your gateways some time to bring up the connection, and check the Dashboard for the virtual networks to see if the connections work. You should see something resembling this:

If you have Virtual Machines in for example VNET1, you can now connect to other Virtual Machines in VNET3. From machines in VNET2 you can connect to machines in VNET3. Please do keep in mind that using this simple sample configuration will not allow you to connect from machines in VNET1 to machines in VNET2, or vice versa, directly. If that's what you want, you can setup a new network connection following the same procedure.

That's it! You've managed to connect multiple virtual networks to another virtual network in Microsoft Azure.

Comments

Anonymous
January 01, 2003
Microsoft Azure: Connecting multiple VNET's to a VNET.
thank you
Anonymous
April 28, 2015
Thanks! This was a big help and helped me accomplish my goal!
Anonymous
May 12, 2015
There appears to be a very serious flaw in this article. You need to issue a -connect command or your networks will never connect.https://msdn.microsoft.com/en-us/library/azure/dn495121.aspx
Anonymous
May 15, 2015
@Ron - I did not need to issue a -connect command after I used the above process.
Anonymous
July 01, 2015
Build a script to automate the process.
https://tombwu.wordpress.com/2015/07/02/build-complex-cross-azure-subscription-windows-lab-by-using-azure-site-to-site-vpn/
Anonymous
July 30, 2015
Thanks Tino, this was the missing sauce to getting my meshed network going. :)
Anonymous
October 19, 2015
Perfect! Thanks for the nice explanation.
Anonymous
March 16, 2016
The comment has been removed
- Anonymous
  March 31, 2016
  You will have to make sure that all Virtual Networks know how to reach the clients. Most likely, the Local Network that defines the address space for your local site, is only known in VNET3. Hence, only hosts in VNET3 can actually reach the local site. If you want other VNET's to be able to reach the local site, you will have to add the local site's address space to the Local Networks that VNET1 and VNET2 connect to. (E.g. VNET1 is connected to a Local Network, let's say LOCALVNET3. You need to add the address space for your local site to the LOCALVNET3 address space.)Alternatively, you can use User Defined Routes in VNET1 and VNET2 to accomplish the same.

Udostępnij za pośrednictwem

Microsoft Azure: Connecting multiple VNET's to a VNET.

Introduction

Solution

Comments

Dodatkowe zasoby