Building an Azure lab – Implementing P2S (Point-to-Site) VPN

In the previous post I walked you through the steps I needed to take to create a Site-to-Site VPN connection between the Azure Virtual Network and my local network.
Azure supports another type of VPN called P2S (Point-to-Site) VPN. This post is all about setting up a P2S (Point-to-Site) VPN in Azure.

So, to clearly state this post’s purpose: Create an Azure P2S (Point-to-Site) VPN to allow domain-joined and non-domain-joined (BYOD) devices to connect to the P2S VPN Endpoint in Azure. If the connection is established we need to be able to reach both Azure and on-premises resources using the IP or DNS FQDN.
This time the contents of this post are created on efforts I did with colleagues Tom Loos and Michael Verbeek.

If you’re following the “Building an Azure lab” series on this blog you’ll be used to the disclaimer by now:
I’m not claiming these are best practices, or that these are “the way to go”. I’m simply providing step-by-step guides set up by me and my colleagues on occasion to document how we did things to achieve the goals that were set. These guides get the job done, for me.

First things first.
The Azure P2S (Point-to-Site) VPN is an SSL based VPN solution, relying on Certificates to securely connect.
This guide assumes you have an Active Directory integrated Certificate Authority installed, and that you know what that means and how to use it.

Since this VPN is an SSL based VPN solution we’ll need several certificates to make this work.
We need the root certificate that identifies the CA that is issuing your client VPN certificates. You need to export this certificate to a DER Encoded .cer file and keep it at hand for later in this guide.
Whatever you do, export the certificate only. Never ever ever ever ever ever (even if you can) never ever export the private key along with this certificate. Did I mention not to export the private key of your CA along with a certificate you are going to use for something else than using it on your CA?
00-7 Azure Freaks - P2S
You can export this certificate on the CA itself.

The second certificate we need is a certificate to identify the user that is going to make the VPN connection. The user needs to present his or her certificate to the VPN endpoint during the handshake.
The Windows Active Directory integrated Certificate Authority by default offers a user certificate template, but this one is not suitable for what we need. The default can be used for File Encryption (which we don’t need), for email signing (which we don’t need). The default has limited validity (which I don’t want), and most importantly, you cannot export the private key once you’ve obtained such a certificate.
So for domain-joined devices we can of course use the default User certificate to connect to the VPN Endpoint. But for non-domain-joined devices we need to be able to provide a certificate and a private key to the user.

We are going to need a new User Certificate template that fits our needs for BYOD perfectly.

Open the Certificate Templates mmc, which is on your CA by default.
Find the User template and duplicate that template. This is the base for our new Certificate Template.

On the General tab for the Certificate Template I choose to name it “User BYOD”, and set the validity to 10 years:
00-1 Azure Freaks - P2S

On the Request Handling tab make sure the “Allow private key to be exported” check is checked:
00-2 Azure Freaks - P2S

On the Extensions tab, select Appication Policies and click Edit. Select the Encrypting File System and Secure Email Application policies:
00-3 Azure Freaks - P2S
Then click Remove, and click OK.

Go to the Security tab and remove the Domain Users group here:
00-4 Azure Freaks - P2S

Add a Security Group containing users that are allowed to VPN from non-domain-joined devices:
00-5 Azure Freaks - P2S
Remove the Read right and add the Enroll right for this group.
Of course you can leave the Domain Users group here, depending on your company’s policies here. My company will not allow everyone to VPN into the company’s network using non-domain-joined devices, hence the limitation to this particular Security Group.

With this template now completed, go to the Certificate Authority mmc and select the new template as a New Certificate Template to issue:
00-6 Azure Freaks - P2S

I used to following technique to obtain a .pfx file containing the User BYOD certificate including the corresponding private key for the user Arjan Mensch.

Log on to a domain-joined machine with said user and open an mmc. Add the Certificate (User) snap-in:
12 Azure Freaks - P2S
As you can see I already have the default user certificate (using Active Directory auto-enrollment policy).

To obtain the User BYOD certificate (the user is a member of that Security Group I configured on the Certificate Template), right click the Certificates node, point to All Tasks, and select Request New Certificate:
13 Azure Freaks - P2S

Since I’m using Active Directory integrated Certificates Services I can choose the User BYOD certificate template in the wizard:
14 Azure Freaks - P2S

After the certificate is issued to me I right click the certificate, point to All Tasks, and select Export:
16 Azure Freaks - P2S

Choose to export the private key:
17 Azure Freaks - P2S

For now select to Include all certificates in the certification path. The reason we need to do this is that the device on which you will import the User BYOD certificate itself needs to trust the certificate you’re importing for the SSL VPN to work. That’s a security measure. We wouldn’t want to set up a trusted connection using a certificate that is not trusted by the device that you are using to setup the connection in the first place. I’m saying “for now” because I think I have found a more elegant way to do this, but I will explain a lot more about customizing the VPN connection in the next post.
18 Azure Freaks - P2S

Save the .pfx file somewhere you can find it again later. We’ll need it when we configure the client.

Pre-requisites completed, let’s start configuring the Azure magic.
Log on to (again, if you want to know how to do this using a local account, check this post).

Select the Networks menu option, and click the Virtual Network name:
01 Azure Freaks - P2S

Click the Configure tab:
02 Azure Freaks - P2S

Check the “Configure point-to-site connectivity” check:
03 Azure Freaks - P2S
An Address Space will be suggested. These are the addresses that will be assigned to clients that connect using the P2S (Point-to-Site) VPN connection that we are about to build. Whatever address range you choose, note that it must be outside the range you used for the Azure Virtual Network ( in my case), and must not match or overlap your local subnet(s) ( in my case).

When you’re satisfied with your choices, click the Save button on the bottom of the Azure Portal screen:
04 Azure Freaks - P2S

Nice to know if you’re doing this in a production environment:
05 Azure Freaks - P2S

When the Azure Portal is done doing its magic, this is what the network looks like:
06 Azure Freaks - P2S

Notice the exclamation in the newly created P2S VPN adapter: A root certificate has not been uploaded. Also notice that this VPN adapter is apparently part of the Gateway subnet we added when configuring the S2S (Site-to-Site) VPN in the previous post.

To deal with that pesky exclamation click the Certificates tab, then click Upload a Root Certificate:
07 Azure Freaks - P2S

A popup pops up in which you can click the Browse button. Browse to the exported Root CA .cer file you created in the pre-requisite part of this post. Click the Ok button afterwards:
08 Azure Freaks - P2S

The interface will report the upload as succeeded:
09 Azure Freaks - P2S
And that concludes the configuration on the Azure side of things.

If you’ve followed or read the post about the S2S VPN connection, you’ve noticed my setup and the changes I needed to make to be able to connect to Azure and visa versa.
We need to make the same changes to enable IP traffic from the P2S VPN clients to the on-premises network and back again.

For this I added a route on my default gateway (DD-WRT) to the VPN Client subnet (, remember?) using the IP address of my RRAS server as the default gateway for that route. For more info on why and what, see that post about S2S VPN I mentioned a couple of times already.
34 Azure Freaks - P2S

Now that my default gateway knows to route all traffic meant for the VPN Clients to my RRAS server, we need to tell the RRAS server what to do with it.
For that we add a static route on the Azure Gateway interface for the VPN Clients subnet:
35 Azure Freaks - P2S

And that’s it. That’s really all we need to do to ensure connectivity between connected Azure P2S VPN Clients, whether they need to access resources in the Azure Virtual Network address spaces, or on the on-premises subnets.

So what about the client?
Can it simply connect? If so, what’s the address we need to connect to? What are the connection’s properties? Where’s the list of settings we need to apply to this VPN connection?

Luckily, Microsoft’s got that covered by providing VPN Client software, tailored to fit just your configuration.

Still on the Azure Virtual Network menu item, click the Dashboard tab:
10 Azure Freaks - P2S
And there they are. The 32-bit and 64-bit Client VPN Packages.

I chuckled when I downloaded them:
11 Azure Freaks - P2S
Really, Smartscreen. Really?

Before we actually run it though, let’s check the client device I will be using.
I will be using a non-domain-joined laptop. Because it’s on my on-premises network as I type it, I need to configure it to have an IP-address not in my network’s range, but still have internet access.
The easiest way to do this is to switch on my phone’s internet access using 4G and to share that connection. This sets up a Wireless Access Point on the phone, to which I connect the laptop’s wireless adapter.

This is the output for IPCONFIG /ALL on the Wifi adapter:
19 Azure Freaks - P2S

And this is the default routing table on the laptop when connected to the Wireless Access Point I just created:
20 Azure Freaks - P2S

Time to run that Client VPN Package I just downloaded:
21 Azure Freaks - P2S
Again a warning from Smartscreen. I couldn’t be bothered by finding out why Smartscreen does this, or how to disable it for downloads from the Azure Portal. I’ll look into it some other time. Maybe. If you check out the next post (when I post it), you’ll understand why I can’t be bothered now.

The only feedback the installer gives to you when you run it:
22 Azure Freaks - P2S

And the results of the installer can be found in the Network Connections section:
23 Azure Freaks - P2S

Before you connect to this adapter, if you’re on a non-domain-joined machine like me, import the .pfx file for the user, the one you created in the pre-requisites part of this post.

If you connect to this adapter (you can also find it by clicking on the Wireless or Wired network icon on the taskbar if you have it visible) a notification pops up. Notice this is tailored to my configuration since it’s called Click Connect to connect:
24 Azure Freaks - P2S

Another notification. This one is telling us a change in the routing table is needed:
25 Azure Freaks - P2S
I won’t disable this notification for now, so don’t check it.

If you forgot to import the user .pfx file, the connection will tell you just that:
26 Azure Freaks - P2S

And we’re connected. Here’s the output for IPCONFIG /ALL on the new PPP adapter:
27 Azure Freaks - P2S
Notice that the connection installer configured the PPP adapter to use my on-premises DNS server. The one we registered on the Azure Virtual Network configuration in the previous post.

Let’s have a look at the routing table after we installed and connected the VPN Connection:
28 Azure Freaks - P2S
Note several routes were added to establish connection.
A route to establish connection for any addresses in the VPN Client range (VPN Client to VPN Client).
A route to all subnets in the Azure Virtual Network.
And broadcast routes.

I’ve created a VM in the Azure Virtual Network, specifically in the subnet I defined for stretching the it-worxx.local Active Directory domain. The server is named ITWAZ001, is a member of the domain it-worxx.local so its FQDN is, and its IP-address is For the remainder of the tests to come I have ensured ICMP replies are possible (ping responses). So in these tests, ping-tests are reliable tests for reachability. I’ve also checked that the Domain Membership for ITWAZ001 registered successfully, resulting in a DNS record in it-worxx.local:
31 Azure Freaks - P2S

Let’s test reachability to ITWAZ001 using its IP-address:
30 Azure Freaks - P2S
Success! So the P2S VPN configuration and default client installation package ensure we can reach resources in the Azure Virtual Network address spaces.

Now for reachability using the FQDN:
32 Azure Freaks - P2S
Oh noes. As you can see I cannot reach the server using the FQDN because the name cannot be resolved because the only DNS server I registered is on-premises and unreachable using the IP address.

So what’s happening?
Well, if you take a look at the routing table I showed earlier the VPN Client does not get a route for the on-premises network. Because the default route in the routing table is to the default gateway on the Wifi adapter and not on the VPN PPP adapter, the packets for get routed to the internet, disappearing into that great bit-bin:
vpn no-route

We can fix this using two different methods.

We could set the default route to the VPN PPP adapter. But would this be wise? That would mean that all traffic is routed through Azure, and back again to the client. All traffic. Including Internet browsing amongst other things. In Azure you pay for traffic going out of the Azure environment. Depending on applications and Internet usage, and of course number of users this could be a pricy fix.
Let’s implement a fix that’s easy to do and keeps thing working as intended. Add a route to the on-premises network on the VPN PPP adapter so all traffic for the on-premises network will be routed through Azure.

In my case that would be the command shown here:
33 Azure Freaks - P2S
And as you can see, this fix is instantaneous. Resources can be reached using the IP-address or the FQDN of the on-premises server.

So adding that route fixes the communications to the on-premises network.
The question remains what caused this? Is this because the Site-to-Site VPN we created in this post didn’t really meet the requirements? Is this because I choose the address spaces I’m using in the Azure Virtual network poorly?
Whatever the reason, in my situation this can only be fixed by adding that route on each client after connecting the Azure P2S VPN Connection.
Can this be automated?
Are there other solutions to get this done?

Spoiler-alert: Yes, this can be solved.

More on this in the next post, which will be about customizing the Azure P2S VPN Client packages.

For now, mission accomplished. The goal for this step in the Azure Lab saga is accomplished. We can now connect to the IT-WorXX network using the Azure P2S VPN Connection and access resources in both the Azure Virtual Network, and the on-premises IT-WorXX environment.

Thank you Tom Loos and Michael Verbeek for your additions to this post.


20+ years experience in Microsoft powered environments. Enjoy automating stuff using scripts, powershell, and even batch files. In my free time (hah! as if there is any) I hunt achievements and gamerscore on anything Xbox Live enabled (Windows Mobile, Windows 8, Windows 10, Xbox 360 and Xbox One). When I'm not doing that I enjoy traveling or riding my Yamaha R1 on the edge ;)

Tagged with: , , , ,
Posted in Azure, Networking, RRAS, Step-by-Step guide, Virtual Networking, Windows 2012 R2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog Authors
Donate Button

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 322 other followers

Blog Stats
  • 1,913,769 hits
%d bloggers like this: