Configure a Point-to-Site VPN Connection to an Azure VNet

發行項
06/05/2015

This post shows how to create a point-to-site (P2S) VPN connection to an Azure virtual network (VNet).

Background

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:

NetworkConfig.xml

<NetworkConfiguration xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="https://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<Dns />
<VirtualNetworkSites>
<VirtualNetworkSite name="kirketestvnet-southcentral" Location="South Central US">
<AddressSpace>
<AddressPrefix>10.0.1.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
<AddressPrefix>10.0.1.0/27</AddressPrefix>
</Subnet>
<Subnet name="Subnet-2">
<AddressPrefix>10.0.1.32/27</AddressPrefix>
</Subnet>
<Subnet name="Subnet-3">
<AddressPrefix>10.0.1.64/26</AddressPrefix>
</Subnet>
<Subnet name="GatewaySubnet">
<AddressPrefix>10.0.1.128/29</AddressPrefix>
</Subnet>
</Subnets>
<Gateway>
<VPNClientAddressPool>
<AddressPrefix>10.0.0.0/24</AddressPrefix>
</VPNClientAddressPool>
<ConnectionsToLocalNetwork />
</Gateway>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>

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.

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:

Create Certificates

makecert -sky exchange -r -n "CN=DevOpsDemoRootCert" -pe -a sha1 -len 2048 -ss My "DevOpsDemoRootCert.cer"
makecert.exe -n "CN=DevOpsDemoClientCert" -pe -sky exchange -m 96 -ss My -in "DevOpsDemoRootCert" -is my -a sha1

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.

Clean Up

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.

For More Information

ExpressRoute or Virtual Network VPN - What's right for me?

Configure a Virtual Network with a Site-to-Site VPN Connection

Configure a Point-to-Site VPN connection to an Azure Virtual Network.

VPN Gateway Pricing

Comments

Anonymous
June 22, 2015
Thanks for the article. I have 2 issues with it.

VS2013 is incredibly heavy - big to download and install
should a laptop be stolen and I want to prevent it accessing my vpn how do we revoke the certificate? Should we look at generating a ADCS to generate and publish certificates?

Anonymous
June 22, 2015
@Steve - it only supports self-signed root certificates currently. Visual Studio is not required, there are other ways to generate a self-signed root cert. Revoking the cert would revoke for all VPN users (which shouldn't be very many).
Anonymous
June 23, 2015
Hi Kirk, I have configured multiple site-to-site connections to connect VNets in different regions / subscriptions together. Is it possible to configure a point-to-site connection to "see" machines in other VNets as I am unable to connect to any of them? If I remote into a VM on the same VNet as the point-to-site connection, I can then connect to VM's on other VNets without any issue, but it would be better if there was a way to directly connect to them without the need to do RDP inside an RDP session :)
Anonymous
June 23, 2015
@John - not currently, but please submit suggestions on UserVoice. feedback.azure.com/.../34192--general-feedback Point to site (and site to site) is to a specific VNet. As you've indicated, to span VNets you need to set up additional site-to-site VNets and RDP across them.
Anonymous
June 30, 2015
Kirk, What is the next step after you click connect on your Client? For example, when I'm using a Windows-To-Go stick with Windows 8.1 and have run through the setup steps you outlined. And when I hit 'Connect' on the client, the Azure mgmt. portal shows a client is connected. But I don't seem to be able to access network resources. Thoughts? Thanks, Tony
Anonymous
July 01, 2015
Make sure the Windows Firewall in your VM is not blocking access. For instance, if you are trying to ping a VM, the VM must have the ICMP echo rule enabled.
Anonymous
December 31, 2015
Thanks for the article. One thing I noticed was the statement:"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. ..."But I didn't see anywhere when the VPN client is used where you can require the use of the certificate and a password or group? Did I miss something or where you just mean the password created when the certificate is exported?Thanks!

共用方式為