Azure Multi-VNET Topologies in the ARM Era (Part 2)

This article is the second (and the last) one of the series dedicated to Azure Multi-VNET Topologies in ARM implementation. You may find the first article here: .

We will continue with the implementation of the technical solution as it was defined in the first article.

Technical Solution for the Given Scenario

The diagram for the technical solution we proposed is below:


The solution is composed of 3 main segments:
1. VNET peering between VNET2 and VNET1 (both VNETs being in the same datacenter)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1, configured in the VNET Peering settings directly.



a. VNET Peering configuration

The first part of our implementation consists in putting in place the NET Peering configuration between VNET1 and VNET2.

For this, in the “net1dublin” Settings, section Peerings, we will add a new peering, by giving it a name, selecting the corresponding VNET (“vnet2dublin” in our case):

Keep all other values by default (for the moment).
You should have the successful message right after that:


Then you will see the peering listed in the Peerings list:


See that the Peering status is “Initiated” at this stage.

Similarly, let’s add a peering in the other way – “net2dublin” to “net1dublin”:


Here it is, listed in “net2dublin” ‘s Peerings list:


Quickly, both Peerings pass in the Connected state. You can see it if go back  in “net1dublin” ’s Peerings list:


And that’s all for the VNET Peerings part Smile

Testing the VNET Peering

At this point, you can already test the connectivity between the two virtual machines deployed across the networks. Download the proposed RDP file for the first VM (click “Connect” in the VM blade), connect via RDP to the VM, “vm1net” (private IP identified as, and then ping the second one, “vm2net2” (private address


In the same way, test the connectivity from vm2net2 to vm1net1:


You may remark the very fast response time between the two VMs (and the underlying networks).


b. VNET-to-VNET VPN configuration

Now let’s add the VNET-to-VNET VPN configuration. We will start by creating a first VPN Gateway, “gw1net1”, for “net1dublin”. From the Azure portal, add a new Virtual Network Gateway as follows:


Note the main steps during this configuration:
- selection of the gateway type: VPN
- selection of the VPN type: route-based (known also as “dynamic” gateway)
- selection of the SKU (which will give you the expected performance level)
- selection of the VNET
- configuration of the IP address range for the gateway instances (which will create behind a dedicated subnet in our VNET)
- configuration of the Public IP Address (newly created, by default, or select an existing one).

The result (after 30-45 min, the gateway provisioning is quite long) will look as follows:


The same steps will be followed for the second VPN Gateway, “gw3net3”:


And here is the result for this configuration:


After creating the gateways, we will create the connections between the gateways. We need to create 2 VNET-to-VNET connections, that is one connection from the first gateway to the second, and another way around.

From the gateway “gw1net1” Settings, Connections, add a new Connection “conn-net1-net3”:


Configure it as follows:
- type: VNet-to-VNet
- second gateway: “gw3net3”
- shared PSK key (a string to your choice).

Here is the result:


The connection is created, but the status either “Unknown” or  “Not connected” at this stage:


The connection with its details:

Going to the second gateway, we will see that the connection is also listed here:


Proceed in the same way to create a connection “conn-net3-net1”, from “gw3net3” to “gw1net1”. After a few seconds (52, to be precise Smile ), we have the result :


At this stage, you will see the 2 connections in both “gw1net1” and “gw3net3” settings.

After a few minutes of attempts, you will see the 2 connections passing in “Connected” status:


Testing the VPN connection

If you connect remotely to “vm3net3”, from there you will be able to ping the VM “vm1net1”:


Note the ~25ms response time between the 2 datacenters at a few hundreds kilometers distance, which is a very good performance indeed.

c. Connection Transitivity

There is one last piece missing from the assembly : connectivity between “vnet2dublin” and “vnet3amsterdam”.

Due to the awesome implementation of the Peering feature, this will be solved by 2 clicks configuration only:

1. In the “net1dublin” settings, “net1-net2-peer” peering, under Configuration, check “Allow gateway transit” checkbox:

(note that the service detects the existence of a VPN gateway in the VNET and predefines the options accordingly)

2. In the “net2dublin” settings, “net2-net1-peer”, under Configuration, check “Use remote gateways” checkbox:


And that’s it. Really!

Testing the connection transitivity

As you may expect, the ping from “vm2net2” to “vm3net3” will start working:


And the same thing in the other way:




We have seen together the essential networking concepts and architectures to be able to implement simple or complex topologies in the Cloud, depending on our needs.

You have seen demonstrated the implementation of a relatively complex VNET-to-VNET-to-VNET topology, within the same Azure region and across regions.

With the switch to the Azure Resource Manager (ARM) deployment model in Azure, the previously existing functionalities in classic model were ported and published in the new Azure portal, but also simplified enormously. The new features like VNET Peering are equally configurable in a simple manner and are integrated seamlessly, permitting the connection transitivity via adjacent VPN gateways, or more advanced scenarios like IP forwarding for the usage of VPN appliances.

Scripting and Automation

As the ARM deployment model is based on ARM templates, you can have the complete solution implemented as ARM template which can be used in automation scenarios.

Here is for conformity a screenshot showing the resource group of the demo implementation:


For automating the deployment, you can either develop the ARM template in your preferred tooling (like Visual Studio or VS Code), or export it directly from the portal (from the resource group level).

Please note that as of today not all the resources are exportable as is from the portal; some of them are not yet available. However, you can still go to Resource Explorer ( and extract the template elements from there.


The “MS Experiences Online” corresponding video (in French, named: “Architecture et topologie Azure multi-VNet”) is available on

A “From-Zero-to-Hero” white-paper on this subject (in French also) is available on Cellenza’s blog.

A demo ARM template of this technical solution is available on GitHub:

Aucun commentaire:

Enregistrer un commentaire