Staff working from home can present challenges for organizations, especially for those who have been forced into fast-tracking these arrangements due to the COVID-19 virus. IT departments around the world are scrambling to implement ways to enable their colleagues to work remotely and helping keep the lights on for their employers. Thankfully, the cloud has been the new normal for around 90% of organizations in some way or form for the last few years. That being said, the cloud doesn't just solve all your remote-working problems magically, there are often still several challenges present depending on the cloud strategy which has been adopted in your organization — SaaS, PaaS, IaaS, hybrid-cloud or a combination of them all.
Several months ago I wrote about how organizations can link their on-premise and cloud networks together using IPSec VPNs, but what about enabling employees to gain access to access these same systems and infrastructure from home? If you guessed Client VPNs you guessed right, but are probably thinking, "this isn't anything new, our company already has a Client VPN", and you'd also be right. The new problem these organizations are now facing is their current VPN infrastructure doesn't have enough capacity to serve the demands of a fully remote workforce and is compromising the efficiency of their staff's daily tasks. So, how can we solve this problem quickly, securely and inexpensively? By leveraging your cloud provider, of course!
In this example, I'll walk through how you can setup a Point-to-Site VPN in Azure, though the same can be achieved on AWS. Ok — let's get started!
Caveat: I'm assuming you already have an Azure tenant, subscription and VNet configured.
1. Create a Virtual Network Gateway
The first piece of the puzzle is to create an Azure Virtual Network Gateway to facilitate access for the outside world into your Azure VNet. Now, depending on the capacity you require will depend on the SKU which should be selected — the varying tiers support different bandwidth throughputs and connection limits. Any of the SKUs are fine to use except for basic, as the basic SKU does not support the Azure AD Authentication option which we'll want to use later.
Fill out the details like in the screenshots below, everything essentially can be left as default, ensuring you select the right VNet and define a Gateway subnet range which doesn't conflict with one already in use within your VNet. It will take around 30 minutes for the gateway to deploy.
2. Configure the Point-to-Site VPN
After the Virtual Network Gateway has been provisioned, navigate to it, select "Point-to-Site Configuration" and click the Configure Now button to get started setting up the Client VPN configuration. Now at this point, open a new tab as there will be some jumping around to gather all of the information required.
We now need to navigate to Azure Active Directory and take a copy of your Tenant ID as we'll need this for some of the fields in the Point-to-Site configuration.
Next, we need to allow access for the Virtual Network Gateway to utilize Azure AD for authentication when users connect. To facilitate this we grant permission to the Azure VPN application in Azure AD. Depending on your deployment location there are a few endpoints which can be used, we're going to use the standard public endpoint:
After permission has been granted to the Azure VPN app, navigate to the Enterprise Applications tab within Azure AD and take a copy of the Application ID (though will likely be 41b23e61–6c1e-4545-b367-cd054e0ed4b4 if using the public endpoint).
Going back to our tab for the Point-to-Site configuration, let's start populating the details we've gathered. Fill out as the following:
- An address pool which does not conflict with your VNet's CIDR block
- OpenVPN (SSL) as the tunnel type
- Azure Active Directory as the authentication type
- Using your Tenant ID from earlier, populate tenant with the following, ensuring you keep the trailing slash: https://login.microsoftonline.com/<Tenant ID>/
- Use the Application ID from the app registration as the audience (this should be: 41b23e61–6c1e-4545-b367-cd054e0ed4b4
- Using your Tenant ID again, populate issuer with the following, also ensuring you keep the trailing slash: https://sts.windows.net/<Tenant ID>/
Now you can save the configuration! Once saved (this takes a minute or two), once done click Download VPN client to get a copy of the configuration files for use later. That's it — we're done with the configuration!
3. Getting Connected
Azure VPN uses OpenVPN as the technology behind the service — so any OpenVPN compatible client can theoretically be used, but to make our life easier we can install the Azure VPN Client from the Microsoft Store for free.
Once installed and opened, click the + button at the bottom of the window and choose the import option — import the VPN configuration downloaded from Azure earlier.
The VPN client should show you the connection information, rename it if you'd like, otherwise the other information can be kept as default. Click Save.
We're now ready to connect! If you have multiple accounts select the correct account to sign in with after clicking connect, enter any details you're prompted for. If all has gone well you should see "Connected" and connection details in the interface.
4. Testing Connectivity
Now we're connected, let's do some simple tests to establish there is end-to-end connectivity into Azure from my PC. First up are the ping and trace tests:
And to show something real is on the other side of this IP address, we'll open an SSH session to a VM which exists in my Azure tenant. It works!
Summary
Any Azure service which exists in your VNet or can be connected via PrivateLink can be accessed in this way; web apps, databases, remote desktop and much more. With a little planning, almost any organization can provide a similar experience for staff working from home that they are used to from within their offices, relatively quickly, for a reasonable cost and without compromising security.