AWS - Setup an AWS Client VPN using AWS Managed Microsoft AD

In modern IT environments, high availability and resiliency should be ingrained into everything that is built or developed. One common area that is often overlooked is your VPN client endpoint and the issues for remote staff if there is an issue with your client vpn endpoint, if you have a hybrid on-premise/AWS cloud environment with a greater percentage of your services sitting in AWS it makes sense to move your company's VPN endpoint to a managed AWS offering, it can offer greater security, resiliancy, scalability and remove the requirement of additional licences on your VPN endpoint device.

AWS Client VPN is a managed client-based VPN service that enables you to securely access your AWS resources and resources in your on-premises network. It uses OpenVPN and TLS to provide a secure connection into your AWS environment.

This guide shows you how to configure a AWS Client VPN with AWS Managed Microsoft Active Directory. AWS Directory Service creates two domain controllers in separate subnets for resiliency and adding the DNS service, these run on Windows Server 2012 R2.

You are billed per active association per Client VPN endpoint on an hourly basis. You are billed for each client VPN connection per hour. Billing is pro-rated for the hour. For more information, see AWS Client VPN Pricing.

For the purposes of this guide I am using the following;

CIDR Block - 172.16.0.0 /16

Client VPN IPv4 (VPN Pool) - 172.17.0.0 /22

Private Subnet 1A - 172.16.1.0 /24

Private Subnet 1B - 172.16.2.0 /24

DNS Servers -These are generated once the directory has been setup

Create Cloudwatch log group and log stream

For business use, it is essential to create a log stream so that VPN activity can be recorded and audited.

Navigate to Cloudwatch within the AWS management console then select Logs from the left hand side, select Action > Create Log Group and give it a logical name (client-vpn-log-group)

Once the log group has been created go into it and select create log stream and give it a logical name (i.e. client-vpn-log-stream)

Create Certificate in ACM

Within the AWS console search for Certificate Manager or ACM

Select request a public certificate, add your domain or a wildcard (i.e. *.infra.engineer)

Validate the domain via DNS or Email

I strongly recommend using Route 53 if you do not use it already, if you do use it select the Create record in Route53 otherwise it will have to be verified manually.

A few minutes after the records have been created the domain should change from pending validation to validated.

If you have multiple certificates note the last few characters or the ARN or the Identifier to use later on when setting up the endpoint.

Create AWS Managed Microsoft AD

Within the AWS console search for Directory Service then select "AWS Managed Microsoft AD"

Please be aware of the running costs when setting up this directory, see here for pricing

Select the Standard edition, enter an internal FQDN for the domain and create an administrator password

Choose your VPC and 2 private subnets (An additional one can be created here if you only have one)

Review and create, allow 30 minutes for the directory to be created.

Create a server to install admin tools

This step is not required if you have a server but a server will need joined to the directory/domain to allow the control of active directory using the normal tools to perform tasks such as creating user accounts, security groups or organise computers etc.

Create a new windows server in one of the private subnets with standard settings apart from set the domain join directory and create an IAM role with AmazonEC2RoleforSSM permissions,

Once the server has been created and you have RDP'd into it using the domain administrator account format and the username admin i.e. domain\admin and the password from earlier (This can be reset within the AWS directory if required)

Add the Active Directory Administration Tools on Server 2016;

Open Server Manager from the Start screen by choosing Server Manager.
In the Server Manager Dashboard, choose Add roles and features,
In the Add Roles and Features Wizard choose Installation Type, select Role-based or feature-based installation, and choose Next.
Under Server Selection, make sure the local server is selected, and choose Features in the left navigation pane.
In the Features tree, open Remote Server Administration Tools, Role Administration Tools, select AD DS and AD LDS Tools, scroll down and select DNS Server Tools, and then choose Next.
Review the information and choose Install. When the feature installation is finished, the Active Directory tools are available on the Start screen in the Administrative Tools folder.

Once installed open the Active Directory Users and Computers from the Administrative Tools, if it does not open correctly check to ensure you are not logged on as a local administrator, the RDP username format should be domainname\admin

Drill down to the OU that your domain is set to (You do not have permission to create objects at a higher level than this)

Create a couple of test users (Untick change passwords at next login) and a Client VPN Users security group, add 1 test user to this.

Also using powershell get the SID of the group using the command, this sid will be used to control who has authorisation to use the VPN

Get-ADGroup -Identity "Client VPN Users"

Create the Client VPN endpoint

Navigate to the VPC section

On the left hand side under Virtual Private Network (VPN) > Client Endpoints > Create Client VPN Endpoint

Create a name tag and description

Add your client subnet in CIDR notation. As per AWS guidelines, the IP address range cannot overlap with the target network or any of the routes that will be associated with the Client VPN endpoint. The client CIDR range must have a block size that is between /16 and /22 and not overlap with VPC CIDR or any other route in the route table. The IP address range cannot be changed after the Client VPN endpoint has been created. For this purpose I am using 172.17.0.0 /22

Set the server certificate ARN to the certificate created earlier, set your authentication option to active directory and set the directory ID, set your connection logging to the cloudwatch group name and log stream created earlier to audit VPN activity

Specify the 2 internal DNS servers that were created automatically by AWS after your directory has been created. (These are displayed once the directory has been created)

Once all options have been checked, click to create client VPN endpoint.

Once this has been created, it will be in a pending completion state until a target network is added.

It should now give a DNS name along the lines of *.cvpn-endpoint-0123xxx0.prod.clientvpn.eu-west-1.amazonaws.com which will be used later for connectivity.

Enable VPN connectivity for clients

You must associate a target network (Must be /27 or greater) with the Client VPN endpoint which will enable clients to establish a VPN session. A target network is a subnet within the VPC.

Still within the Client VPN Endpoints, click the associations tab and click associate

After a few minutes the client VPN should go from a pending state to available.

Authorise clients to access the network

An authorisation rule must now be created to say which users can access the VPC that the subnet sits within.

Select the authorisation tab and select the authorisation ingress

Specify the destination network to be authorised (For this example I have used my full CIDR block but normally this will be controlled to a segment of the network), paste the SID of the authorised security group from the powershell command earlier then select add authorisation rule

After a short while pending, this rule will go active.

Enable access to your on-premise network (Optional)

To add access to your on premise network, add a network route to your on-premise network specifying the target VPC subnet which has routes/access to this network. An authorisation rule must also be granted to this subnet as per the last section.

Tip: Any new subnets used to be used to communicate to an on premise network will likely have to have route tables and ACL's updated at both ends along with permitted subnets added on both VPN endpoints.

A sample route table entry would look like,

If you do not want to use split-tunnel and force all traffic through the VPN, create a route table entry for 0.0.0.0/0 specifying a Target VPC subnet ID which has internet access.

Download and edit the configuration file

Download the configuration file from the Client VPN Endpoint and edit it using Notepad++ (Notepad does not work well here)

Copy and paste the root PEM file below or from Amazon Trust at https://www.amazontrust.com/repository/SFSRootCAG2.pem

This seems to be a bug in the config file for windows but this needs to be replace the 3rd certificate at the bottom of the ovpn file, save and close the ovpn file

Install the OpenVPN Client

Install the latest stable OpenVPN client with default settings from https://openvpn.net/community-downloads/

The windows client is around 3.8MB

I experienced permission issues with the local route table updates, so I set the program to run as administrator by right clicking the OpenVPN and under the Compatibility tab set the program to run as administrator

Connect to the VPN

Run the OpenVPN software (Administrator mode should be set as above), select your imported ovpn profile, then enter your credentials of the active directory user created earlier.

Note: Please be aware that non approved users can connect to the VPN but without the authorisation rule they cannot get anywhere.

Once connected you should be able to access your internal resource (Check firewalls/routing/security groups if issues are encountered)

Remember to disconnect once finished and implement split tunnel if required.

Your Cloudwatch log stream should also have recorded details of the connections, i.e.