Part of the overall equation of running your business in the cloud is determining how to reliably and securely access your resources. There is a myriad of ways to skin that cat; Remote Desktop Services, Citrix, Site-to-Site IPSEC VPN tunnels, SSH, etc. A very common method, especially for remote workers (i.e. those that are not within the company's private network) is a Point-to-Site (P2S) VPN. You may also hear these referred to as SSL VPNs (due to the commonly used method of encrypting the connection using an SSL Certificate). Point-to-Site VPNs are a private connectivity topology that consists of an endpoint (PC, phone, tablet, etc) connecting to a site network (That site can be on-premises, in the public cloud, a data center, etc).

Point-to-Site VPNs have existed on Microsoft Azure for sometime. You have the option of running a 3rd party appliance that supports such a service, or utilizing the Azure VPN Gateway platform. Up until Microsoft Ignite 2017, the only option to authorize a user connecting to an Azure VPN Gateway P2S was via a private certificate. This was problematic for several reasons. Either you had to run your own Private Key Infrastructure (PKI) or you generated a self signed certificate (bad idea!). If a users access needed to be revoked, there was the painstaking process of revoking the certificate at both the PKI authority and the Azure VPN Gateway. Or, in the case of a self-signed certificate, a new certificate would have to be generated and the old revoked, and any client connecting using the old certificate updated to use the new certificate. As you can imagine, this was not practical for an environment consisting of more than a few users.

Many new and exciting networking features were announced at Microsoft Ignite 2017. One of those new features was RADIUS authentication for Azure VPN Gateways. While RADIUS is an older technology, it is still very much in play today and remains very common. RADIUS allows for user identities to be verified against an identity authority by Username and Password. That could be an Active Directory Domain Controller, or a 3rd party authentication service. Let's take a look at a scenario utilizing an Active Directory Domain Controller.

Azure Environment

I built a basic environment with Azure that consists of a virtual network, 2 domain controllers, and an Azure VPN Gateway. I want access into this environment from a PC that is obviously not within the Azure virtual network.

Configuring the Azure VPN Gateway for RADIUS Authentication

In the Azure Portal, I configure the VPN Gateway for RADIUS authentication and direct its authentication source at my Domain Controller:

Address Pool: This is a range of IP addresses assigned to clients connecting into the VPN.

Authentication Type: As previously stated, we are configuring RADIUS Authentication.

Server IP Address: This is the address of the RADIUS server (in my case, the domain controller where authentications will be verified.

Server Secret: This is a password that is used by the Azure VPN Gateway and the RADIUS server to ensure both ends are supposed to be talking to one another.

Configuring the RADIUS Server

In our scenario a Domain Controller will be our RADIUS server. I installed the Network Policy & Access Server role on the server, and then configured the proper settings to allow the Azure VPN Gateway to authenticate users against Active Directory.

First, I created a new Network Policy called "AzureVPN" that allows authentication to take place. The policy grants access to the user if the policy requirements are met, specifies the type of connection (VPN), a specific group that users must be a member of to be authenticated (VPN Users), constrains the authentication method to MSCHAPv2, and finally specifies that the VPN Gateway will issue an IP address to the client on it's own.

Next, I created an new RADIUS client which specifies the Azure VPN Gateway as the requester, specifies the same shared password we input into the Azure VPN Gateway settings, and enables the Domain Controller/NPAS to begin fielding RADIUS requests.

Connecting to the VPN

Once the VPN Gateway and RADIUS server were configured, I then installed the VPN client from the Azure Portal on my PC and used it to connect to my Azure environment.

It appeared I had successfully connected, but I ran some additional tests to be sure.

As you can see, I had been given a private IP on the Azure virtual network by the Azure VPN Gateway and I was also able to ping the Domain Controller. At this point, I would now be able to reach and interact with my resources located in my Azure virtual network.

Conclusion

This is just one method to use RADIUS authentication for your Azure VPN Gateway. However, you may also want to consider leveraging 3rd party services such as DUO, Authanvil, or others that add additional functionality to your RADIUS authentication experience, such as Multi-Factor Authentication. Additionally, you may want to configure other settings according to your needs, such as connection time limits or other constraints.

Traditionally, it's important to note that this functionality is available in the Standard, High Performance, VPNGW1, VPNGW2, and VPNGW3 SKUs. It is not available in the Basic SKU VPN.

Either way, I am glad to see this functionality supported in Azure!



