Configuring an Azure Point-to-Site VPN using Microsoft Enterprise CA certificates for authentication for remote users to establish a secure tunnel into Azure

I’ve recently been asked by several clients about how they would go about setting up a P2S (Point-to-Site) VPN for their remote workers to VPN into Azure so I thought I’d write a short blog post demonstrating the process.

Before I begin, the following are the Microsoft documentation for configuring a Point-to-Site VPN that should be reviewed as it provides an explanation of how it works and the respective configuration parameters available during the deployment.

Configure a Point-to-Site VPN connection to a VNet using native Azure certificate authentication: Azure portal
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal

About Point-to-Site VPN
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about

Configure a Point-to-Site VPN connection to a VNet using native Azure certificate authentication: Azure portal
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal

Create and install VPN client configuration files for native Azure certificate authentication P2S configurations
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-configuration-azure-cert

Configure a Point-to-Site VPN connection to a VNet using native Azure certificate authentication: Azure portal
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal

Step #1 - Configure Azure Point-to-Site VPN

Assuming that a Site-to-Site VPN between Azure and an on-premise datacenter or office is already configured, begin by logging into Azure and selecting the Virtual network gateways option to list the gateways configured:

Select the existing Site-to-Site VPN gateway that is already configured and then click on Point-to-site configuration:

The following options for the P2S VPN is displayed:

The Address pool is where you define the IP subnet that the VPN client will be in. Specify a subnet that does not overlap any existing address space specified in a Virtual Network.

The Tunnel type is where you select the type of VPN you want to provide to the users. I won’t go into the details of the differences between all of them and will simply reference the following Microsoft TechNet article: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal#tunneltype

For the purpose of demonstrating how to use Microsoft Enterprise CA certificates for authentication and using a Windows 10 operating system to connect natively with the OS built client, we’ll be configuring the following:

Tunnel type: IKEv2 and SSTP (SSL)
Authentication type: Azure certificate

Root Certificates:

We’ll need to obtain the Microsoft Enterprise CA root certificate’s Public certificate data by performing the following:

Either log onto the certificate authority, launch the Local Computer Certificate Store (certlm.msc), navigate to the Personal > Certificates folder to locate the Root CA Certificate Authority’s certificate (this is used to sign certificates this CA issues):

Or from any domain joined computer, launch the Local Computer Certificate Store (certlm.msc), navigate to the Trusted Root Certification Authorities > Certificates folder to locate the Root CA Certificate Authority’s certificate:

Open the properties of the certificate, click on the Details tab, click on Copy to File to copy the certificate without the private key to a file in Base-64 encoded X.509 format:

Open the file in Notepad, copy the content between:

-----BEGIN CERTIFICATE-----

… and:

-----END CERTIFICATE-----

… then paste it into the Public certificate data field:

Save the configuration and proceed to download the VPN client by clicking on Download VPN client:

A zip file containing the following folders will be downloaded:

We’ll come back to installing the client once we have issued the client certificate.

Update December 15, 2020 – Configuring OpenVPN SSL

I received a few questions after publishing this post that using the IKEv2 and SSTP (SSL) and native Windows 10 VPN client isn’t usually a viable option due to the local administrator right issue, which while has workarounds available, isn’t a great solution overall. For those who want to implement a solution that has a free VPN client can opt for using tunnel type OpenVPN SSL paired with the Azure VPN Client. OpenVPN SSL can be configured to either authenticate the user via the Azure Active Directory or with certificates:

Create an Azure Active Directory tenant for P2S OpenVPN protocol connections
https://docs.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-tenant

The Azure VPN Client can be downloaded via the following URL:

https://www.microsoft.com/en-ca/p/azure-vpn-client/9np355qt2sqb?activetab=pivot:overviewtab#

The following is a sample OpenVPN (SSL) configuration using certificate for authentication:

Once complete, click on the Download VPN client to download a package with the azurevpnconfig.xml configuration file then import it into the Azure VPN client:

Select the appropriate Certificate Information, change the Connection Name if required and leave all the other settings as the default:

Note how the message Client Certificate Hash cannot be empty is displayed if a certificate is not selected:

Save the changes and proceed to connect:

Note that the client has successfully connected along with the appropriate routes injected without the user requiring local administrator rights:

 

Step #2 – Generate Client Certifcates for Authentication

The Microsoft document doesn’t provide much information for using an Enterprise CA other than the following:

Generate client certificates
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal#generateclientcert

You can generate client certificates by using the following methods:

· Enterprise certificate:

o If you're using an enterprise certificate solution, generate a client certificate with the common name value format name@yourdomain.com. Use this format instead of the domain name\username format.

o Make sure the client certificate is based on a user certificate template that has Client Authentication listed as the first item in the user list. Check the certificate by double-clicking it and viewing Enhanced Key Usage in the Details tab.

The information isn’t very clear on what certificate template to use other than that the common name value format must be the UPN rather than domain name\username. The good news is that the default User certificate template that a Microsoft Enterprise CA has can be used. While logged in as the user, launch the Certificates Console under the Current User context with:

Certmgr.msc

Proceed to request a new certificate under the Personal > Certificates store:

Select Active Directory Enrollment Policy:

Select the User template:

As the User template does not require information to be supplied because it requests the template with the logged in user’s identity, a certificate will be issued:

Step #3 – Install and Configure Windows VPN Client

With the appropriate certificate requested, we can now install and configure the VPN client by navigating into the appropriate folder based on the operating system. For this example, the OS is Windows 10 so the VPNClientSetupAmd64.exe executable in the folder WindowsAmd64 will be ran:

***Note that the installation doesn’t really present anything on the screen as it just flashes for a bit (I hope this will change in the future).

With the VPN installation completed, proceed to launch the VPN settings:

Note that there will be a new VPN connection configured (in this case it is vnet-prod-eastus):

The following are the advanced settings of the VPN connection. Note that the Type of sign-in info is specified as Certificate:

The following are the settings that can be edited:

Proceeding to connect to Azure will display the following message:

Note that one of the most complained about topic for the Azure Point-to-Site VPN is that it requires the user connecting to Azure be an administrator because routes need to be injected into the routing table by using the CMROUTE.DLL file to copy them into a routes.txt file and this operation requires elevated permissions:

The problem with this approach is that it is executed under the context of the current user, and a standard user does not have the permissions to make changes to routes. There are plenty of workarounds available on the internet for this so I will not include them here.

More information can be found here:

What are the client configuration requirements?
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about#what-are-the-client-configuration-requirements

The connection will proceed once the routes have been copied:

Notice that the VPN connect is now labeled as Connected:

An IP address will also be assigned under the PPP adapter:

Reviewing the Allocated IP Addresses will display the IP address assigned to the VPN client:

Note that if the following message is displayed in the Connection Status when attempting to connect then it is because a valid certificate for authentication is not available:

A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798)

Also, there are cases when administrators would like to generate the certificate for the user under their own login and if this is desired, simply duplicate the User certificate template and modify the properties of it from:

Planning and setting up a Site-to-Site VPN connection between an on-premise network and Azure

One of the tasks most administrators will have to perform when adopting Microsoft’s Azure as their cloud platform is setting up a site-to-site VPN connection between their on-premise infrastructure to an Azure region where they will host their IaaS, PaaS or SaaS services. There are plenty of blog posts, YouTube videos and Microsoft documentation demonstrating the configuration but I find that most of the environments I come across tend to show that not a thought has been put into something as simple as, yet I feel is very important, naming conventions. With that in mind, this post serves to place a bit more emphasis on preparing the resources that will be required to set up the VPN connection prior to proceeding with the configuration.

The following is a diagram of what the topology would look like along with the resources we will be creating:

 

Azure Resource Preparation

It is possible to create the Azure resources required for a site-to-site VPN connection during the configuration but making decision on the fly is prone to mistakes that you may make so it is always best to plan and design the resources before commencing with the configuration.

As a start, if this has not been done, spend some time to determine how resources should be named. Maintaining a standard naming convention will save you a lot of grief in the future and make it much easier to identify resources and/or sort them into lists for exercises such as billing. Microsoft has an official document that provides recommendations for naming and tagging here:

Recommended naming and tagging conventions
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging

**Note that I don’t proclaim that my naming conventions are the best but I hope a demonstration would provide an example for such an exercise.

 

Resource Groups
Every resource in Azure needs to be placed into a resource group so the first step is to determine where the resources that will be required for the site-to-site VPN will be created. It is possible to move a resource to another resource group or even another subscription but putting a bit of thought in how you would like to organize your resources and maintaining a standard will ensure tidiness. For the purpose of this example, all of the resources created for the site-to-site VPN will be placed into a single resource group containing networking items as the environment isn’t very large. It is possible to break up the components into dedicated groups (e.g. Public IPs, Virtual Network Gateways, Virtual Networks).

Resource group: rg-prod-network

 

Subnets
Subnets are networks you define in Virtual Networks (VNet) and it is not something you create before the creation of the Virtual Network but it is best to pre-plan the name and subnet prior to the configuration.

Subnet

Parameter	Configuration
Name	snet-prod-svr-10.248.1.0-24
Address range (CIDR block)	10.248.1.0/24

The naming convention chosen is to use the snet- prefix followed by the environment (in this case production) and then the Azure region (East US).

Gateway Subnet
The gateway subnet contains the IP addresses that the virtual network gateway virtual machines and services use. When you create your virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings. This subnet is reserved solely for the virtual network gateway so do not deploy anything else into it. The subnet size can be as small as /29 but it is recommended to be /27 or larger as this would accommodate most configurations and not limit additional virtual network gateway connections in the future.

Gateway Subnet

Parameter	Configuration
Name	GatewaySubnet
Address range (CIDR block)	10.248.255.0/27

The Gateway Subnet is specific to the VNet and you are not allowed to provide a custom name so the default will be used.

 

Virtual Networks
The Azure Virtual Network (also known as VNet) is a fundamental building block for the network in Azure. These objects define the IP scheme of the resources located within it and interacts with other VNets and/or networks through a Virtual network Gateway. Note that moving a virtual machine between VNets isn’t very straight forward and trying to redesign VNets after a deployment can be a laborious task so spend some time to think out the naming convention and IP addressing before creating and using them. For the purpose of this example, we’ll have one VNet that contains all of the production servers.

Virtual network

Parameter	Configuration
Name	vnet-prod-eastus
Location	East US
Address Space	10.248.0.0/16
Subnets	Hosts Subnet: 10.248.1.0/24 (247 addresses) GatewaySubnet: 10.248.255.0/27 (26 IP addresses)
DNS servers	Domain Controllers

The naming convention chosen is to use the vnet- prefix followed by the environment (in this case production) and then the Azure region (East US).

 

Public IP Address
Public IP addresses are fairly self-explanatory as these objects represent the public IP addresses available that can be assigned to resources such as a virtual machine, Virtual Network Gateway or application. The public IP address we’ll need for the site-to-site VPN is a public IP for the VPN Gateway.

Public IP Address:

Parameter	Configuration
Name	pip-vgw-EastUS
SKU	Basic
IP address assignment	Dynamic

The naming convention chosen is to use the pip- prefix followed by the Virtual Network Gateway prefix vgw- and then the Azure region (East US).

 

Virtual Network Gateway
The Virtual Network Gateway is the device that establishes the connection to the VPN device at your on-premise datacenter or office. Note that a single Virtual Network Gateway can establish multiple site-to-site VPN connections so it is not advisable to name it to include where it is connecting to.

Virtual Network Gateway

Parameter	Configuration
Name	vgw-EastUS
VPN type	Route-based
SKU	VpnGw1
Gateway type	VPN

The naming convention chosen is to use the vgw- prefix followed by the Azure region (East US).

 

Local Network Gateway
The Local Network Gateway represents the device at your on-premise datacenter or office that establishes the connection to the Virtual Network Gateway at the Azure region. You will need to work with the network engineer to determine what static IP address this device will use to accept the site-to-site VPN connection as well as the address space (subnets) that reside in the network so the VNet will know what traffic to route through this VPN.

Local Network Gateway

Parameter	Configuration
Name	lgw-BDA-EastUS
IP Address	162.x.213.x
Address Space	10.247.0.0/16, 192.168.113.0/24

The naming convention chosen is to use the lgw- prefix followed by the location of the gateway (in this case BDA represents Bermuda) and finally which Azure region (East US) it is connecting to.

 

Connection (Site-to-Site)
The connection represents the site-to-site connection between the Azure Virtual Network Gateway to the Local Network Gateway.

Connection between Azure Virtual Network Gateway to Local Network Gateway

Parameter	Configuration
Connection Type	Site-to-Site
Name	cn-lgw-BDA-EastUS-to-vgw-EastUS
Shared key (PSK)	<create a unique string>
Protocol	IKEv2
Location	East US

The naming convention chosen is to use the cn- prefix followed by the local network gateway object name, then the -to- to indicate that it is connected to the virtual network gateway in Azure.

On-Premise Preparation

The network engineer configuring the VPN appliance on-premise will likely ask you for the:

• Public IP address of the virtual network gateway in Azure
• Shared key
• Address space in Azure (if they were not involved with the subnet planning)
• VPN type

You wouldn’t be able to complete the configuration without asking and obtaining the following information for the on-premise appliance:

• Public IP address of the local network gateway located on-premise

What I typically do is agree on a shared key, address space and VPN type with the network engineer, proceed to create the virtual network gateway, supply the information to the engineer, then ask for them to provide me with the public IP address of the local network gateway.

Deployment

Resource Group
Begin by creating the resource group or groups that these resources will reside in. For the purpose of this example, we will create one resource group named rg-prod-network for all of the resources.

Virtual Networks
Create the virtual network (VNet) that will be used to host the Virtual Network Gateway and host the resources such as virtual machines.

Remove the default IPv4 address space of 10.0.0.0/16 and default subnet of 10.0.0.0/24 if those are not the address space and subnet you will be using:

Add the subnet you’ll be using into the VNet configuration:

Leave DDoS protection on and the firewall either as disabled or enabled if one is configured and to be used:

Add a designed tag for the resources if ones have been planned for the resource:

Proceed to create the VNet:

Once the Virtual Network has been created, proceed to navigate into the resource, then to Subnets and then click on Gateway subnet:

Create the Gateway Subnet with the pre-planned subnet:

For the purpose of this example, we will only configure the Address range (CIDR block) and leave the rest as default/unconfigured.

You should now see the two subnets configured for the VNet:

Public IP Address
It may seem logical to create a public IP address before creating the virtual network gateway but what I’ve noticed in the past (not sure if this has changed) is you cannot assign a static public IP address to the gateway and creating a dynamic public IP address would not allow you to select it during the virtual network gateway configuration (probably because a dynamic public IP address doesn’t actually have an IP assigned to it until it is associated and used) so this is the one component that I create during the configuration of the virtual network gateway. Having the name of the public IP address for the virtual network gateway planned should still be done.

Virtual Network Gateway
Proceed to create the virtual network gateway by navigating to the virtual network gateways resource and click Add:

Create the virtual network gateway with the configuration previously planned:

The creation of the gateway takes a bit of time (upwards to 20 minutes or more) so do not expect it to be within a few minutes.

You’ll notice that the public IP address gets created quickly but there is no IP address assigned:

The reason is because this public IP address is configured for the virtual network gateway and the deployment hasn’t completed yet. Note how the Assignment configuration is set to Dynamic as well.

Once the virtual network gateway deployment has completed, obtain the public IP address that has been assigned to it, proceed to reach out to the network engineer configuring the local network gateway and provide him with the public information.

Also ensure that you have obtained the Public IP address of the local network gateway located on-premise.

Local Network Gateway
While waiting for the virtual network gateway deployment to complete, you can continue with creating the local network gateway by navigating to the local network gateways resource and click Add:

Create the local network gateway with the configuration previously planned:

The deployment, unlike the virtual network gateway, shouldn’t take too long to complete:

Connection (Site-to-Site)
Once you have confirmed with the network engineer that the on-premise VPN appliance is configured, you can proceed to connect the Azure Virtual Network Gateway to the Local Network Gateway. Proceed to navigate to the virtual network gateway object, connections and then click on the Add button:

Create the virtual network gateway connection to the local network gateway with the configuration previously planned:

The creation of the connection doesn’t take long and the initial connection Status will be labeled as Unknown:

Assuming there are no problems with the configuration then the Status will be change to Connected:

**Note that one of the things I’ve noticed in the past is that if you do not define an address space for the local gateway network then the connection status would remain unknown indefinitely so ensure that it has been configured.

You can proceed to configure additional site-to-site connections to other gateways if there are other datacenters or offices that need to connect into Azure.