Networking in Azure part 2

with No Comments


In this post I will describe more advanced networking scenarios. I expect basic knowledge in virtual networks and how to configure them. If this is a new topic for you, I recommend you read part 1 first, where I break things down into parts and explain in more detail. In this post we will focus more on the configuration and design rather than details.


full mesh

Sometimes it happens that you have several different networks. If everyone on the same network should be able to talk to each other directly, we call it full-mesh. This can be used to connect different groups sitting in various subscriptions in Azure. Or, in a scenario where you use multiple datacenters in Azure. There are many uses and it is you who must design and decide for yourself. One thing worth mentioning is that all traffic between the various vNets do not cost anything because it never leaves Microsoft's own fiber WAN.

Network configuration

We have four network that we want to connect to each other.

  • vNet1 =
  • vNet2 =
  • vNet3 =
  • vNet4 =

We start by defining our tunnels to be used. Since we have four networks, we need four <LocalNetworkSitereferences in <LocalNetworkSites>. Remember to use some random public IP, such as Google DNS as the gateway-IP. This is because we have not created our gateways yet.

Did you just complete part 1? Well then, we already have two vNets created, these can be reused but we are missing vNet3 and vNet4. Under <VirtualNetworkSiteswe define our networks. Create four of them, vNet1, 2, 3 and 4.

In <ConnectionsToLocalNetworklocated under each <VirtualNetworkSite>, we state our references from the <LocalNetworkSites>. For example, to define this for vNet1 we need references to vNet2, 3 and 4. For vNet2 we need references for vNet1, 3 and 4. Do this with vNet3 and vNet4 also.

Your configuration should be similar to this.

Import configuration to Azure.
Set-AzureVNetConfig 'c:tempnetworkconfig.xml'

Wait until the cmdlet above has finished running. Then verify that your network has been created. Since we have four networks, we need four gateways. We can choose between default which means a maximum of 10 VPN tunnels and 100 Mbit/s and high performance which means a maximum of 30 VPN tunnels and 250 Mbit/s. If you need higher speeds than this, you should instead start look at  Express Route that can deliver up to 10 Gbit/s.

Since it takes about 20 minutes for each gateway to deploy the. I'm running them as background jobs in parallel.

Start-Job -ScriptBlock {New-AzureVNetGateway -VNetName 'vNet1' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'}

Start-Job -ScriptBlock {New-AzureVNetGateway -VNetName 'vNet2' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'}

Start-Job -ScriptBlock {New-AzureVNetGateway -VNetName 'vNet3' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'}

Start-Job -ScriptBlock {New-AzureVNetGateway -VNetName 'vNet4' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'}

Edit the network configuration with the correct public IP address for each tunnel and import it into Azure again.

Get-AzureVNetGateway -VNetName 'vnet1' | select VIPAddress

Get-AzureVNetGateway -VNetName 'vnet2' | select VIPAddress

Get-AzureVNetGateway -VNetName 'vnet3' | select VIPAddress

Get-AzureVNetGateway -VNetName 'vnet4' | select VIPAddress

Set-AzureVNetConfig 'c:tempnetworkconfig.xml'


Update your VPN tunnels with the correct PSK. Keep in mind that you should not use the same key for several tunnels and that "TopSecretKey123" is not a safe key. A rule of thumb can be to use a 32-character key. Since we have twelve tunnels, we need to set this twelve times.

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet1' -LocalNetworkSiteName 'vNet2' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet1' -LocalNetworkSiteName 'vNet3' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet1' -LocalNetworkSiteName 'vNet4' -SharedKey 'TopSecretKey123'}


Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet2' -LocalNetworkSiteName 'vNet1' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet2' -LocalNetworkSiteName 'vNet3' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet2' -LocalNetworkSiteName 'vNet4' -SharedKey 'TopSecretKey123'}


Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet3' -LocalNetworkSiteName 'vNet1' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet3' -LocalNetworkSiteName 'vNet2' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet3' -LocalNetworkSiteName 'vNet4' -SharedKey 'TopSecretKey123'}


Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet4' -LocalNetworkSiteName 'vNet1' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet4' -LocalNetworkSiteName 'vNet2' -SharedKey 'TopSecretKey123'}

Start-Job -ScriptBlock {Set-AzureVNetGatewayKey -VNetName 'vNet4' -LocalNetworkSiteName 'vNet3' -SharedKey 'TopSecretKey123'}

We should now see our tunnels begin to connect. If they don't, we can use the following cmdlet to initiate a connection.

Set-AzureVNetGateway -VNetName 'vNetX' -LocalNetworkSiteName 'vNetX' -Connect


In the Azure portal, we can now see that each vNet has three VPN-tunnels.


If we check the overview of our network, we can now see that we have a network that extends between Japan, Europe and the United States.


Hub and spoke

hub and spoke

In the next configuration, I want to describe a hub and spoke configuration. I will demonstrate how we use <LocalNetworkSites> to define routes needed to be able to communicate between tunnels that do not have direct contact.

In this scenario, I imagine that we have two applications that are located both in Europe and the United States. We also have some shared services, authentication, monitoring, DNS, etc. We do not want the applications to be able to communicate with each other. But we still want it to be geographical available to access our shared services.

vNet6 have to communicate with vNet1 and vNet2.
vNet5 have to communicate with vNet1 and vNet2.
vNet4 have to communicate with vNet2 and vNet1.
vNet3 have to communicate with vNet2 and vNet1.

Network configuration

  • vNet1 =
  • vNet2 =
  • vNet3 =
  • vNet4 =
  • vNet5 =
  • vNet6 =

Start as usual and define your <LocalNetworkSites>. At least those with tunnels that will not be routed beyond one site, exactly like earlier scenarios.

vNet1 to vNet5
vNet1 to vNet6
vNet2 to vNet3
vNet2 to vNet4

The other tunnels that we will create have more than one destination. What we need to do is to define our <LocalNetworkSites> with all destinations.

Lets start with vNet1. Above we have already  vNet1 to vNet5 and vNet1 to vNet6. But we still have some sites we need to be able to reach.

vNet1 to vNet2, vNet3 and vNet4.

In order to define what we want to reach, we have to add each vNet ip-range between <AddressPrefix></AddressPrefix>. In this case, we have three networks we can connect to through a tunnel so when we need to add all three. Gateway IP is to the first tunnel. In this example vNet2.

      <LocalNetworkSite name="vNet234">









We take another, for example. vNet5 and vNet6 will use the same <LocalNetworkSitereference. Then we just need to create it once.

vNet5 to vNet1 and vNet2.
vNet6 to vNet1 and vNet2.

Now we have two networks we want to connect to, vNet1 and vNet2. We define the IP-ranges for both sites and enter the gateway-IP to the first connection.

      <LocalNetworkSite name="vNet12">







The configuration should look like this when finished.

To find and change the gateway IP and how to set the PSK do you already know how to do. I jump over those steps as it only feels like repetition otherwise. Deploy your configuration, sit back and smile in for a moment.


We have now gone through the basics in part 1 as well as two scenarios that might be more realistic in an enterprise solution in part 2. Remember that it is you who sets the limits on how you want to design your network, just as you would do on-prem.

The security of these networks will be any <-> any. In the future I will write a post about Network Security Groups. Where we can specify the protocol and port, allow or deny for subnets or individual servers. This however is another story. You should now have enough knowledge to create a proof of concept network using Azure IaaS.

If you should change your mind, you can always rebuild everything from scratch and migrate of your services. Think about it, how often do you walk into your datacenter and say: "Today we'll rewire everything!"


Do you have any questions please leave a comment below or send me a email, I reply as soon as I can. Thank you for your time!

Follow Viktor Gilbertsson:

Private cloud, public cloud, hybrid cloud, community cloud. Kind of a cloud enthusiast. IT professional.

Leave a Reply