Overall Context Architecture

To ensure you have the highest level of security controls implemented for interactive user access to instances and services within the your AWS environment, the following architecture has designed which encompasses:

  1. Mutual authentication - require a validated(server signed) client certificate to access the environment
  2. SSO Federated authentication - require an account in the Organisational Account which has MFA enabled/configured
  3. Access to Client VPN SSO Application - require user account to be added to application group
  4. Network access to Client VPN is locked down to IP address and group access - depending on the numer of users, network level access to the Client VPN should be locked down to users IP address (so they do need a static IP address) as well as the SSO Group associated with the destination CIDR.

As the level of security controls implemented are extensive and defence in depth, the access to all configured environments (in VPC Client VPN Endpoints) can be achieved via central Client VPN in your central inspection or management VPC. Using an inspection VPC also has the advantage of routing being possible from there given its ideally the central routing hub account for all external connections and generally associated with your AWS Transti Gateway. Monitoring and control can be maintained via:

  • Client certificates are generated by environment administrators and supplied to users on an as needed basis.
  • CloudWatch logging is enabled so there is traceability for access control.
  • If additional event based controls are required they can be implemented quickly using EventBridge, CloudWatch and other services such as SNS notifications.
client vpn context diagram

Client VPN with Mutual Authentication and SAML Federated User Access

Ideally there is a requirement to have interactive user access to EC2 instances and other services which ordinarily would require access via a public facing bastion server, which inherently reduces the security posture of environments given bastions are generally required to have a publicly accessible access point in order to gain access.

Through the use of the AWS Client VPN service, access can be locked down as well as has the additional advantage of being able to combine different authorisation methods to further strengthen access and overall security posture for interactive user access. Noting that AWS Client VPNs also instantiate public IP endpoints, they're AWS infrastructure and come with the associated security controls AWS provides in their shared responsibility model.

The authorisation methods which will be implemented will be:

  • Single Sign On Authentication using AWS Identity Centre implemented within the Master Payer Account should you use AWS Organisation, which ideally you are in this use case
  • Mutual Authentication using client server certificates which are married against the Server Certificate loaded into AWS Certificate Manager
Console Logged In

Along with requiring access via federated access the client also needs to have the CA which they obtain by logging into the self-service portal once logged into the SSO login screen as per above screen shot.

SAML Assertion

What is Mutual TLS (Transport Layer Security)

With mutual authentication, Client VPN uses certificates to perform authentication between the client and the server. Certificates are a digital form of identification issued by a certificate authority (CA). The server uses client certificates to authenticate clients when they attempt to connect to the Client VPN endpoint. You must create a server certificate and key, and at least one client certificate and key.

The main thing that makes mTLS different (and arguably more secure) is that it requires both the server and client to verify each other via a handshake. This is where the exchange will be done between server cert and client certs.

To configure mutual TLS, we first create the private certificate authority and subsequent client certificates. We need the public keys of the root certificate authority and any intermediate certificate authorities. These must be uploaded to Certificate Manager to authenticate certificates using mutual TLS. The approach being taken to keep costs down and should you not have a root CA would be to use Self Signed certs using tools such as OpenSSL. Using OpenSSL to create the certificate authority and client certificate, you can optionally use AWS Certificate Manager Private Certificate Authority (ACM Private CA) to manage this process.



mutual TLS

The Technical Stuff - Creation of mTLS Root Authority Certificate (Self Signed)

First create a new certificate authority (CA) with signed client certificate using OpenVPN easy-rsa repo, this certificate will be required to be generated and imported into AWS Certificate Manager account manually as a prerequisite for any further deployment:

To generate the server certificates and keys and upload them to ACM:

  1. Clone the OpenVPN easy-rsa repo to your local computer and navigate to the easy-rsa/easyrsa3 folder.
  2. $ git clone https://github.com/OpenVPN/easy-rsa.git
    $ cd easy-rsa/easyrsa3
  3. Initialize a new PKI environment.
  4. $ ./easyrsa init-pki
  5. To build a new certificate authority (CA), run this command and follow the prompts.
  6. $ ./easyrsa build-ca nopass
  7. Generate the server certificate and key using cert domain name client-vpn.server.yourdomain.com
  8. $ ./easyrsa build-server-full client-vpn.server.yourdomain.com nopass
  9. Copy the server certificate and key to a custom folder and then navigate into the custom folder.
    Before you copy the certificates and keys, create the custom folder by using the mkdir command. The following example creates a custom folder in your home directory.
  10. $ mkdir ~/custom_folder/
    $ cp pki/ca.crt ~/custom_folder/
    $ cp pki/issued/server.crt ~/custom_folder/
    $ cp pki/private/server.key ~/custom_folder/
    $ cp pki/issued/client1.domain.tld.crt ~/custom_folder
    $ cp pki/private/client1.domain.tld.key ~/custom_folder/
    $ cd ~/custom_folder/
  11. Upload the server certificate and key to AWS Certificate Manager. Be sure to upload them in the same Region which in this example is ap-southeast-2 in which the Client VPN endpoint exists. The following commands use the AWS CLI to upload the certificates. To upload the certificates using the ACM console instead, see Import a certificate in the AWS Certificate Manager User Guide.
  12. $ aws acm import-certificate --certificate fileb://client-vpn.server.yourdomain.com.crt --private-key fileb://client-vpn.server.yourdomain.com.crt.key --certificate-chain fileb://ca.crt --profile aws-account-profile

To generate the client certificates and keys and provide them through to clients.

You do not necessarily need to upload the client certificate to ACM. If the server and client certificates have been issued by the same Certificate Authority (CA), you can use the server certificate ARN for both server and client when you create the Client VPN endpoint, which is what has been implemented in this example. However, the steps to upload the client certificate are included for completeness.

  1. Generate the client certificate and key.

    Make sure to save the client certificate and the client private key because you will need them when you configure the client.
  2. $ ./easyrsa build-client-full username.client-vpn.client.yourdomain.com nopass

    Optionally repeat this step for each client (end user) that requires a client certificate and key.

IAM Identity Centre Design and Configuration

Single Sign On (SSO) Federated Access is configured within the Master Payer Account where there are two applications created of which they must be configured with exact naming and configuration to work as expected.

Single Sign on Federation

  • SAML VPN Client
    • Display name: VPN Client
    • Application ACS URL: http://127.0.0.1:35001
    • Application SAML audience: urn:amazon:webservices:clientvpn
  • SAML VPN Client Self Service
    • Display name: VPN Client Self Service
    • Application ACS URL: https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml
    • Application SAML audience: urn:amazon:webservices:clientvpn

To manage access, a group is created which uses are added to when access is to be provisioned, this group is named “ClientVPN-App-Access” and is added to each of the applications created above.

Access Management to AWS Environments

The ability to manage what CIDRs users connecting into the Client VPN can interact with can be further locked down so that access to each account end points CIDR can be controlled with group access management. The group names can be specific to your environment.

All the groups in SSO IAM Identity Centre and are relatively self explanatory:

  • ClientVPN-<Environment>-Only - users added to any of these groups will have access to the specific CIDR endpoints for that environment
  • ClientVPN-All-Access - users added to this group will have access to all (0.0.0.0/0) CIDRs, which would evaluate to complete access to all systems.

If a finer grain of access be required to certain things within the environment, the architecture allows for extensibility across any sized CIDR based on requirements of the user requesting access. This could be particularly useful for access to SAML integrated applications such as Intranet sites for example.

IAM Identity Centre Groups Example

The following groups exist as examples for this solution.

Single Sign on Groups

Attribute Mappings for VPN Client

The following attribute mappings are required to be configured before the IAM Identity Center metadata is downloaded

Single Sign on VPN Client Attributes

Attribute Mappings for VPN Client

The following attribute mappings are required to be configured before the IAM Identity Center metadata is downloaded

Single Sign on VPN Client Self Service Attributes

Client VPN Configuration

Client VPN Details

Association is with a Management Zone and all three AZ’s for redundancy

Client VPN Target Network Associations

Security Group used of which it has association to the each Target Network Association, important to note that Ingress of the SG is access to the Client VPN and Egress is what those connections have access to back into the environment.

Client VPN Security Groups

Authorisation rules based on Group Access in SSO

Client VPN Authorisations

Routing back into the various environments

Client VPN Routing

Revoking Certificate Access

Through the Import client certificate CRL process, we can revoke access to certificates as well as through group membership in SSO revoke access to federation user access.

  • CRL’s are in PEM format which are generated using the following command:
  • $ ./easyrsa revoke client_certificate_name
    $ ./easyrsa gen-crl
Client VPN Revoke

Where to Next

Congratulations on successfully deploying your AWS Client VPN! You've taken a crucial step in enhancing your network security and providing remote access to your resources. As you continue to optimize and expand your solution, consider the following steps:

  • Network Monitoring and Optimization - Regularly monitor the performance of your AWS Client VPN to ensure optimal user experience. Utilize Amazon CloudWatch to track metrics and logs related to VPN usage, latency, and traffic patterns. Use this data to identify and address potential bottlenecks, ensuring a seamless remote access experience for your team.
  • Security Enhancements - Continue to strengthen the security of your VPN setup. Explore advanced authentication methods, such as multi-factor authentication (MFA), to add an extra layer of protection for VPN users. Regularly review and update your security groups, NACLs, and routing configurations to mitigate potential vulnerabilities.
  • Scaling for Growth If your organization is expanding or experiencing an increase in remote work, ensure your VPN solution can scale to accommodate the growing user base. Consider the use of AWS Transit Gateway for centralized VPN management and seamless scalability across multiple Amazon VPCs.
  • Integration with Other AWS Services - Leverage the AWS ecosystem to enhance your VPN solution's capabilities. Integrate with AWS Directory Service for simplified user authentication and management. Explore AWS CloudFormation templates for automated deployment and updates, saving time and reducing manual errors.
  • Disaster Recovery and Business Continuity - Plan for contingencies by implementing disaster recovery and business continuity strategies. Regularly back up your VPN configuration settings, and create a clear plan for rapidly restoring the VPN infrastructure in case of unexpected outages.
  • User Training and Support - Ensure that your VPN users are well-informed about how to use the VPN securely and efficiently. Provide training materials and resources to help them understand best practices, troubleshoot common issues, and make the most of the remote access capabilities.

By focusing on these areas, you'll not only optimize your current AWS Client VPN deployment but also lay the groundwork for a secure, scalable, and efficient remote access solution that aligns with your organization's evolving needs.

Note that the above solution is fully codified with native AWS services such as Lambda and Cloudformation so if you're keen for any of the code used in this solution or have questions reach out, its all written in Python mostly using available AWS modules though Lambda packaging can solve that dilemma.