OpenVPN on Protecting Gig Employees & Remote Workers with a VPN
Guest Post by Lauren Elkin, Technical Writer, OpenVPN
The rapid growth of both the gig economy and flexible, remote workforce has led to a revolution for employment. Businesses now have the ability to hire people regardless of location. However, supporting a distributed workforce comes with its own technological difficulties. At OpenVPN, which provides secure and scalable communication services, we wanted to launch a virtual private network (VPN) using AWS to provide our remote workforce with security and privacy wherever they are. We also wanted to provide our users with a custom domain name for downloading their clients and configuration files. With our Amazon Machine Image (AMI) purpose-built with OpenVPN Access Server, and a simple registration and configuration using Amazon’s Route 53, we set it up in less than an hour. Here’s how we did it and how it would fit for a use case for a small business.
Launching a VPN
Many are familiar with OpenVPN as a secure VPN protocol available through open source code. Not as many are familiar with OpenVPN Access Server, our commercial product, which provides a powerful web interface. The advantage of this product is simplicity. This is because with the product, you get an easy-to-use web administration portal.
Amazon provides managed VPN, AWS Client VPN. This is a great solution for site-to-site, amongst other use cases. For remote-access VPN, you can find a number of solutions on Amazon EC2, including OpenVPN.
Getting an OpenVPN Access Server up and running is quick and doesn’t require working exclusively in a Linux environment. Access Server also provides a simplified client distribution. You’ll be able to send your gig and remote workers a custom domain. From that URL, they can login with credentials you provide and download OS-specific clients bundled with the required certificates and configuration to connect to your AWS-hosted Access Server.
Make it simple
We didn’t want to deal with an IP address for getting to the VPN. We wanted the convenience of using an easy URL. Any step that convolutes security means a user won’t likely take it. We created a new domain through Amazon’s Route 53 called accessservertest.com and created a subdomain for connecting to the VPN. It didn’t take long at all.
Launching the OpenVPN Access Server AMI
To start, we launched a t2.micro instance setup with OpenVPN Access Server directly from the AWS Marketplace. It only took a few clicks using the purpose-built AMI. After choosing t2.micro and clicking through the configuration, we set it up with an Elastic IP address.
After launching the AMI, we connected with SSH to the Linux machine via the IP. Once logged in, the OpenVPN Access Server configuration launched automatically. We set ours up with the default settings, made note of the URL address for the Admin Web UI (https://[instance-IP-address]/admin). We also set a password for the bootstrap user by entering the command passwd openvpn (with root privileges).
Now that your Access Server is up and running, we opened a web browser and entered the URL for our Admin Web UI. We logged in with the openvpn user and the new password. The first time logging in, the web browser shows a security warning. This is because Access Server comes with a self-signed certificate. Once you setup your custom domain, you’ll want to replace that with your own web cert, but to start, we simply clicked through the warning. This warning is due to the self-signed certificate Access Server ships with. You’ll be able to easily import your own valid SSL web certificate using the admin tool to remove the warning. After agreeing to the EULA, we were in the Admin Web UI. It’s a great tool for managing many configuration settings for your VPN. We want to check on how the web traffic will route, since we’re providing remote and gig workers with security wherever they connect to the internet.
From Configuration > VPN Settings, there’s a question under the Routing section that asks, “Should client Internet traffic be routed through the VPN?” When you want your VPN to secure Internet traffic for any users, you want to make sure this is set to Yes. When it’s set to No, this is split tunneling. For clients connected to a VPN with that configuration, only traffic destined to the private networks will traverse the VPN while other traffic will bypass it.
Now that we know the VPN will handle Internet traffic, we can move on. The next step was to hop on over to Amazon’s Route 53 and set up our domain.
Registering a domain
These are the steps we took to register our domain and create our subdomain, using Route 53.
- Login to AWS Management Console
- Enter Route 53 in Find Services (or click on Register a domain in the Build a solution section.
- Enter the domain name, choose an extension (.com, .net, etc) and click on Check.
- Once you have your preferred domain and it’s available, click on Add to cart.
- Go through the steps to register the domain by entering contact details, then verifying and purchasing. (Amazon automatically creates a hosted zone where you will store information for routing traffic to an Amazon EC2 instance.)
- Click on Complete Order.
- Wait for the domain registration to complete (it states that it may take more than a day, but for us it took less than an hour).
Creating a specific sub-domain
- From the Registered Domains console, click on your domain name.
- Click on Manage DNS.
- Click on the main domain name under the Hosted Zones.
- Click on Create Record Set.
- Add an A record set by entering vpn in the Name field, leaving Type set to A and entering your OpenVPN Access Server AMI’s IP address in the Value field.
- Click Create.
Setting up OpenVPN Access Server with the new hostname
The final setup step is to update your Access Server with your new hostname. We logged in to our Access Server’s Admin Web UI again by going to the IP address from the initial setup. Once logged in, we went to Configuration > Network Settings. In the Hostname or IP Address field, we typed in our new, custom domain. For our example, we entered vpn.accessservertest.com. We clicked on Save Settings and then Update Running Server.
Now we could create new users in the Admin Web UI, then send those credentials over to our remote and gig workers. They could enter vpn.accessservertest.com into a web browser, login, and download clients directly from the Client UI. Those clients came already configured to connect to our OpenVPN Access Server AMI. They also had the option to download a configuration file if they had a preferred VPN client on their device already. With only a few clicks, we provided our users with easy access to our VPN and they could now browse securely over their internet connections.
Here’s the detail of how the connection to vpn.accessservertest.com works using Route 53 and OpenVPN Access Server. It looks like a lot of steps, but DNS resolvers work fast.
Now that we’ve setup Access Server to handle Internet traffic, created our custom domain, and configured all settings with that, we can also access the Admin Web UI from our custom domain by going to vpn.accessservertest.com/admin. It’s much easier than remembering an IP address and port.
Use Case for Tech Startup
A great example for using this AWS setup is a tech startup company. They don’t want to expose any of their data to the internet as they develop their app. For trial customers and focus groups, however, they want to provide secure access and they want it to be easy to invite them to participate. If they can provide easy access and simplified setup for doing so securely, they feel like they’ll have more success with trial customers and focus groups following through with participation.
They set up OpenVPN Access Server on an AMI within their AWS VPC. They also created a custom domain through Route 53: vpn.trialapp.com. This simplified the email invite. They gave instructions to visit the website, login, and download a VPN client with configuration for connecting immediately.
Not only is it simple for the tech startup to invite beta testers, but they can easily manage access. With the Admin Web UI for Access Server, they can easily add users, manage the granularity of access control, revoke access, or delete users.
It’s a good idea to setup your custom domain with a web certificate and copy the necessary files over to Access Server. After doing this, you no longer receive the security warning from your browser when you go to the Admin Web or Client UI. For a simple tutorial on doing this, we put together a video: Installing a Valid Web Certificate.
Amazon Web Services enables us to provide our purpose-built AMI so businesses of all sizes can launch a VPN solution within minutes. Using OpenVPN Access Server provides secure remote access, multiple client OS support, automated certificate management, single-sign-on capability, integrated two-factor authentication, and fine-grained access control.
Setting up a VPN with AWS doesn’t require Linux fluency or paying a third-party provider. OpenVPN Access Server is an affordable solution that provides two free simultaneous connections. That means we could set up our solution and test it out for free on Amazon’s free tier without worrying about an initial investment.