Unless you’re starting up a company from scratch, you probably won’t host all of your workloads in a public cloud like Microsoft Azure. If you’re building a hybrid cloud, you probably want to have network connectivity between the two clouds and that means a VPN. Microsoft Azure uses a Virtual Network Gateway to provide this connectivity.
NOTE: As of the writing of this blog post, Microsoft has two portals that can be used to provide cloud resources. The Classic portal and the Azure Resource Manager portal. This post focuses on setting up a VPN tunnel using the new Azure Resource Manager portal.
To begin setting up a VPN tunnel, we first need to deploy a virtual network gateway in our Azure VNet. To do this, go to the Azure portal and browse for the “Virtual Network Gateways” tab. Click Add to deploy a new one.
Give the gateway a name, and select the VNet that it will belong in. Give the gateway a subnet address range. To give some background, virtual network gateways are deployed in a new subnet so you’ll need to deploy a new subnet when you deploy your virtual network gateway. Add a new public IP address or select an existing one. This IP address will serve as the public cloud’s VPN endpoint. Select “VPN” for the gateway type and then in the VPN type select “Policy-based”. As with any Azure service you’ll need to select the subscription for proper billing services. Select a resource group and location.
Wait! It may take up to twenty minutes to deploy the virtual network gateway, so be patient. When your virtual network gateway is deployed open up your gateway menu and click “Connections”. Add a new connection to add your VPN information. Here you’ll need to name the VPN tunnel and choose what type of connection. Since this is going to connect to a Cisco ASA Firewall in my lab, I’m choosing Site-to-Site (IPSec). Select the network gateway if not already selected, and add a new local network gateway.
The local network gateway is not an Azure object to be deployed. It is a reference to your on-premises VPN endpoint. In my case this is the public IP address of the firewall in my lab. I’ve blurred out the IP Address for obvious reasons. After adding the public IP Address, add the local IP space in your on-premises network. This is the internal network that will be accessible over the tunnel.
Once done, go back to your Connection menu and finish adding a PreShared Key for authentication purposes, the subscription to use and a resource group.
On-Premises VPN Setup
You’re mileage will very here, but this is my setup through a Cisco ASA 5505 Firewall. Also, I’m using the wizard (Don’t judge me). I started the VPN wizard and the first question asks where the Peer IP Address is. This is the public IP Address of the virtual gateway we deployed earlier. If you don’t remember what that is, check the properties of your virtual network gateway in the Azure portal.
Next, I’m asked which local and remote network should be part of the IPsec encryption. On my lab side, I want the 10.10.50.0/24 network, and in the Azure network I need to add my VNet information of 172.30.0.0/16.
Now we’re asked how to setup authentication. We select the simple configuration and then enter the same pre-shared key that we entered in the Azure setup screen. They must match exactly, including the case. It’s a password, they must match.
Next, I’m exempting any network address translation on my internal networks destined for the Azure VNet. Then review the summary and finish the wizard.
After the VPN is configured, I can check the IPSec sessions in my ASA and see that I’ve got a successful connection.
In Microsoft Azure, I can look at the VPN and will see that I have a “Connected” state along with data in and out. I can deploy a virtual machine in azure now and connect to it through the VPN tunnel in my home lab.
When connecting to my Linux VM in my Azure VNet, I’m able to ping my lab network over the VPN even though I can’t ping any public IP Address.
A couple of notes if you had issues.
- If you have a successful tunnel created, but can’t connect to the machine, check to see if you have a security group on the subnets. Remember that they act as a firewall on your networks and may not allow SSH for example.
- Make sure you waited long enough for the Virtual Network Gateway to be deployed in Azure. It takes a little while to deploy.
- Make sure your pre-shared key matches, local and remote networks match on both sides and public IP Addresses are correct.