As we move more and more workloads from on-premises to Microsoft Azure, where the elasticity and economy of scales play a big role in managing datacenter/infrastructure, we can start using more cloud solutions to solve some of the common problems that we face today. VPN support (when required) to your desktop is a good example and the topic for this article. One feature of the virtual network gateway that is sometimes overlooked is allowing VPN clients to connect directly to your environment.
Using point-to-site may bring benefits and reduce costs where your traditional VPN infrastructure may no longer be required at all, and the process of switching over to Azure will save money on licenses and annual fees that VPN software/appliances like to charge to enterprises.
Creating the virtual network gateway
The first step is to create the virtual network gateway. A prerequisite for this Azure Resource is the virtual network, and a subnet must be created to support the new virtual network gateway. The subnet name that will be provisioned as part of the process is called GatewaySubnet.
Note: The virtual network gateway is always deployed in the same resource group of the virtual network when using the Azure Portal. Thus, the missing resource group option during the creation wizard.
There are several ways to create it using Azure Portal. A simple one is logged in to the Azure Portal, search for virtual network gateway, and on the new blade, click on Add.
On the Basics page, we have all the settings that we need to define our virtual network gateway. Besides the traditional settings, like subscription, name, region, we do have some specific settings to define if this gateway will be a VPN or ExpressRoute, and what type of routing (route-based or policy-based).
Nowadays, we have two generations of virtual network gateways, and each generation has several SKUs. The difference between them is the number of tunnels/connections, aggregate throughput, BGP capabilities, and the ability to be zone redundant.
We will have to define one or two public IP addresses. If we decide to use Active-Active, then a secondary public IP address will be required. Keep in mind that the ability to have Active-Active relies on the SKU chosen for the VPN gateway.
After reviewing all the settings, click on Review+Create and wait for the completion of the new virtual network gateway.
The result will be a new virtual network gateway, and on the Overview page, we can see the public IP addresses assigned to the new VPN gateway. We can see the metrics available, which we can use for troubleshooting.
Gathering key information to support VPN client configuration
Before starting the configuration to support VPN clients to connect in our Azure environment, we should go on a trip to gather some information in our Azure tenant.
Our first stop is going to Azure Active Directory in the Azure Portal (you can search Azure Active Directory and select from the list). On the Azure Active Directory pane, click on Properties, and let’s copy the “Tenant ID” information and save it for later use.
The second step is to perform some string manipulation. We need to replace the <TenantID> in the two lines below with the Tenant ID information that we just retrieved in the previous step.
- https://login.microsoftonline.com/<Tenant-ID>
- https://sts.windows.net/<Tenant-ID>/
The final step is to define the value for the audience field (you haven’t seen it, but it is coming). This value is based on your location, as follows:
If you want an easier approach, then open your Cloud Shell (using PowerShell) and save the content below as a file. In my case, I renamed it as P2S-InfoGather.ps1.
$tenantId = (Get-AzTenant).Id
write-host ("Tenant.....: https://login.microsoftonline.com/" + $tenantId)
write-Host "Audience....: 41b23e61-6c1e-4545-b367-cd054e0ed4b4 (Public)"
write-Host " 51bb15d4-3a4f-4ebf-9dca-40096fe32426 (Azure Government)"
write-Host " 538ee9e6-310a-468d-afef-ea97365856a9 (Azure Germany)"
write-Host " 49f817b6-84ae-4cc0-928c-73f27289b3aa (Azure China/21Vianet)"
write-host ("Issuer.....: https://sts.windows.net/" + $tenantId + "/")
When executed as depicted in the image below, it will provide all the information required for our next step.
Configuring point-to-site (aka VPN client support)
The process to configure a virtual network gateway to support point-to-site (VPN clients) is by selecting the point-to-site configuration item and then hitting Configure to start the configuration.
On the new page is where the magic happens. We need first define an address pool to the VPN clients that will be assigned. Important, make sure that you don’t overlap that range with your internal IP range. The idea is to have a range completely alien to your existing network.
Azure VPN gateway supports several tunnel types: OpenVPN, SSTP, IKEv2, IKEv2, OpenVPN, and IKEv2 and SSTP. In the Authentication area, there is support for Azure Certificate, Azure Active Directory, and RADIUS authentication.
We will use OpenVPN and Azure Active Directory and use all the information gathered in the previous section. The result on your side should be similar to the image below.
We are ready to test our connection. However, in the unlikely event that you need to disable point-to-site from your environment, here are the steps to perform such a task.
$gw=Get-AzVirtualNetworkGateway -name <gateway-name>` $gw.VPNClientConfiguration = $null` Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`
Configuring the VPN client
After configuring the point-to-site in the Azure Portal, the new Download VPN client button will be available. Click on it, and it will download all the configuration files required on the client-side, save them in a place that we can distribute to our future clients.
Extract the content of the download file. In our example, we extracted to the C:\VPNGateway folder as depicted in the image below.
Time to install the Azure VPN client on your desktop (assuming that you are using Windows 10 on this article). Open Microsoft Store, search and install the Azure VPN client, or you can download it directly using this link. After installing it, click on Launch.
On the main page of the Azure VPN client, click on the + sign located on the bottom left corner, and then click on Import. In the file dialogue box, search for the file azurevpnconfig.xml, which can be found under the AzureVPN folder from the extracted files from the previous step.
All configurations required to configure the client will be filled out automatically, as depicted in the image below. Click on Save to confirm (no changes are required from the customer side).
The result of the steps we have done so far is a new connection listed on the left side. We can click on Connect to start the connection. We also have some options to Diagnose, configure, export, and even remove the connection.
We are using Azure authentication, and we need to provide the credentials to continue with the connection process.
After establishing the connection, we will have all the IP information and routing for the VPN client.
Monitoring the VPN clients
On the Azure side, we can check all connected VPN clients by checking the point-to-site sessions.
We can also check the metrics, and all P2S entries are related to VPN clients.
You’re set up and ready to go
This article covered all the required steps to create a virtual network gateway, configure it to support VPN clients, and check the steps required on the client-side to connect.
If you are already using a VPN gateway for site-to-site (S2S) connections, you can add the steps we provided in this article on the same VPN gateway. After all, there is no need to spin up two virtual network gateways if you can do all the work with a single one.
Featured image: Shutterstock
I like this
Thanks for this guide
Will it work for Windows Autopilot in hybrid Azure AD Join (HAADJ) ?
This is a great primer on setting up VPN; thank-you.
Would you be able to provide some additional info?
– How do you define which IPs get routed via this VPN; i.e. normally the VPN client is given a list of subnets to route via VPN vs those IPs which would resolve to its own LAN. Or is that not covered by the VPN Client, but rather something the user would have to setup via `route add …` commands?
– I’ve read that you shouldn’t associate a Network Security Group (NSG) with your GatewaySubnet; so you can’t set outbound rules… How do you control what resources anyone connected over this VPN has access to; is this done solely through what the GatewaySubnet’s VNet has connectivity with, plus the NSGs inbound rules on the destination resources.
Thanks in advance for any advice in these areas.