Traditional on-premises VPN services are fixed in capacity and difficult to scale up, or down, in a rapid and on-demand fashion. Hardware constraints, licensing, and bandwidth can all be factors that prevent traditional client VPN services from scaling to meet the needs of a rapidly growing mobile workforce. Fortunately, the elasticity of cloud and pay-as-you-go pricing of AWS Client VPN can help. AWS Client VPN is a scalable and highly available OpenVPN based service that can be used to connect to both AWS and on-premises resources.

In this blog I expand on my previous post and discuss AWS Client VPN connectivity and architectures for remote worker connectivity to both cloud and on-premises resources.

Client connectivity

The AWS Client VPN service provides a scalable endpoint for your users to connect to. It is elastic and can expand to keep up with increased connections. By default, an endpoint can scale up to 2,000 concurrent connections. This limit can be increased much higher through a limit increase request in the support console. End users can authenticate to Client VPN using certificate-based mutual authentication or Active Directory authentication. Multi-factor authentication (MFA) can be enabled on Active Directory authentication for an additional layer of security.

The Client VPN endpoint attaches to one or more subnets per AZ. For high availability, at least two subnets are recommended. The attachment creates an elastic network interface (ENI) in the subnet. All of the network traffic from the client subnet is NATed (Network Address Translated) to the ENI IP address. This allows connected clients to use the subnet route table to connect to resources both inside and outside of the VPC.

Network access can be finely controlled through authorization and is locked down by default. Clients can additionally be configured for full-tunnel access, where all network traffic goes through Client VPN, or split-tunnel. One point to consider is that a sufficiently large subnet chosen for the VPN clients that does not overlap with the VPC CIDR. When sizing the Client VPN CIDR, be sure it can facilitate two times the number of concurrent connections. Remote worker connectivity is shown in the diagram below using 10.254.0.0/16 as the client subnet.

Architecture

Once a remote worker connects to the AWS Client VPN endpoint, they can reach any destination that the client VPN subnet has a route to (subject to an authorization allowing access). This enables access to resources within the VPC as well as resources in additional VPCs and on-premises.

Client VPN to many VPCs

Connected clients will already have a route to resource within the VPC. Since Client VPN is doing source NAT, client traffic has a source IP of the endpoint ENI. Resources like interface VPC endpoints and EC2 instances can connect seamlessly. VPC peering and AWS Transit Gateway can be used to connect to resources outside of the VPC. This is accomplished by adding routes to the Client VPN subnet route table. This architecture in shown in the following diagram.

Client VPN to on-premises

Client VPN allows remote workers to use AWS Direct Connect (DX) and AWS Site-to-Site VPN to connect to on-premises resources. In this fashion remote worker VPN capacity can scale independent of on-premises infrastructure and bandwidth. A single VPC can make use of a DX connection or VPN connection to a VPC. For a more scalable alternative, AWS Transit Gateway can be used to connect many VPCs together, as well as on-premises connectivity through Direct Connect gateway (with a transit virtual interface) or VPN. This architecture is shown below.

Client VPN to Internet

If a full VPN tunnel is used for client VPN connections, then internet traffic can use the subnet route table to route a default route of 0.0.0.0/0. Internet-bound traffic can use a NAT Gateway or third-party appliance. Multiple NAT Gateways or appliances can be used for high availability and scale. This is shown in the architecture below.

As an alternative, it is also possible to use the Client VPN ENIs for egress traffic to the internet. To accomplish this, all you need to use is a public subnet for the Client VPN attachment. Each ENI receives a public IP address and can provide internet access without any NAT Gateways and the associated charges. This architecture is shown below.

Conclusion

In this post I laid out several architectures that connect remote workers to VPC resources, the internet, and on-premises resources. These architectures can be combined and modified to meet your work from home requirements. AWS Client VPN makes it simple to create a scalable remote access solution to meet your work from home user needs.