This post shows how to create a point-to-site (P2S) VPN connection to an Azure virtual network (VNet).
In my previous post, I showed how to create a virtual network configuration XML file and to create several environments (dev, stage, and prod) that are each deployed into a separate subnet. It’s kind of a goofy network architecture because typically you see VNets configured that model the tiers of a single application (front tier, middle tier, backend tier). However, it suits my use case and enables me to show how to create a point-to-site virtual network that enables me to communicate with all of the environments through a single connection.
I am showing point-to-site in this post because that’s what I use for demos while I am on the road. If you travel for work or work remotely, you likely use an agent that you run in order to connect to the corporate network. That agent establishes a secure connection to the corporate network, enabling you to access resources even from public locations. That’s exactly what a point-to-site network is, it includes an installer that will add a VPN connection. Here you can see that I have a VPN connection to Microsoft IT VPN that allows me to VPN into the Microsoft corporate network, and another VPN connection named “DevOps-demo-dev-southcentral” that enables me to connect to an Azure virtual network.
When I click Connect on that VPN connection, the agent appears.
I then click Connect, and I am securely connected to the virtual network in Azure. I can now access any resources within that virtual network as though they were part of my local network.
There are two other types of connectivity to Azure: site-to-site VPN and ExpressRoute. A site-to-site VPN allows you to create a secure connection between your on-premises site and the virtual network by using a Windows RRAS server or configuring a gateway device. ExpressRoute lets you create private connections between Azure and your on-premises or co-located infrastructure without going over the internet. For more information on choosing between a VPN and ExpressRoute, see ExpressRoute or Virtual Network VPN – What’s right for me?
Create the Network
In my previous post, Creating Dev and Test Environments with Windows PowerShell, I showed an example of an XML configuration file for an Azure virtual network. I used a simple network with three subnets. One of the elements in that XML file is an additional gateway subnet. When you create a virtual network, you can choose to configure a point-to-site VPN.
When you configure the subnets, you can then add a gateway subnet.
I’m lazy and I cheated. I created the network using this wizard, and then exported the virtual network. Who likes authoring XML documents directly, anyway?
Exporting your new network results in an XML file that looks like this:
If you have an existing network and want to add a point-to-site VPN to it, simply export the XML configuration, add the gateway subnet and the VPNClientAddressPool nodes, and then import the configuration file.
Create the Gateway
Now that you’ve created the virtual network and the gateway subnet, it’s time to create the gateway itself. In the Azure Management Portal (https://manage.windowsazure.com), go to the dashboard view of your VNet and click “Create Gateway”.
While the gateway is being created, the status will look similar to this:
This process takes some time to complete (expect around 30 minutes). In the meantime, start on the next step: creating certificates.
The communication between on-premises and Azure is secured using a self-signed root certificate. If you are reading this blog, there is a high likelihood that you are a developer with Visual Studio installed. If not, install Microsoft Visual Studio Express 2013 for Windows Desktop, which is free of charge. In Windows 8, go to the Start screen, open the charm bar, and click settings. Enable the “Show administrative tools” option.
Now go to the all apps view and look for the Visual Studio Tools folder.
In that folder you will find the Visual Studio 2013 command prompt (thankfully, this is much easier to locate in Visual Studio 2015!)
Right-click and run as Administrator.
Now that we have the command prompt open, we can create two certificates using the following commands:
Once you’ve created the certificates, upload the root certificate to the management portal.
The result shows the certificate has been uploaded.
The client certificate depends on the root certificate. We will export the client certificate and choose whether we want to use a password or a group to provide access to the certificate. Open certmgr.msc.
Navigate to Certificates – Current User / Personal / Certificates. Right-click on the client certificate that you just created and choose export.
Follow the directions to export the client certificate, including the private key. The result will be a .pfx file, you will distribute that .pfx file to each machine where the client will be installed.
Right-click on the .pfx file and choose Install. Leave the installation location as Current User, and provide the password when prompted.
Click finish, and the certificate is now installed.
Create the VPN Client Configuration Package
Go back to the Azure Management Portal. You may need to refresh the page to get the most current status. Once the gateway is created, it looks like this:
Now click on the link to download the 32-bit or 64-bit client VPN package.
When you download, the file name will be a GUID. Feel free to save as whatever file name you want.
Right-click the .EXE file and choose Properties. On the Properties page, choose Unblock.
Now double-click the .EXE to run it. You are asked if you want to install the VPN client.
Test It Out
Now that everything is wired together, the last thing to try is to actually VPN in. Connect to the VPN client.
Now that we’re connected, run a simple ping test and see that it fails.
It fails because the Windows firewall in the VM itself is blocking the communication. When we created the VM, a public endpoint for Remote Desktop connections was created. That would connect us through the cloud service name, in my case it is kirketestDEV.cloudapp.net. However, we are already connected to the network, so we don’t have to use that endpoint. Just open a new remote desktop connection and connect to the IP address of the machine, 10.0.1.4.
We connect to the VM using Remote Desktop and enable the Windows Firewall inbound rule for ICMP ping.
Now go back to the console window and try the ping test again. It works!
We were able to set up a point-to-site connection to our VNet. I frequently use this approach while demonstrating virtual networks when I am on the road traveling because I can connect to the network from anywhere, even hotel or conference wireless connections. I can now introduce the idea of a VPN connection and show exactly what to expect.
I am using my MSDN subscription for this, which gives me $150 worth of Azure credits per month. When we created the dynamic routing gateway (the process that took 30 minutes), that created a network resource that is billable. Looking at the VPN Gateway Pricing page, I can see that the cost for the dynamic routing gateway is $0.036 US per hour, which is around $27 per month.
While that still leaves me with plenty of room for other projects, I may not want or need that gateway in my MSDN subscription all month if I am just using it for a demo. Just go back to the virtual network’s dashboard and delete the gateway. Of course, the next time you need it you will have to create the gateway again and suffer the 30 minute wait, but that’s kind of a small operational price to pay for something that is so incredibly cool and convenient.