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?
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.
Add a Security Group containing users that are allowed to VPN from non-domain-joined devices:
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.
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:
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:
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.
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 https://manage.windowsazure.com (again, if you want to know how to do this using a local account, check this post).
Check the “Configure point-to-site connectivity” check:
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 (172.16.0.0/16 in my case), and must not match or overlap your local subnet(s) (192.168.2.0/24 in my case).
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.
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 (10.0.0.0/24, 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.
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:
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.
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.
Time to run that Client VPN Package I just downloaded:
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.
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 ITWORXX.azure. Click Connect to connect:
And we’re connected. Here’s the output for IPCONFIG /ALL on the new PPP adapter:
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 ITWORXX.azure VPN Connection:
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 ITWAZ001.it-worxx.local, and its IP-address is 172.16.1.4. 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:
Let’s test reachability to ITWAZ001 using its IP-address:
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:
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 192.168.2.0/24 get routed to the internet, disappearing into that great bit-bin:
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.
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.