AWS Client VPN connection and traffic flow handling simplified

Client connection Initiation and Authentication (Step 1)

Once a Client VPN Endpoint is created, a client configuration file is available to download. The Client VPN endpoint configuration file includes the DNS name of the Client VPN endpoint and authentication information required to establish a VPN session. The client is the end user who establishes the VPN session from their local computer or mobile device using the AWS provided client or another OpenVPN-based client application.

Once the Client initiates a connection, Client authentication serves as the initial step to ascertain whether the client is authorized to connect.

AWS Client VPN offers the following types of client authentication:

• Active Directory authentication (user-based)
• Mutual authentication (certificate-based)
• Single sign-on (SAML-based federated authentication) (user-based)

If authentication is successful, a secure SSL channel is established between the client's machine and the AWS Client VPN endpoint and an IP address is dynamically assigned to the client local machine's virtual adapter from the designated "Client IPv4 CIDR" address range.

The AWS Client VPN endpoint also pushes other configurations such as DNS and routing information to the client machine. Routing information depends on whether "Split-tunnel" is enabled or disabled. If enabled, all routes in the AWS Client VPN endpoint's route table are pushed to the client's local routing table. If disabled, a “0.0.0.0/0” route is pushed to the client's local routing table, making the Client VPN interface as default for all traffic from the local machine.

Traffic Flow

After the client connection is established, user can initiate traffic to the target resource through the established secure channel in encrypted format which gets decrypted at the Client VPN Endpoint.

Client Authorization (Step 2)

Client Authorization is the next step, where Network-based authorization is implemented using authorization rules. For each network that you want to enable access, you must configure authorization rules that limit the users who have access. This can either be for “all users” or specific users using “Access group ID”. User traffic is evaluated against these rules before proceeding to the next step.

Traffic Routing (Step 3)

Once clients are authorized, the traffic is routed to the appropriate "target network" or subnet. This routing process relies on the Client VPN Route table.

Note: If you are associating multiple subnets to the Client VPN endpoint, you should make sure to create a route for each subnet in such a way that each associated subnet should have an identical set of routes.

Security Group Rules (Step 4)

At this point, traffic reaches the elastic network interface (ENI) of the selected Target subnet to which the Client VPN Security Group is attached. Outbound rules of the associated security group are checked and these rules need to allow traffic to the destined resource (example: an EC2 instance, VPC CIDR etc.). Inbound rules are not checked as Security Groups are stateful in nature.

Network Address Translation (NAT) (Step 5)

An essential component of VPN traffic handling is Network Address Translation (NAT). The source IP address of traffic is NAT'ed to one of the Elastic Network Interface's private IPv4 addresses and this IP is used to connect to resources both inside the VPC and beyond. Hence, any Security Group, NACL, Firewall Rules at the destination should allow the NAT’ed IP of the Client.

Routing to Final Destination (Step 6)

The traffic is then routed to its final destination based on the Target Subnet’s Route table. It is therefore important to make sure that the Target subnet attached to the Client VPN Endpoint, has access to all the networks you want the clients/users to access.

Network ACL Rule (Step 7)

The Target subnet’s Network ACL rules are checked if traffic leaves the associated subnet. Hence, the network ACL's outbound rules need to allow traffic to the destination network you want to reach. Similarly, return traffic from the destination is checked against the inbound rules of the subnet NACL. This step is not checked if the destination resource is within the same subnet that is associated with the Client VPN.

Conclusion:

A well-orchestrated VPN network relies on a series of intricate processes to handle traffic securely. From client authorization to network-based access rules, traffic routing, security group rules, NAT, and NACLs, each step plays a vital role in ensuring the confidentiality, integrity, and availability of data.