Point-to-Site VPN in Azure Virtual Networks

The capability to VPN from individual machines (Point-to-Site VPN) into Windows Azure Virtual Networks is in preview mode at the moment, but is already generating a lot of excitement. It replaces the older Azure Connect technology which also provided Point-to-Site connectivity, but which used a relay based mechanism that was slow, and which forced you to install an agent on your laptop/workstation. It is also of great interest because the Point-to-Site technology utilizes SSTP (secure socket tunneling protocol) and thus is able to work through firewalls and NAT devices.

The steps for configuring a Point-to-Site VPN are already well documented here. The official documentation should be read carefully as that is the definitive source of information. However, as well documented as it is, I like to see a walkthrough of the configuration steps with screenshots and actual addresses/values etc. as that is a very useful when one is playing with a new feature for the first time. I did not see anything relevant so decided to take screenshots of my own set up. Hopefully, folks will find it useful to see a full walkthrough.

Planning

There are three areas of planning needed before starting to configure the VNet, viz.

  • Address space for the VNet and the subnets
  • One or more DNS servers
  • Address space on the client side

Address space for VNet

I chose 10.1.0.0/16 as the overall address space for the VNet from which to carve out the subnets. A small subnet dedicated to DNS was carved as 10.1.1.0/29 which provides three usable addresses 10.1.1.4 through 10.1.1.6 – to be discussed a bit more, below. Two subnets, 10.1.2.0/24 and 10.1.3.0/24 were carved out for locating my application related VM’s. Finally, a subnet for the VPN Gateway was again carved out as 10.1.4.0/29. These are shown in the screenshot, below. Note that the subnet for Gateway gets added automatically by the Portal UI when you click on the link labeled as “add gateway subnet”.

DNS Servers for VNet

I intend to deploy several Cloud Services in the VNet, and therefore need to deploy my own DNS server for name resolution across the Cloud Service boundary. There is an interesting conundrum though – I have not even created the VM that will eventually be configured as a DNS server; and yet, the Portal UI forces me to specify the DNS Server’s IP address right away while configuring the VNet itself. Actually, to be accurate, a recent change in the behavior of VNet now does permit specifying the DNS server later on when the VNet is already fully configured and is in use. But this new feature is still not available through the Azure Portal UI; you have to add the DNS server information using Powershell. Thus, for now, I continue to use a trick that is described, next.

Specify a subnet for DNS as 10.1.1.0/29 as shown in the screenshot, above. In theory, this subnet will have 32 – 29 = 3 bits to use toward the available addresses, which amounts to 2^3 = 8 possibilities. But, 000 and 111 are always reserved (for whole subnet and broadcast), and it is my understanding that Azure further reserves 001, 010, and 011. Thus, the addresses that are really available are those corresponding to 100, 101 and 110 (i.e. 10.1.1.4, 10.1.1.5, and 10.1.1.6). Eventually, when I do create a VM and add it to this subnet, it would be quite safe to assume that this VM will get assigned the IP address 10.1.1.4. Thus, having created a subnet for DNS like this, I can specify my DNS server during the VNet configuration even though the DNS server machine does not even exist, yet.

 

Address space on the Client side

In order to set up the VPN to this VNet, you have to specify the range of IP addresses that your client machines will be located in; i.e. the address space of your laptop, workstations etc. This address space must be a private address space and must not overlap with the address space of the VNet (in the present walkthrough the 10.1.0.0/16). At home, I have a router-plus-NAT combo device which also dispenses DHCP addresses in the range 192.168.1.0/24. Thus, this is the address space I picked for VPN clients.

Configure Virtual Network

At this point we have all the information needed to configure the VNet. In the portal UI, navigate to the section where new Network items can be created and choose “Custom Create.”

 

Specify the name of the VNet and the name of an Affinity group.

On the DNS Server and VPN Connectivity page, specify the DNS IP address as 10.1.1.4 (as discussed, above) and give it some suitable name. Also, select the checkbox for Point-to-Site VPN Connectivity.

 

Next, we need to specify the client side address space on the Point-to-Site Connectivity page. Use the 192.168.1.0/24 as discussed, above.

Next, on the Virtual Network Address space page, enter the Address space as 10.1.0.0/16 and then specify the various Subnets as planned, before. Finally, click on the link for “add gateway subnet” to add the Gateway subnet as 10.1.4.0/29.

Click through to the end and save the Virtual Network.

Create VPN Gateway

Click the link for the newly create VNet and navigate to the dashboard page. It should look like the following:

At the bottom of the screen, click on the Create gateway icon to start provisioning the Gateway VM’s in the Virtual Network.

This will take some time as the gateway VM’s are provisioned and configured. Once this step completes, the Gateway IP address will be displayed on the page and VPN connectivity page will look as below.

Create and upload Certificates

Certificates are used to authenticate the VPN clients. Read more about it at this link, and this link for Management certificates, in general. Using makecert utility, generate a Root certificate as shown, below. Specify a suitable name for the Root certificate.

 

makecert -sky exchange -r -n "CN=PRMgmtRootCert" -pe -a sha1 -len 2048 -ss My "PRMgmtRootCert.cer"

 

This command will create and then install a certificate in the Certificate store on your current machine. Also, a “.cer” file (without the private key) corresponding to this certificate will be put in the current file folder from where the makecert command was run. The “.cer” certificate file needs to be uploaded to the Virtual Network. It is also recommended that you export the Root certificate along with its private key (i.e. the “.pfx” file) from the Certificate store and keep it somewhere safe so that if necessary this root certificate can be installed on some other machine.

To upload the “.cer” file for the Root certificate just generated, click on the “Upload client certificate” link shown in the screenshot above and supply the path to the certificate. Once the Root certificate has been uploaded, the icons on the VNet dashboard will change to look as below:

Using the Root certificate, generate one or more client certificates and distribute to your team members. These client certificates will be used in the authentication process during the VPN session.

 

makecert.exe -n "CN=PRMgmtClientCert1" -pe -sky exchange -m 96 -ss My -in "PRMgmtRootCert" -is my -a sha1

 

Download and install the VPN package

The Virtual Network is now fully configured. In order to initiate a VPN session, you need to download and install a VPN package on your client machine. Depending upon whether your client machine is a 32 bit machine or 64 bit, pick the appropriate download link from the page shown above. An executable file will be downloaded which will be named after your VNet (in my case it was named as “vnetprvnt.exe”). Execute this VPN package on the client machine to configure the VPN settings on the local machine. Note that this VPN package is not an agent, even though it appears as if you are installing something on your local machine. Instead, the package is just a tool to configure the built-in RRAS features of your Windows Operating System.

Once the package is run successfully, your client machine is ready to VPN into the VNet. An icon should show up in the network area of your machine, as shown below for my Windows Server 2012 machine.

Click on the icon to start the connection; you may have to pick the client certificate that is chained to the Root certificate uploaded to VNet. Then, to verify that VPN connectivity is working, go to a command prompt and run ipconfig /all.

You now have a Point-to-Site VPN to Virtual Network working.