Update March 17, 2020 – With recent events, the need to provide a remote workforce with secured connectivity is greater than ever. It comes as no surprise that this post (originally published on December 19, 2018) is receiving a lot of traffic. The content is still relevant today, so we’re publishing it again to make it easier to find.  You may also be interested in a recent 300-level online tech talk that dives into our Client VPN and Site to Site VPN services in detail.

Many organizations, both small and large, rely on some form of client virtual private network (VPN) connectivity to facilitate secure remote user access to resources hosted on internal networks. This has often meant relying on on-premises VPN hardware or provisioning client VPN infrastructure in EC2 instances. Managing these client-based VPN solutions presents scaling and operational challenges and is an ongoing burden. Many times, unforeseen events cause spikes in the bandwidth and connection requirements, causing reduced VPN availability.

Overview

AWS Client VPN is a fully managed service that provides customers with the ability to securely access AWS and on-premises resources from any location using OpenVPN based clients. Connectivity from remote end-users to AWS and on-premises resources can be facilitated by this highly available, scalable, and pay-as-you-go service. The undifferentiated heavy lifting of maintaining and running a client VPN solution is completely avoided. What’s also unique with AWS Client VPN is the scalable nature of the service. The service will seamlessly scale to many users, without the need to acquire or manage any licenses or additional infrastructure. This is key for spiky workloads, such as the typical ebbs and flows of workforce connectivity throughout the day. A great example of this is inclement weather. Legacy client VPN solutions are typically pushed to their limits when there is an increase in client connections, not to mention the huge influx in bandwidth required to serve client connections. AWS Client VPN will scale to meet the capacity needs and ensure a consistent user experience, despite influxes in usage.

AWS Client VPN supports both certificate-based and Active Directory based authentication. Customers get tighter security controls because they can define access control rules based on Active Directory groups and can use security groups to limit access of AWS Client VPN users. Using a single console, you can easily monitor and manage all of your client VPN connections. Client VPN allows you to choose from OpenVPN-based clients, including Windows, macOS, iOS, Android, and Linux based devices.

Client VPN seeks to simplify the provisioning, scaling, and management of a client VPN infrastructure in a cloud-centric fashion. With a few clicks in the console you can easily deploy a scalable client VPN solution. We’ll walk through this exciting new service!

How it works

AWS manages the back-end infrastructure for Client VPN. You only need to configure the service to meet your needs. The provisioning process is shown in the following architecture diagram.

Deploying Client VPN

We’ll now walk through deploying Client VPN. We’ll walk through deploying an end-to-end solution for client VPN connectivity using Active Directory authentication.

Create a Client VPN Endpoint

We start by navigating to the VPC section of the AWS Management Console. There is a new option, Client VPN endpoints.

From this new part of the console we can create a Client VPN endpoint.

We then choose a CIDR for our VPN clients. For this example we are using a /22 address space, which is the smallest subnet that can be used. You can specify a larger subnet if required (up to a /18). Ensure the subnet you choose does not overlap with the resources you’ll want to access via the Client VPN endpoint. Note that Client VPN will use source NAT (SNAT) to connect to resources in the associated VPC(s).

In the next section, we need to enter information for authentication. I have previously deployed a managed Active Directory, so I will choose that. If you do not have an AWS Managed Microsoft AD directory, you can find more information on setup. We will need to generate and import a private certificate into AWS Certificate Manager (ACM). For this walk-though we are only showing Active Directory authentication.

In the next section we’ll configure connection logging. I’ve already set up a CloudWatch log group for this purpose. With connection logging, we can get forensics on which clients attempted to connect and the result of the connection attempt.

In the final section of configuration, we specify the IP address for DNS servers and choose TCP or UDP for client connections. Here I choose the IP addresses of my Route 53 Resolver inbound endpoints, but you can choose whichever DNS servers you use in your environment.

After we finish filling in the required information, we can see that the VPN endpoint is Pending-associate. We can now associate the VPN endpoint with one or more VPCs.

Associate Client VPN endpoint to a Target Network

Our next step is to associate our VPN endpoint with a target network (a VPC subnet). This is done through the Associations part of the AWS Client VPN console.

We choose a VPC and subnet to create the association with our Client VPN endpoint. I created a specific subnet in the VPC to host the ENIs for the VPC endpoint for easy visibility and traceability of client VPN traffic. Note you can associate the client VPC endpoint to multiple subnets. The requirement is that each of the subnets needs to belong to the same VPC but different Availability Zones. After successfully associating a target network (subnet in a VPC), we can create VPN sessions, but we will not be able to access any resources.

Enable end-user access to VPC (Add authorization rule)

Our next step is to add an authorization rule. An authorization rule controls which set of users can access a specified network through the Client VPN endpoint. I only want users in my “Client VPN” AD group to have access. To accomplish this, I start by getting the SID of the “Client VPN” AD group I created in an existing AWS Managed Microsoft Active Directory in my AWS account. This is shown in the following screenshot.

I then go to the authorizations part of the Client VPN console and click Authorize Ingress.

For Destination network to enable I enter a default route of 0.0.0.0/0 because I want to enable all traffic to flow through the client VPN endpoint, including internet traffic (through a NAT Gateway I have running in the VPC). I then place the SID of my VPN Users groups in the the Active Directory group name field (acquired from running the previous command). Now users belonging to the “Client VPN” AD group are authorized to route all traffic through the VPN client endpoint.

Applying a security group

Client VPN endpoints support security groups. Security groups can be used to limit access to applications. Note that the security group only controls the traffic egress from the VPC associated ENIs. To limit the traffic that can route through the VPC associated ENI(s), restrictive authorizations can be used.

I start by selecting the VPN endpoint and going to the security group tab. From there, I select Apply Security Groups.

I have an Allow All security group that I select, but this could be a set of one or more specific security groups that are more restrictive.

A neat feature with security groups here is that we can leverage the security groups we have applied to our VPN endpoint as the source for traffic in other security groups. This allows us to create security groups that only allow connectivity from VPN clients.

Add routes

Routes for associated VPCs are automatically added to the Client VPN route table. This is shown in the following screenshot.

Since I want this VPC association to provide internet connectivity to VPN clients (though a NAT Gateway already running in the VPC), I need to add a default route of 0.0.0.0/0 to the route table. I start this process by clicking the Create Route button. I then select the target VPC subnet and enter a description.

An interesting point to note here is that the VPC association Elastic Network Interface (ENI) has a public IP. If my association subnet were to reside in a public subnet, I could use it to provide internet access to my VPN clients. This is shown in the following screenshot of the Network Interface section of the EC2 console.

A powerful feature of AWS Client VPN is the ability to access on-premises resources. Since my associated VPC has access to on-premises resources, I can add a route for my on-premises network (10.200.0.0/24). Note here that since I have an authorization that already allows 0.0.0.0/0, I do not need to explicitly add a new authorization. If I did not have the default route authorization, I would need to create a new authorization for my on-premises network (10.200.0.0/24). Similarly, if you want to connect to other VPCs, you can peer the VPC to the VPC that has the subnet associated.

Download the Client Configuration

Now that we have our infrastructure provisioned and configured, out final step is to download the client configuration. Since we use open-VPN, and I’m using macOS, I downloaded and installed Tunnelblick.

Now I just need to download the client configuration from the console. I select the VPN endpoint and click the Download Client Configuration button.

From there I just open the config file with Tunnelblick by double-clicking the config file from my Mac and I can VPN into my VPC!

Monitoring Client Connections

Since AWS Client VPN is a cloud-based service, logging and analytics are baked in. We can monitor all our client connections from the console for a quick real-time view of our client connections. This is shown in the following screenshot. I was able to monitor my client connections as they were happening. This is super helpful for troubleshooting and monitoring. CloudWatch and CloudTrail can also be used for monitoring.

Conclusion

We’ve shown how easy it is to get up and running with Client VPN and remove the undifferentiated heavy lifting of deploying a client VPN solution. With a single VPN client tunnel, we can access resources in AWS or on-premises from any location using OpenVPN based clients. You also get granular security capabilities with network based rules and security groups.

We hope that you’ve found this post informational and we look forward to hearing how you use this new service!