AWS Client VPN overview

With a well-defined challenge at hand, it's time to delve into the distinct components comprising the AWS Client VPN service and explore their respective functionalities.

Endpoint(s)

Central to the architecture is a pivotal component: the Endpoint. Serving as the definitive point of culmination for all client VPN sessions, it seamlessly interfaces with Target Networks, notably exemplified by a VPC within our context. This association materializes through an assembly of network interfaces seamlessly integrated within the VPC framework. Illustrated in the diagram above, an Endpoint affixed to a VPC unlocks a multitude of connectivity avenues, facilitating interactions with an array of resources across both the associated and connected VPCs, as well as VPN sites.

Security Group(s)

Security Groups extend beyond their role within AWS Client VPN; they encompass a broader spectrum of functionalities and stand as foundational elements within AWS' networking security framework. This inherent versatility positions them as a compelling focal point for integration into Client VPN implementations. Integral to this synergy is the affiliation of a Security Group with each Endpoint network interface, endowing the capability to grant resource access contingent upon the parameters delineated by the Endpoint Security Group.

Client

The client is the piece of software running on the end-user computer that handles that side of the Client VPN connection. Amazon provides their own client software for Windows, MacOS and Ubuntu 20. For other operating systems the OpenVPN client for that operating system can be used. The Amazon client is a version of the OpenVPN client but then adapted by Amazon. When a ClientVPN Endpoint is set up a configuration file for the Endpoint can be downloaded. Which is part of the configuration needed to set up a connection between the Client and the Endpoint.

Authorization Rules

Authorization rules are rules tied to an Endpoint. These rules allow access to specific IP addresses or entire IP ranges. This is one of the access control mechanisms provided with AWS Client VPN.

Routes

Routes are the network routes advertised to a user who connects to an Endpoint. These routes in turn shape which VPCs or connected networks a user can access.

Authentication Methods

To connect the Client VPN with the Endpoitn in AWS multiple authentication methods are available to ensure that a user is a genuine user and should be allowed to connect to the Endpoint and in turn to AWS resources.

Active Directory Authentication

This authentication method integrates with the AWS Directory Service or AWS Active Directory Connector in case you have a self hosted Active directory. The authentication method supports logging in based on username and password or based on username, password and a mult-factor authentication (MFA) code.

Mutual Authentication

This authentication method involves server and client certificates uploaded to AWS Certificate Manager. The connecting user has to have access to the client certificate which allows the user to identify himself with the Endpoint. Client VPN allows the usage of a certificate for each user which can be revoked from the Client VPN console in AWS. This method proves particularly advantageous for users lacking an operating system that supports a compatible Client VPN client, a topic we'll delve into further shortly.

Single Sign on (SAML-based) authentication

The Single Sign on authentication method is used for this project. The method works with username and password authentication in the Client VPN client as well as confirmation by email or any of the other MFA methods available with your Security Assertion Markup Language (SAML) identity provider.

Challenges to overcome

So far the project seemed quite straightforward, however, there are some complicating factors:

• Short time to deliver: Unfortunately, the On-premises OpenVPN solution's license was set to expire in the near future at the beginning of the project.

• Complex routing needs: The customer has a lot of different VPCs with access requirements differing per user group. Furthermore, an Azure environment as well as some other on-premises locations are connected with the AWS infrastructure through site-to-site VPNs and a Transit Gateway.

• Role based access control: The request to add role based access control to the solution complicated matters. Normally, you would handle that by leveraging the authorization rules feature of Client VPN. Unfortunately, that would not work with the customer demands. Some resources for developers reside in VPCs where there are resources that should be available only to Administrators. Now you could add authorization rules based on single IP addresses and complete this requirement that way. That would, however, become difficult to manage in the long term, especially if IP addresses change. Thus, a different solution had to be found, in this case Security Groups. With each user group having their own Client VPN Endpoint we could assign each user group their own Security Group. In turn allowing access to resources to be restricted based on Security Groups. These resources usually do not reside in the networking (Hub) AWS account of the customer but rather in application specific Test, Staging or Prod accounts. Therefore VPC peerings had to be created between the networking account and other (Spoke) accounts allowing the usage of cross-account Security Groups.

• Client VPN operating system support: As previously highlighted, the ultimate design incorporates both Mutual Authentication and Single Sign-On authentication methods. This selection arises from the necessity to accommodate diverse user scenarios; notably, Ubuntu 22 users lack an available AWS Client VPN client, rendering Single Sign-On unviable. To address this, distinct Endpoints were established, featuring mutual authentication, exclusively tailored for these users. Notably, these dedicated Endpoints share a common Security Group with the SSO-enabled Endpoint catering to the remaining user group.

• Ongoing migration of IaC solution: During the initiation of this project, the customer's Infrastructure as Code (IaC) solution was concurrently undergoing migration to an alternative framework as part of a separate endeavor. The migration was moving from the CloudNation proprietary solution (DAF) towards Terraform. As a result most of the resources in the account where the Client VPN Endpoints are to be configured were still managed with the old solution whilst it would be inefficient to build the Client VPN with the old framework. So the Infrastructure code for this project end up being a combination of both frameworks with a focus on allowing easy integration with the new Terraform infrastructure code.

Final design

Now that both the project goals, Client VPN components and the challenges are covered, let’s have a look at the final design.

Multiple Endpoints

As elucidated earlier, a series of Endpoints were established to facilitate role-based access control, each uniquely linked to distinct Security Groups. While the diagram depicts them as a singular Endpoint, their individual significance cannot be understated. This distinction is pivotal, as these Endpoints are accompanied by dedicated Security Groups, affording the customer the capability to finely curate resource access through precise Security Group allowances. To enable the cross-account utilization of these Security Groups, the establishment of VPC peering connections between the Networking (Hub) account and all application (Spoke) accounts is imperative.

SAML and Mutual Authentication

Both the SAML based Single Sign On authentication method and the Mutual Authentication method with Client and Server certificates are implemented. Two Endpoints with Mutual Authentication for subgroups of users that are not able to use the Amazon provided Client VPN client. Four Endpoints with Single Sign On authentication. These are integrated with the AWS IAM identity Center (former AWS SSO) to allow signing in with the credentials users already have.

AWS Certificate Manager and Cloudwatch event rules

Each Endpoint has a Server Certificate which is used to prove to the client software that the Endpoint is indeed who it claims to be. These certificates have to be stored in the AWS Certificate Manager (ACM). For the users that authenticate with mutual authentication the client certificates are also stored in ACM.

To ensure that certificate expirations in the future will not cause problems a CloudWatch event rule has been set up that sends a notification to an SNS topic in case a certificate expiration event is noticed on the event bus of the networking account.

Conclusion

The implementation detailed in this blog has provided the developers at Diebold Nixdorf with a streamlined and highly secure avenue for connecting to their AWS Infrastructure. Simultaneously, administrators now possess enhanced security controls, empowering them to meticulously curate resource access, confining it solely to those who require it. Additionally, the newly devised solution seamlessly integrates with IAM Identity Center, simplifying the administration of user access.

Collectively, the project's outcome culminates in a satisfied customer benefiting from a solution that surpasses its predecessor in every aspect.