Networking in Azure part 1

with No Comments


Moving to the cloud is not as simple as people think. One of those most fundamental thing is to have a functional network to run your services in. We can all click “next, next, finish” in the Azure portal. But the question you should ask yourself is. What opportunities do we have and what is hidden in the darkness?

Network and security in Azure IaaS is a class apart. No wonder you get a headache before you learned this. By virtualizing the network, we open the doors to a lot of exciting things.

We could easily lift our current IP-range to Azure, or create a new one just to test how it works? Without limitations on our network, we are very free to do as we feel like. With the help of class A/B/C networks. We can create what we want in terms of size without having to bother about the neighbors in the same rack.

I will describe 3 scenarios using vNets Azure. Obviously, it works just as well to have a hybrid solution by using VPN-tunnels that are on-prem. Before using network hardware on-prem I would recommend anyone trying on this to read the Microsoft documentation on supported hardware. The person who performs the configuration on-prem should also have knowledge in policy and route-based VPN configurations. Windows Server 2012 R2 can also be used as "hardware" on-prem to connect with VPN to Microsoft Azure.

Do you already have a basic knowledge of networking Azure IaaS? Jump straight to part 2 for more advanced configurations.

Singel VPN tunnel


By creating two networks vNet1 and vNet2 we can link these together using a VPN-tunnel.
Download a template configuration here.

Network Configuration


We start by entering our internal name servers.



          <DnsServer name="dc01" IPAddress="" />



If you want to add more DNS-servers, use the <DnsServers></DnsServerstags again. We can refer to these later in the configuration.

Local Network Sites

Not quite what it sounds like. What we want to define here are our opposite sides of our vNets. Since we have vNet1 we must create vNet2 the opposite side, and vice versa.

We write googles DNS instead of a real gateway IP (or whatever you feel like). This is because we do not have any gateways yet.


      <LocalNetworkSite name="vNet1">






      <LocalNetworkSite name="vNet2">







The easiest way to think of this is that we define our routes. Keep this in mind, nothing you need to focus on right now. It becomes more relevant later when we build a more advanced network.

Virtual Network Sites

Here we define the networks that we want to create in Azure, we also specify the name of our name server and which VPN-tunnels we want to connect.

Start by defining the name, location, IP range and subnet which we want in our VNET. A Gateway subnet must be created so we have somewhere to place our gateway.

      <VirtualNetworkSite name="vNet1" Location="North Europe">





          <Subnet name="Subnet-01">



          <Subnet name="Subnet-02">



          <Subnet name="GatewaySubnet">





          <DnsServerRef name="dc01" />


We also need to refer to our local network sites. We enter vNet2 because we want to connect to this network.



            <LocalNetworkSiteRef name="vNet2">

              <Connection type="IPsec" />





Make a copy of everything between the <VirtualNetworkSite> </ VirtualNetworkSite> tag included and define your second network vNet2. Remember that the reference for the Local Network sites will be vNet1.


Everything that we have created will be located between the following tags.

<?xml version="1.0" encoding="utf-8"?>

<NetworkConfiguration xmlns:xsd="" xmlns:xsi="" xmlns="">





Now that's more like a full-fledged configuration to deploy. Please compare your configuration with this.

Deployment of the networkconfiguration

To create our network, we have to import our configuration to Azure. To do this, we use modules specific to Azure. If you have not installed them earlier, you can download here.

Open up a PowerShell-console and verify that you are using the correct subscription. Then run the following cmdlet, and wait a few minutes.
Set-AzureVNetConfig 'c:tempnetworkconfig.xml'

If we open the Azure portal and look at our networks we can see that vNet1 and vNet2 exist.

Create Dynamic Gateway

As it is, networks can be used independently. But we want to use the vNet to vNet VPN. To do this, we need to create a gateway for each network. The following cmdlet will take care of it. Please note that we are defining Dynamic Routing as the Gateway Type. Without this it will not work.
New-AzureVNetGateway -VNetName 'vNet1' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'
New-AzureVNetGateway -VNetName 'vNet2' -GatewayType 'DynamicRouting' -GatewaySKU 'Default'

It takes about 30 minutes until our gateways are created. When it is finished it will look like below in the portal.

Final touch and connection of VPN-tunnels

As you can see above, the VPN tunnel is created but not connected. It depends on two things. The first thing we must do is to find out the public IP address and update our network configuration.

To find out the public IP address we make the following cmdlet.
Get-AzureVNetGateway -VNetName 'vnet1' | select VIPAddress
Get-AzureVNetGateway -VNetName 'vnet2' | select VIPAddress

Then edit the network configuration where we replace in <LocalNetworkSites> with the correct IP address for both of our sites.

Save the configuration when both sites are updated with the correct IP. Since we update our configuration, we must now import it to the Azure again.
Set-AzureVNetConfig 'c:tempnetworkconfig.xml'

The second thing we must do is to update both our VPN tunnels with the same pre-shared key.
Set-AzureVNetGatewayKey -VNetName 'vNet1' -LocalNetworkSiteName 'vNet2' -SharedKey 'TopSecretKey123'
Set-AzureVNetGatewayKey -VNetName 'vNet2' -LocalNetworkSiteName 'vNet1' -SharedKey 'TopSecretKey123'

All configuration should now be complete. To initiate a connection, we can run the following cmdlet.
Set-AzureVNetGateway -VNetName 'vNet1' -LocalNetworkSiteName 'vNet2' -Connect

Give it a few minutes and then run the following to check if the tunnel is up.
Get-AzureVNetConnection -VNetName 'vNet1'

You can also check the Azure portal under each network to confirm that our tunnel is up and running.

We have now created a vNet to vNet VPN. In part 2, I will describe how we take this to the next level with full mesh and hub and spoke configurations.

Follow Viktor Gilbertsson:

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

Leave a Reply