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.
We start by entering our internal name servers.
<DnsServer name="dc01" IPAddress="10.10.0.1" />
If you want to add more DNS-servers, use the <DnsServers></DnsServers> tags 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.
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">
<DnsServerRef name="dc01" />
We also need to refer to our local network sites. We enter vNet2 because we want to connect to this network.
<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="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
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.
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'
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 220.127.116.11 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.
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'
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.