# How AWS Client VPN works With AWS Client VPN, there are two types of user personas that interact with the Client VPN endpoint: administrators and clients. Client VPN supports IPv4, IPv6, and dual-stack (both IPv4 and IPv6) connectivity. You can create endpoints that use IPv4, IPv6, or both, allowing you to connect to IPv6 resources in your VPCs or connect from clients on IPv6 networks. This flexibility helps organizations that have already implemented or are transitioning to IPv6 infrastructure. The *administrator* is responsible for setting up and configuring the service. This involves creating the Client VPN endpoint, associating the target network, configuring the authorization rules, and setting up additional routes (if required). After the Client VPN endpoint is set up and configured, the administrator downloads the Client VPN endpoint configuration file and distributes it to the clients who need access. The Client VPN endpoint configuration file includes the DNS name of the Client VPN endpoint and authentication information that's required to establish a VPN session. For more information about setting up the service, see [Get started with AWS Client VPN](cvpn-getting-started.md). The *client* is the end user. This is the person who connects to the Client VPN endpoint to establish a VPN session. The client establishes the VPN session from their local computer or mobile device using an OpenVPN-based VPN client application. After they have established the VPN session, they can securely access the resources in the VPC in which the associated subnet is located. They can also access other resources in AWS, an on-premises network, or other clients if the required route and authorization rules have been configured. For more information about connecting to a Client VPN endpoint to establish a VPN session, see [Getting Started](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/user-getting-started.html) in the *AWS Client VPN User Guide*. The following graphic illustrates the basic Client VPN architecture. ![\[Client VPN architecture\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/architecture.png) ## Scenarios and examples for Client VPN AWS Client VPN is a fully-managed remote access VPN solution that you use to allow clients secure access to resources within both AWS and your on-premises network. There are multiple options for how you configure access. This section provides examples for creating and configuring Client VPN access for your clients. **Scenarios** + [Access a VPC using Client VPN](#scenario-vpc) + [Access a peered VPC using Client VPN](#scenario-peered) + [Access an on-premises network using Client VPN](#scenario-onprem) + [Access the internet using Client VPN](#scenario-internet) + [Client-to-client access using Client VPN](#scenario-client-to-client) + [Restrict access to your network using Client VPN](#scenario-restrict) ### Access a VPC using Client VPN The AWS Client VPN configuration for this scenario includes a single target VPC. We recommend this configuration if you need to give clients access to the resources inside a single VPC only. ![\[Client VPN accessing a VPC\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-vpc.png) Before you begin, do the following: + Create or identify a VPC with at least one subnet. Identify the subnet in the VPC to associate with the Client VPN endpoint and note its IPv4 CIDR ranges. + Identify a suitable CIDR range for the client IP addresses that does not overlap with the VPC CIDR. + Review the rules and limitations for Client VPN endpoints in [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). **To implement this configuration** 1. Create a Client VPN endpoint in the same Region as the VPC. To do this, perform the steps described in [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Associate the subnet with the Client VPN endpoint. To do this, perform the steps described in [Associate a target network with an AWS Client VPN endpoint](cvpn-working-target-associate.md) and select the subnet and the VPC you identified earlier. 1. Add an authorization rule to give clients access to the VPC. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md), and for **Destination network**, enter the IPv4 CIDR range of the VPC. 1. Add a rule to your resources' security groups to allow traffic from the security group that was applied to the subnet association in step 2. For more information, see [Security groups](client-authorization.md#security-groups). ### Access a peered VPC using Client VPN The AWS Client VPN configuration for this scenario includes a target VPC (VPC A) that is peered with an additional VPC (VPC B). We recommend this configuration if you need to give clients access to the resources inside a target VPC and to other VPCs that are peered with it (such as VPC B). **Note** The procedure for allowing access to a peered VPC (outlined following the network diagram) is required only if the Client VPN endpoint was configured for split-tunnel mode. In full-tunnel mode, access to the peered VPC is allowed by default. ![\[Client VPN accessing a peer VPC\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-peer-vpc.png) Before you begin, do the following: + Create or identify a VPC with at least one subnet. Identify the subnet in the VPC to associate with the Client VPN endpoint and note its IPv4 CIDR ranges. + Identify a suitable CIDR range for the client IP addresses that does not overlap with the VPC CIDR. + Review the rules and limitations for Client VPN endpoints in [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). **To implement this configuration** 1. Establish the VPC peering connection between the VPCs. Follow the steps at [Creating and accepting a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) in the *Amazon VPC Peering Guide*. Confirm that instances in VPC A can communicate with instances in VPC B using the peering connection. 1. Create a Client VPN endpoint in the same Region as the target VPC. In the diagram, this is VPC A. Perform the steps described in [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Associate the subnet that you identified with the Client VPN endpoint that you created. To do this, perform the steps described in [Associate a target network with an AWS Client VPN endpoint](cvpn-working-target-associate.md), selecting the VPC and the subnet. By default, we associate the default security group of the VPC with the Client VPN endpoint. You can associate a different security group using the steps described in [Apply a security group to a target network in AWS Client VPN](cvpn-working-target-apply.md). 1. Add an authorization rule to give clients access to the target VPC. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md). For **Destination network to enable **, enter the IPv4 CIDR range of the VPC. 1. Add a route to direct traffic to the peered VPC. In the diagram, this is VPC B. To do this, perform the steps described in [Create an AWS Client VPN endpoint route](cvpn-working-routes-create.md). For **Route destination**, enter the IPv4 CIDR range of the peered VPC. For **Target VPC Subnet ID**, select the subnet you associated with the Client VPN endpoint. 1. Add an authorization rule to give clients access to peered VPC. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md). For **Destination network**, enter the IPv4 CIDR range of the peered VPC. 1. Add a rule to the security groups for your instances in VPC A and VPC B to allow traffic from the security group that was applied the Client VPN endpoint in step 3. For more information, see [Security groups](client-authorization.md#security-groups). ### Access an on-premises network using Client VPN The AWS Client VPN configuration for this scenario includes access to an on-premises network only. We recommend this configuration if you need to give clients access to the resources inside an on-premises network only. ![\[Client VPN accessing an on-premises network\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-on-premises.png) Before you begin, do the following: + Create or identify a VPC with at least one subnet. Identify the subnet in the VPC to associate with the Client VPN endpoint and note its IPv4 CIDR ranges. + Identify a suitable CIDR range for the client IP addresses that does not overlap with the VPC CIDR. + Review the rules and limitations for Client VPN endpoints in [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). **To implement this configuration** 1. Enable communication between the VPC and your own on-premises network over an AWS Site-to-Site VPN connection. To do this, perform the steps described in [Getting started](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html) in the *AWS Site-to-Site VPN User Guide*. **Note** Alternatively, you can implement this scenario by using an Direct Connect connection between your VPC and your on-premises network. For more information, see the [Direct Connect User Guide](https://docs.aws.amazon.com/directconnect/latest/UserGuide/). 1. Test the AWS Site-to-Site VPN connection you created in the previous step. To do this, perform the steps described in [Testing the Site-to-Site VPN connection](https://docs.aws.amazon.com/vpn/latest/s2svpn/HowToTestEndToEnd_Linux.html) in the *AWS Site-to-Site VPN User Guide*. If the VPN connection is functioning as expected, continue to the next step. 1. Create a Client VPN endpoint in the same Region as the VPC. To do this, perform the steps described in [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Associate the subnet that you identified earlier with the Client VPN endpoint. To do this, perform the steps described in [Associate a target network with an AWS Client VPN endpoint](cvpn-working-target-associate.md) and select the VPC and the subnet. 1. Add a route that allows access to the AWS Site-to-Site VPN connection. To do this, perform the steps described in [Create an AWS Client VPN endpoint route](cvpn-working-routes-create.md); for **Route destination**, enter the IPv4 CIDR range of the AWS Site-to-Site VPN connection, and for **Target VPC Subnet ID**, select the subnet you associated with the Client VPN endpoint. 1. Add an authorization rule to give clients access to the AWS Site-to-Site VPN connection. To do this, perform the steps described in [Add an authorization rule to an AWS Client VPN endpoint](cvpn-working-rule-authorize-add.md); for **Destination network**, enter the AWS Site-to-Site VPN connection IPv4 CIDR range. ### Access the internet using Client VPN The AWS Client VPN configuration for this scenario includes a single target VPC and access to the internet. We recommend this configuration if you need to give clients access to the resources inside a single target VPC and also allow access to the internet. If you completed the [Get started with AWS Client VPN](cvpn-getting-started.md) tutorial, then you've already implemented this scenario. ![\[Client VPN accessing the internet\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-igw.png) Before you begin, do the following: + Create or identify a VPC with at least one subnet. Identify the subnet in the VPC to associate with the Client VPN endpoint and note its IPv4 CIDR ranges. + Identify a suitable CIDR range for the client IP addresses that does not overlap with the VPC CIDR. + Review the rules and limitations for Client VPN endpoints in [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). **To implement this configuration** 1. Ensure that the security group that you'll use for the Client VPN endpoint allows outbound traffic to the internet. To do this, add outbound rules that allow traffic to 0.0.0.0/0 for HTTP and HTTPS traffic. 1. Create an internet gateway and attach it to your VPC. For more information, see [Creating and Attaching an Internet Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) in the *Amazon VPC User Guide*. 1. Make your subnet public by adding a route to the internet gateway to its route table. In the VPC console, choose **Subnets**, select the subnet you intend to associate with the Client VPN endpoint, choose **Route Table**, and then choose the route table ID. Choose **Actions**, choose **Edit routes**, and choose **Add route**. For **Destination**, enter `0.0.0.0/0`, and for **Target**, choose the internet gateway from the previous step. 1. Create a Client VPN endpoint in the same Region as the VPC. To do this, perform the steps described in [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Associate the subnet that you identified earlier with the Client VPN endpoint. To do this, perform the steps described in [Associate a target network with an AWS Client VPN endpoint](cvpn-working-target-associate.md) and select the VPC and the subnet. 1. Add an authorization rule to give clients access to the VPC. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md); and for **Destination network to enable **, enter the IPv4 CIDR range of the VPC. 1. Add a route that enables traffic to the internet. To do this, perform the steps described in [Create an AWS Client VPN endpoint route](cvpn-working-routes-create.md); for **Route destination**, enter `0.0.0.0/0`, and for **Target VPC Subnet ID**, select the subnet you associated with the Client VPN endpoint. 1. Add an authorization rule to give clients access to the internet. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md); for **Destination network**, enter `0.0.0.0/0`. 1. Ensure that the security groups for the resources in your VPC have a rule that allows access from the security group associated with the Client VPN endpoint. This enables your clients to access the resources in your VPC. ### Client-to-client access using Client VPN The AWS Client VPN configuration for this scenario enables clients to access a single VPC, and enables clients to route traffic to each other. We recommend this configuration if the clients that connect to the same Client VPN endpoint also need to communicate with each other. Clients can communicate with each other using the unique IP address that's assigned to them from the client CIDR range when they connect to the Client VPN endpoint. ![\[Client-to-client access\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-client-to-client.png) Before you begin, do the following: + Create or identify a VPC with at least one subnet. Identify the subnet in the VPC to associate with the Client VPN endpoint and note its IPv4 CIDR ranges. + Identify a suitable CIDR range for the client IP addresses that does not overlap with the VPC CIDR. + Review the rules and limitations for Client VPN endpoints in [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). **Note** Network-based authorization rules using Active Directory groups or SAML-based IdP groups are not supported in this scenario. **To implement this configuration** 1. Create a Client VPN endpoint in the same Region as the VPC. To do this, perform the steps described in [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Associate the subnet that you identified earlier with the Client VPN endpoint. To do this, perform the steps described in [Associate a target network with an AWS Client VPN endpoint](cvpn-working-target-associate.md) and select the VPC and the subnet. 1. Add a route to the local network in the route table. To do this, perform the steps described in [Create an AWS Client VPN endpoint route](cvpn-working-routes-create.md). For **Route destination**, enter the client CIDR range, and for **Target VPC Subnet ID**, specify `local`. 1. Add an authorization rule to give clients access to the VPC. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md). For **Destination network to enable **, enter the IPv4 CIDR range of the VPC. 1. Add an authorization rule to give clients access to the client CIDR range. To do this, perform the steps described in [Add an authorization rule](cvpn-working-rule-authorize-add.md). For **Destination network to enable**, enter the client CIDR range. ### Restrict access to your network using Client VPN You can configure your AWS Client VPN endpoint to restrict access to specific resources in your VPC. For user-based authentication, you can also restrict access to parts of your network, based on the user group that accesses the Client VPN endpoint. #### Restrict access using security groups You can grant or deny access to specific resources in your VPC by adding or removing security group rules that reference the security group that was applied to the target network association (the Client VPN security group). This configuration expands on the scenario described in [Access a VPC using Client VPN](#scenario-vpc). This configuration is applied in addition to the authorization rule configured in that scenario. To grant access to a specific resource, identify the security group that's associated with the instance on which your resource is running. Then, create a rule that allows traffic from the Client VPN security group. In the following diagram, security group A is the Client VPN security group, security group B is associated with an EC2 instance, and security group C is associated with an EC2 instance. If you add a rule to security group B that allows access from security group A, then clients can access the instance associated with security group B. If security group C does not have a rule that allows access from security group A, then clients can't access the instance associated with security group C. ![\[Restricting access to resources in a VPC\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-scenario-security-groups.png) Before you begin, check if the Client VPN security group is associated with other resources in your VPC. If you add or remove rules that reference the Client VPN security group, you might grant or deny access for the other associated resources too. To prevent this, use a security group that is specifically created for use with your Client VPN endpoint. **To create a security group rule** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Choose the security group that's associated with the instance on which your resource is running. 1. Choose **Actions**, **Edit inbound rules**. 1. Choose **Add rule**, and then do the following: + For **Type**, choose **All traffic**, or a specific type of traffic that you want to allow. + For **Source**, choose **Custom**, and then enter or choose the ID of the Client VPN security group. 1. Choose **Save rules** To remove access to a specific resource, check the security group that's associated with the instance on which your resource is running. If there is a rule that allows traffic from the Client VPN security group, delete it. **To check your security group rules** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Choose **Inbound Rules**. 1. Review the list of rules. If there is a rule where **Source** is the Client VPN security group, choose **Edit Rules**, and choose **Delete** (the x icon) for the rule. Choose **Save rules**. #### Restrict access based on user groups If your Client VPN endpoint is configured for user-based authentication, you can grant specific groups of users access to specific parts of your network. To do this, complete the following steps: 1. Configure users and groups in Directory Service or your IdP. For more information, see the following topics: + [Active Directory authentication in Client VPN](ad.md) + [Requirements and considerations for SAML-based federated authentication](federated-authentication.md#saml-requirements) 1. Create an authorization rule for your Client VPN endpoint that allows a specified group access to all or part of your network. For more information, see [AWS Client VPN authorization rules](cvpn-working-rules.md). If your Client VPN endpoint is configured for mutual authentication, you cannot configure user groups. When you create an authorization rule, you must grant access to all users. To enable specific groups of users access to specific parts of your network, you can create multiple Client VPN endpoints. For example, for each group of users that accesses your network, do the following: 1. Create a set of server and client certificates and keys for that group of users. For more information, see [Mutual authentication in AWS Client VPN](mutual.md). 1. Create a Client VPN endpoint. For more information, see [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Create an authorization rule that grants access to all or part of your network. For example, for a Client VPN endpoint that is used by administrators, you might create an authorization rule that grants access to the entire network. For more information, see [Add an authorization rule](cvpn-working-rule-authorize-add.md). # Client authentication in AWS Client VPN Client authentication is implemented at the first point of entry into the AWS Cloud. It is used to determine whether clients are allowed to connect to the Client VPN endpoint. If authentication succeeds, clients connect to the Client VPN endpoint and establish a VPN session. If authentication fails, the connection is denied and the client is prevented from establishing a VPN session. Client VPN offers the following types of client authentication: + [Active Directory authentication](ad.md) (user-based) + [Mutual authentication](mutual.md) (certificate-based) + [Single sign-on (SAML-based federated authentication)](federated-authentication.md) (user-based) You can use one of the preceding methods alone, or you can use a combination of mutual authentication with a user-based method such as the following: + Mutual authentication and federated authentication + Mutual authentication and Active Directory authentication **Important** To create a Client VPN endpoint, you must provision a server certificate in AWS Certificate Manager, regardless of the type of authentication that you use. For more information about creating and provisioning a server certificate, see the steps in [Mutual authentication in AWS Client VPN](mutual.md). If you use a combination of mutual authentication and user-based authentication, both methods must then be used to correctly authenticate in VPN. # Active Directory authentication in Client VPN Client VPN provides Active Directory support by integrating with Directory Service. With Active Directory authentication, clients are authenticated against existing Active Directory groups. Using Directory Service, Client VPN can connect to existing Active Directories provisioned in AWS or in your on-premises network. This allows you to use your existing client authentication infrastructure. If you are using an on-premises Active Directory and you do not have an existing AWS Managed Microsoft AD, you must configure an Active Directory Connector (AD Connector). You can use one Active Directory server to authenticate the users. For more information about Active Directory integration, see the [AWS Directory Service Administration Guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/). Client VPN supports multi-factor authentication (MFA) when it's enabled for AWS Managed Microsoft AD or AD Connector. If MFA is enabled, clients must enter a user name, password, and MFA code when they connect to a Client VPN endpoint. For more information about enabling MFA, see [Enable Multi-Factor Authentication for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html) and [Enable Multi-Factor Authentication for AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_mfa.html) in the *AWS Directory Service Administration Guide*. For quotas and rules for configuring users and groups in Active Directory, see [Users and groups quotas](limits.md#quotas-users-groups). # Mutual authentication in AWS Client VPN 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. You must upload the server certificate to AWS Certificate Manager (ACM) and specify it when you create a Client VPN endpoint. When you upload the server certificate to ACM, you also specify the certificate authority (CA). You only need to upload the client certificate to ACM when the CA of the client certificate is different from the CA of the server certificate. For more information about ACM, see the [AWS Certificate Manager User Guide](https://docs.aws.amazon.com/acm/latest/userguide/). You can create a separate client certificate and key for each client that will connect to the Client VPN endpoint. This enables you to revoke a specific client certificate if a user leaves your organization. In this case, when you create the Client VPN endpoint, you can specify the server certificate ARN for the client certificate, provided that the client certificate has been issued by the same CA as the server certificate. Certificates used in AWS Client VPN must adhere to [RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://datatracker.ietf.org/doc/html/rfc5280), including the Certificate Extensions specified in section 4.2 of the memo. **Note** A Client VPN endpoint supports 1024-bit and 2048-bit RSA key sizes only. Also, the client certificate must have the CN attribute in the Subject field. When certificates being used with the Client VPN service are updated, whether through ACM auto-rotation, manually importing a new certificate, or metadata updates to IAM Identity Center the Client VPN service will automatically update theClient VPN endpoint with the newer certificate. This is an automated process that can take up to 5 hours. **Topics** + [Enable mutual authentication](client-auth-mutual-enable.md) + [Renew your server certificate](mutual-renew.md) # Enable mutual authentication for AWS Client VPN You can enable mutual authentication in Client VPN in either Linux/MacOS or Windows. ------ #### [ Linux/macOS ] The following procedure uses OpenVPN easy-rsa to generate the server and client certificates and keys, and then uploads the server certificate and key to ACM. For more information, see the [Easy-RSA 3 Quickstart README](https://github.com/OpenVPN/easy-rsa/blob/v3.0.6/README.quickstart.md). **To generate the server and client 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. ``` $ git clone https://github.com/OpenVPN/easy-rsa.git ``` ``` $ cd easy-rsa/easyrsa3 ``` 1. Initialize a new PKI environment. ``` $ ./easyrsa init-pki ``` 1. To build a new certificate authority (CA), run this command and follow the prompts. ``` $ ./easyrsa build-ca nopass ``` 1. Generate the server certificate and key. ``` $ ./easyrsa --san=DNS:server build-server-full server nopass ``` 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. ``` $ ./easyrsa build-client-full client1.domain.tld nopass ``` You can optionally repeat this step for each client (end user) that requires a client certificate and key. 1. Copy the server certificate and key and the client 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. ``` $ 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/ ``` 1. Upload the server certificate and key and the client certificate and key to ACM. Be sure to upload them in the same Region in which you intend to create the Client VPN endpoint. The following commands use the AWS CLI to upload the certificates. To upload the certificates using the ACM console instead, see [Import a certificate](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html) in the *AWS Certificate Manager User Guide*. ``` $ aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt ``` ``` $ aws acm import-certificate --certificate fileb://client1.domain.tld.crt --private-key fileb://client1.domain.tld.key --certificate-chain fileb://ca.crt ``` 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. In the steps above, the same CA has been used to create both certificates. However, the steps to upload the client certificate are included for completeness. ------ #### [ Windows ] The following procedure installs Easy-RSA 3.x software and uses it to generate server and client certificates and keys. **To generate server and client certificates and keys and upload them to ACM** 1. Open the [EasyRSA releases](https://github.com/OpenVPN/easy-rsa/releases) page and download the ZIP file for your version of Windows and extract it. 1. Open a command prompt and navigate to the location that the `EasyRSA-3.x` folder was extracted to. 1. Run the following command to open the EasyRSA 3 shell. ``` C:\Program Files\EasyRSA-3.x> .\EasyRSA-Start.bat ``` 1. Initialize a new PKI environment. ``` # ./easyrsa init-pki ``` 1. To build a new certificate authority (CA), run this command and follow the prompts. ``` # ./easyrsa build-ca nopass ``` 1. Generate the server certificate and key. ``` # ./easyrsa --san=DNS:server build-server-full server nopass ``` 1. Generate the client certificate and key. ``` # ./easyrsa build-client-full client1.domain.tld nopass ``` You can optionally repeat this step for each client (end user) that requires a client certificate and key. 1. Exit the EasyRSA 3 shell. ``` # exit ``` 1. Copy the server certificate and key and the client 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 C:\$1 drive. ``` C:\Program Files\EasyRSA-3.x> mkdir C:\custom_folder C:\Program Files\EasyRSA-3.x> copy pki\ca.crt C:\custom_folder C:\Program Files\EasyRSA-3.x> copy pki\issued\server.crt C:\custom_folder C:\Program Files\EasyRSA-3.x> copy pki\private\server.key C:\custom_folder C:\Program Files\EasyRSA-3.x> copy pki\issued\client1.domain.tld.crt C:\custom_folder C:\Program Files\EasyRSA-3.x> copy pki\private\client1.domain.tld.key C:\custom_folder C:\Program Files\EasyRSA-3.x> cd C:\custom_folder ``` 1. Upload the server certificate and key and the client certificate and key to ACM. Be sure to upload them in the same Region in which you intend to create the Client VPN endpoint. The following commands use the AWS CLI to upload the certificates. To upload the certificates using the ACM console instead, see [Import a certificate](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html) in the *AWS Certificate Manager User Guide*. ``` aws acm import-certificate \ --certificate fileb://server.crt \ --private-key fileb://server.key \ --certificate-chain fileb://ca.crt ``` ``` aws acm import-certificate \ --certificate fileb://client1.domain.tld.crt \ --private-key fileb://client1.domain.tld.key \ --certificate-chain fileb://ca.crt ``` 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. In the steps above, the same CA has been used to create both certificates. However, the steps to upload the client certificate are included for completeness. ------ # Renew your server certificate for AWS Client VPN You can renew and re-import a Client VPN server certificate that has expired. Depending on the version of OpenVPN easy-rsa that you're using, the procedure will vary. See [Easy-RSA 3 Certificate Renewal and Revocation Documentation](https://github.com/OpenVPN/easy-rsa/blob/master/doc/EasyRSA-Renew-and-Revoke.md) for more details. **To renew your server certificate** 1. Do **one** of the following: + Easy-RSA version 3.1.x 1. Run the certificate renew command. ``` $ ./easyrsa renew server nopass ``` + Easy-RSA version 3.2.x 1. Run the expire command. ``` $ ./easyrsa expire server ``` 1. Sign a new certificate. ``` $ ./easyrsa --san=DNS:server sign-req server server ``` 1. Create a custom folder, copy the new files to it, then navigate into the folder. ``` $ mkdir ~/custom_folder2 $ cp pki/ca.crt ~/custom_folder2/ $ cp pki/issued/server.crt ~/custom_folder2/ $ cp pki/private/server.key ~/custom_folder2/ $ cd ~/custom_folder2/ ``` 1. Import the new files to ACM. Be sure to import them in the same Region as the Client VPN endpoint. ``` $ aws acm import-certificate \ --certificate fileb://server.crt \ --private-key fileb://server.key \ --certificate-chain fileb://ca.crt \ --certificate-arn arn:aws:acm:region:123456789012:certificate/12345678-1234-1234-1234-12345678901 ``` # Single sign-on — SAML 2.0-based federated authentication — in Client VPN AWS Client VPN supports identity federation with Security Assertion Markup Language 2.0 (SAML 2.0) for Client VPN endpoints. You can use identity providers (IdPs) that support SAML 2.0 to create centralized user identities. You can then configure a Client VPN endpoint to use SAML-based federated authentication, and associate it with the IdP. Users then connect to the Client VPN endpoint using their centralized credentials. **Topics** + [Enable SAML](client-auth-enable-saml.md) + [ ## Authentication workflow ](#federated-authentication-workflow) + [ ## Requirements and considerations for SAML-based federated authentication ](#saml-requirements) + [ ## SAML-based IdP configuration resources ](#saml-config-resources) # Enable SAML for AWS Client VPN You can enable SAML for single sign-on for Client VPN by completing the following steps. Alternatively, if you enabled the self-service portal for your Client VPN endpoint, instruct your users to go to the self-service portal to get the configuration file and AWS provided client. For more information, see [AWS Client VPN access to the self-service portal](cvpn-self-service-portal.md). **To enable your SAML-based IdP to work with a Client VPN endpoint, you must do the following.** 1. Create a SAML-based app in your chosen IdP to use with AWS Client VPN, or use an existing app. 1. Configure your IdP to establish a trust relationship with AWS. For resources, see [SAML-based IdP configuration resources](federated-authentication.md#saml-config-resources). 1. In your IdP, generate and download a federation metadata document that describes your organization as an IdP. This signed XML document is used to establish the trust relationship between AWS and the IdP. 1. Create an IAM SAML identity provider in the same AWS account as the Client VPN endpoint. The IAM SAML identity provider defines your organization's IdP to AWS trust relationship using the metadata document generated by the IdP. For more information, see [Creating IAM SAML Identity Providers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) in the *IAM User Guide*. If you later update the app configuration in the IdP, generate a new metadata document and update your IAM SAML identity provider. **Note** You do not need to create an IAM role to use the IAM SAML identity provider. 1. Create a Client VPN endpoint. Specify federated authentication as the authentication type, and specify the IAM SAML identity provider that you created. For more information, see [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md). 1. Export the [client configuration file](cvpn-working-endpoint-export.md) and distribute it to your users. Instruct your users to download the latest version of the [AWS provided client](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html), and to use it to load the configuration file and connect to the Client VPN endpoint. ## Authentication workflow The following diagram provides an overview of the authentication workflow for a Client VPN endpoint that uses SAML-based federated authentication. When you create and configure the Client VPN endpoint, you specify the IAM SAML identity provider. ![\[Authentication workflow\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/federated-auth-workflow.png) 1. The user opens the AWS provided client on their device and initiates a connection to the Client VPN endpoint. 1. The Client VPN endpoint sends an IdP URL and authentication request back to the client, based on the information that was provided in the IAM SAML identity provider. 1. The AWS provided client opens a new browser window on the user's device. The browser makes a request to the IdP and displays a login page. 1. The user enters their credentials on the login page, and the IdP sends a signed SAML assertion back to the client. 1. The AWS provided client sends the SAML assertion to the Client VPN endpoint. 1. The Client VPN endpoint validates the assertion and either allows or denies access to the user. ## Requirements and considerations for SAML-based federated authentication The following are the requirements and considerations for SAML-based federated authentication. + For quotas and rules for configuring users and groups in a SAML-based IdP, see [Users and groups quotas](limits.md#quotas-users-groups). + The SAML assertion and response must be signed. + AWS Client VPN only supports "AudienceRestriction" and "NotBefore and NotOnOrAfter" conditions in SAML assertions. + The maximum supported size for SAML responses is 128 KB. + AWS Client VPN does not provide signed authentication requests. + SAML single logout is not supported. Users can log out by disconnecting from the AWS provided client, or you can [terminate the connections](cvpn-working-connections-disassociate.md). + A Client VPN endpoint supports a single IdP only. + Multi-factor authentication (MFA) is supported when it's enabled in your IdP. + Users must use the AWS provided client to connect to the Client VPN endpoint. They must use version 1.2.0 or later. For more information, see [Connect using the AWS provided client](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html). + The following browsers are supported for IdP authentication: Apple Safari, Google Chrome, Microsoft Edge, and Mozilla Firefox. + The AWS provided client reserves TCP port 35001 on users' devices for the SAML response. + If the metadata document for the IAM SAML identity provider is updated with an incorrect or malicious URL, this can cause authentication issues for users, or result in phishing attacks. Therefore, we recommend that you use AWS CloudTrail to monitor updates that are made to the IAM SAML identity provider. For more information, see [Logging IAM and AWS STS calls with AWS CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html) in the *IAM User Guide*. + AWS Client VPN sends an AuthN request to the IdP via an HTTP Redirect binding. Therefore, the IdP should support HTTP Redirect binding and it should be present in the IdP's metadata document. + For the SAML assertion, you must use an email address format for the `NameID` attribute. + The maximum username (`NameID`) length is 1024 bytes. Connections with longer usernames will be rejected. + When certificates being used with the Client VPN service are updated, whether through ACM auto-rotation, manually importing a new certificate, or metadata updates to IAM Identity Center the Client VPN service will automatically update the Client VPN endpoint with the newer certificate. This is an automated process that can take up to 5 hours. ## SAML-based IdP configuration resources The following table lists the SAML-based IdPs that we have tested for use with AWS Client VPN, and resources that can help you configure the IdP. | IdP | Resource | | --- | --- | | Okta | [Authenticate AWS Client VPN users with SAML](https://aws.amazon.com/blogs/networking-and-content-delivery/authenticate-aws-client-vpn-users-with-saml/) | | Microsoft Entra ID (formerly Azure Active Directory) | For more information, see [Tutorial: Microsoft Entra single sign-on (SSO) integration with AWS ClientVPN](https://learn.microsoft.com/en-gb/entra/identity/saas-apps/aws-clientvpn-tutorial) on the Microsoft documentation website. | | JumpCloud | [Integrate with AWS Client VPN](https://jumpcloud.com/support/integrate-with-aws-client-vpn) | | AWS IAM Identity Center | [Using IAM Identity Center with AWS Client VPN for authentication and authorization](https://aws.amazon.com/blogs/networking-and-content-delivery/using-aws-sso-with-aws-client-vpn-for-authentication-and-authorization/) | ### Service provider information for creating an app To create a SAML-based app using an IdP that is not listed in the preceding table, use the following information to configure the AWS Client VPN service provider information. + Assertion Consumer Service (ACS) URL: `http://127.0.0.1:35001` + Audience URI: `urn:amazon:webservices:clientvpn` At least one attribute must be included in the SAML response from the IdP. The following are example attributes. | Attribute | Description | | --- | --- | | FirstName | The first name of the user. | | LastName | The last name of the user. | | memberOf | The group or groups that the user belongs to. | **Note** The `memberOf` attribute is required for using Active Directory or SAML IdP group-based authorization rules. It is also case-sensitive, and must be configured exactly as specified. See [Network-based authorization](client-authorization.md#auth-rules) and [AWS Client VPN authorization rules](cvpn-working-rules.md) for more information. ### Support for the self-service portal If you enable the self-service portal for your Client VPN endpoint, users log into the portal using their SAML-based IdP credentials. If your IdP supports multiple Assertion Consumer Service (ACS) URLs, add the following ACS URL to your app. ``` https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml ``` If you are using the Client VPN endpoint in a GovCloud region, use the following ACS URL instead. If you use the same IDP app to authenticate for both standard and GovCloud regions, you can add both URLs. ``` https://gov.self-service.clientvpn.amazonaws.com/api/auth/sso/saml ``` If your IdP does not support multiple ACS URLs, do the following: 1. Create an additional SAML-based app in your IdP and specify the following ACS URL. ``` https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml ``` 1. Generate and download a federation metadata document. 1. Create an IAM SAML identity provider in the same AWS account as the Client VPN endpoint. For more information, see [Creating IAM SAML Identity Providers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) in the *IAM User Guide*. **Note** You create this IAM SAML identity provider in addition to the one you [create for the main app](#federated-authentication). 1. [Create the Client VPN endpoint](cvpn-working-endpoint-create.md), and specify both of the IAM SAML identity providers that you created. # Client authorization in AWS Client VPN Client VPN supports two types of client authorization: security groups and network-based authorization (using authorization rules). ## Security groups When you create a Client VPN endpoint, you can specify the security groups from a specific VPC to apply to the Client VPN endpoint. When you associate a subnet with a Client VPN endpoint, we automatically apply the VPC's default security group. You can change the security groups after you create the Client VPN endpoint. For more information, see [Apply a security group to a target network in AWS Client VPN](cvpn-working-target-apply.md). The security groups are associated with the Client VPN network interfaces. You can enable Client VPN users to access your applications in a VPC by adding a rule to your applications' security groups to allow traffic from the security group that was applied to the association. Conversely, you can restrict access for Client VPN users by not specifying the security group that was applied to the association, or by removing the rule that references the Client VPN endpoint security group. The security group rules that you require might also depend on the kind of VPN access that you want to configure. For more information, see [Scenarios and examples for Client VPN](how-it-works.md#scenario). For more information about security groups, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon VPC User Guide*. ## Network-based authorization 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. For a specified network, you configure the Active Directory group or the SAML-based IdP group that is allowed access. Only users who belong to the specified group can access the specified network. If you are not using Active Directory or SAML-based federated authentication, or you want to open access to all users, you can specify a rule that grants access to all clients. For more information, see [AWS Client VPN authorization rules](cvpn-working-rules.md). **Topics** + [ ## Security groups ](#security-groups) + [ ## Network-based authorization ](#auth-rules) + [Create an endpoint security group rule](client-auth-rule-create.md) # Create an AWS Client VPN endpoint security group rule The default security group for the VPC applied when you associate a subnet with a Client VPN might restrict traffic from the default security group traffic that you want to allow, while simultaneously allowing traffic that you don't want. Use the following steps to create a Client VPN endpoint security group rule that either allows or restricts traffic for an endpoint security group associated with a resource or application. For more information about security group rules, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon VPC User Guide*. **To add a rule that allows traffic from the Client VPN endpoint security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Security Groups**. 1. Choose the security group that's associated with your resource or application, and choose **Actions**, **Edit inbound rules**. 1. Choose **Add rule**. 1. For **Type**, choose **All traffic**. Alternatively, you can restrict access to a specific type of traffic, for example, **SSH**. For **Source**, specify the ID of the security group that's associated with the target network (subnet) for the Client VPN endpoint. 1. Choose **Save rules**. # Connection authorization in AWS Client VPN You can configure a *client connect handler* for your Client VPN endpoint. The handler enables you to run custom logic that authorizes a new connection, based on device, user, and connection attributes. The client connect handler runs after the Client VPN service has authenticated the device and user. To configure a client connect handler for your Client VPN endpoint, create an AWS Lambda function that takes device, user, and connection attributes as inputs, and returns a decision to the Client VPN service to allow or deny a new connection. You specify the Lambda function in your Client VPN endpoint. When devices connect to your Client VPN endpoint, the Client VPN service invokes the Lambda function on your behalf. Only connections that are authorized by the Lambda function are allowed to connect to the Client VPN endpoint. **Note** Currently, the only type of client connect handler that is supported is a Lambda function. ## Requirements and considerations The following are the requirements and considerations for the client connect handler: + The name of the Lambda function must begin with the `AWSClientVPN-` prefix. + Qualified Lambda functions are supported. + The Lambda function must be in the same AWS Region and the same AWS account as the Client VPN endpoint. + The Lambda function times out after 30 seconds. This value cannot be changed. + The Lambda function is invoked synchronously. It's invoked after device and user authentication, and before the authorization rules are evaluated. + If the Lambda function is invoked for a new connection and the Client VPN service does not get an expected response from the function, the Client VPN service denies the connection request. For example, this can occur if the Lambda function is throttled, times out, or encounters other unexpected errors, or if the function's response is not in a valid format. + We recommend that you configure [provisioned concurrency](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) for the Lambda function to enable it to scale without fluctuations in latency. + If you update your Lambda function, existing connections to the Client VPN endpoint are not affected. You can terminate the existing connections, and then instruct your clients to establish new connections. For more information, see [Terminate an AWS Client VPN client connectionTerminate a client connection](cvpn-working-connections-disassociate.md). + If clients use the AWS provided client to connect to the Client VPN endpoint, they must use version 1.2.6 or later for Windows, and version 1.2.4 or later for macOS. For more information, see [Connect using the AWS provided client](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/connect-aws-client-vpn-connect.html). ## Lambda interface The Lambda function takes device attributes, user attributes, and connection attributes as inputs from the Client VPN service. It must then return a decision to the Client VPN service whether to allow or deny the connection. **Request schema** The Lambda function takes a JSON blob containing the following fields as input. ``` { "connection-id": , "endpoint-id": , "common-name": , "username": , "platform": , "platform-version": , "public-ip": , "client-openvpn-version": , "aws-client-version": , "groups": , "schema-version": "v3" } ``` + `connection-id` — The ID of the client connection to the Client VPN endpoint. + `endpoint-id` — The ID of the Client VPN endpoint. + `common-name` — The device identifier. In the client certificate that you create for the device, the common name uniquely identifies the device. + `username` — The user identifier, if applicable. For Active Directory authentication, this is the user name. For SAML-based federated authentication, this is `NameID`. For mutual authentication, this field is empty. + `platform` — The client operating system platform. + `platform-version` — The version of the operating system. The Client VPN service provides a value when the `--push-peer-info` directive is present in the OpenVPN client configuration when clients connect to a Client VPN endpoint, and when the client is running the Windows platform. + `public-ip` — The public IP address of the connecting device. + `client-openvpn-version` — The OpenVPN version that the client is using. + `aws-client-version` — The AWS client version. + `groups` — The group identifier, if applicable. For Active Directory authentication, this will be a list of Active Directory groups. For SAML-based federated authentication, this will be a list of identity provider (IdP) groups. For mutual authentication, this field is empty. + `schema-version` — The schema version. The default is `v3`. **Response schema** The Lambda function must return the following fields. ``` { "allow": boolean, "error-msg-on-denied-connection": "", "posture-compliance-statuses": [], "schema-version": "v3" } ``` + `allow` — Required. A boolean (`true` \$1 `false`) that indicates whether to allow or deny the new connection. + `error-msg-on-denied-connection` — Required. A string of up to 255 characters that can be used to provide steps and guidance to clients if the connection is denied by the Lambda function. In the event of failures during the running of the Lambda function (for example, due to throttling) the following default message is returned to clients by the Client VPN service. ``` Error establishing connection. Please contact your administrator. ``` + `posture-compliance-statuses` — Required. If you use the Lambda function for [posture assessment](#connection-authorization-posture-assessment), this is a list of statuses for the connecting device. You define the status names according to your posture assessment categories for devices, for example, `compliant`, `quarantined`, `unknown`, and so on. Each name can be up to 255 characters in length. You can specify up to 10 statuses. + `schema-version` — Required. The schema version. The default is `v3`. You can use the same Lambda function for multiple Client VPN endpoints in the same Region. For more information about creating a Lambda function, see [Getting started with AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) in the *AWS Lambda Developer Guide*. ## Use the client connect handler for posture assessment You can use the client connect handler to integrate your Client VPN endpoint with your existing device management solution to evaluate the posture compliance of connecting devices. For the Lambda function to work as a device authorization handler, use [mutual authentication](mutual.md) for your Client VPN endpoint. Create a unique client certificate and key for each client (device) that will connect to the Client VPN endpoint. The Lambda function can use the unique common name for the client certificate (that's passed from the Client VPN service) to identify the device and fetch its posture compliance status from your device management solution. You can use mutual authentication combined with user-based authentication. Alternatively, you can do a basic posture assessment in the Lambda function itself. For example, you can assess the `platform` and `platform-version` fields that are passed to the Lambda function by the Client VPN service. **Note** While the connection handler can be used to enforce a minimum AWS Client VPN application version, the field `aws-client-version` in the connection handler, is only applicable to the AWS Client VPN application and is being populated from environment variables on the user device. ## Enable the client connect handler To enable the client connect handler, create or modify a Client VPN endpoint and specify the Amazon Resource Name (ARN) of the Lambda function. For more information, see [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md) and [Modify an AWS Client VPN endpoint](cvpn-working-endpoint-modify.md). ## Service-linked role AWS Client VPN automatically creates a service-linked role in your account called **AWSServiceRoleForClientVPNConnections**. The role has permissions to invoke the Lambda function when a connection is made to the Client VPN endpoint. For more information, see [Using service-linked roles for AWS Client VPN](using-service-linked-roles.md). ## Monitor connection authorization failures You can view the connection authorization status of connections to the Client VPN endpoint. For more information, see [View AWS Client VPN client connectionsView client connections](cvpn-working-connections-view.md). When the client connect handler is used for posture assessment, you can also view the posture compliance statuses of devices that connect to your Client VPN endpoint in the connection logs. For more information, see [Connection logging for an AWS Client VPN endpoint](connection-logging.md). If a device fails connection authorization, the `connection-attempt-failure-reason` field in the connection logs returns one of the following failure reasons: + `client-connect-failed` — The Lambda function prevented the connection from being established. + `client-connect-handler-timed-out` — The Lambda function timed out. + `client-connect-handler-other-execution-error` — The Lambda function encountered an unexpected error. + `client-connect-handler-throttled` — The Lambda function was throttled. + `client-connect-handler-invalid-response` — The Lambda function returned a response that was not valid. + `client-connect-handler-service-error` — There was a service-side error during the connection attempt. # Split-tunnel on AWS Client VPN endpoints By default, when you have a Client VPN endpoint, all traffic from clients is routed over the Client VPN tunnel. When you enable split-tunnel on the Client VPN endpoint, we push the routes on the [Client VPN endpoint route table](cvpn-working-routes.md) to the device that is connected to the Client VPN endpoint. This ensures that only traffic with a destination to the network matching a route from the Client VPN endpoint route table is routed over the Client VPN tunnel. You can use a split-tunnel Client VPN endpoint when you do not want all user traffic to route through the Client VPN endpoint. In the following example, split-tunnel is enabled on the Client VPN endpoint. Only traffic that's destined for the VPC (`172.31.0.0/16`) is routed over the Client VPN tunnel. Traffic that's destined for on-premises resources is not routed over the Client VPN tunnel. ![\[Split-tunnel Client VPN endpoint\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/client-vpn-split-tunnel.png) ## Split-tunnel benefits Split-tunnel on Client VPN endpoints offers the following benefits: + You can optimize the routing of traffic from clients by having only the AWS destined traffic traverse the VPN tunnel. + You can reduce the volume of outgoing traffic from AWS, therefore reducing the data transfer cost. ## Routing considerations + When you enable split-tunnel mode, all of the routes in the Client VPN endpoint's route table are added to the client's route table when the VPN connection is established. This operation is different from the default behavior, which overwrites the client's route table with the entry `0.0.0.0/0` to route all traffic over the VPN. **Note** Adding a 0.0.0.0/0 route to the Client VPN endpoint's route table when using split-tunnel mode may cause connectivity disruption and is not recommended + When split-tunnel mode is enabled, any modification to the Client VPN endpoint route table will result in all client connections being reset. ## Enabling split-tunnel You can enable split-tunnel on a new or existing Client VPN endpoint. For more information, see the following topics: + [Create an AWS Client VPN endpoint](cvpn-working-endpoint-create.md) + [Modify an AWS Client VPN endpoint](cvpn-working-endpoint-modify.md) # Connection logging for an AWS Client VPN endpoint Connection logging is a feature of AWS Client VPN that enables you to capture *connection logs* for your Client VPN endpoint. A connection log contains *connection log entries* that capture information about connection events, such as when a client (end user) connects, attempts to connect, or disconnects from your Client VPN endpoint. You can use this information to run forensics, analyze how your Client VPN endpoint is being used, or debug connection issues. Connection logging is available in all Regions where AWS Client VPN is available. Connection logs are published to a CloudWatch Logs log group in your account. **Note** Failed mutual authentication attempts are not logged. ## Connection log entries A connection log entry is a JSON-formatted blob of key-value pairs. The following is an example connection log entry. ``` { "connection-log-type": "connection-attempt", "connection-attempt-status": "successful", "connection-reset-status": "NA", "connection-attempt-failure-reason": "NA", "connection-id": "cvpn-connection-abc123abc123abc12", "client-vpn-endpoint-id": "cvpn-endpoint-aaa111bbb222ccc33", "transport-protocol": "udp", "connection-start-time": "2020-03-26 20:37:15", "connection-last-update-time": "2020-03-26 20:37:15", "client-ip": "10.0.1.2", "common-name": "client1", "device-type": "mac", "device-ip": "98.247.202.82", "port": "50096", "ingress-bytes": "0", "egress-bytes": "0", "ingress-packets": "0", "egress-packets": "0", "connection-end-time": "NA", "username": "joe" } ``` A connection log entry contains the following keys: + `connection-log-type` — The type of connection log entry (`connection-attempt` or `connection-reset`). + `connection-attempt-status` — The status of the connection request (`successful`, `failed`, `waiting-for-assertion`, or `NA`). + `connection-reset-status` — The status of a connection reset event (`NA` or `assertion-received`). + `connection-attempt-failure-reason` — The reason for the connection failure, if applicable. + `connection-id` — The ID of the connection. + `client-vpn-endpoint-id` — The ID of the Client VPN endpoint to which the connection was made. + `transport-protocol` — The transport protocol that was used for the connection. + `connection-start-time` — The start time of the connection. + `connection-last-update-time` — The last update time of the connection. This value is periodically updated in the logs. + `client-ip` — The IP address of the client, which is allocated from the client IPv4 CIDR range for the Client VPN endpoint. + `common-name` — The common name of the certificate that's used for certificate-based authentication. + `device-type` — The type of device used for the connection by the end user. + `device-ip` — The public IP address of the device. + `port` — The port number for the connection. + `ingress-bytes` — The number of ingress (inbound) bytes for the connection. This value is periodically updated in the logs. + `egress-bytes` — The number of egress (outbound) bytes for the connection. This value is periodically updated in the logs. + `ingress-packets` — The number of ingress (inbound) packets for the connection. This value is periodically updated in the logs. + `egress-packets` — The number of egress (outbound) packets for the connection. This value is periodically updated in the logs. + `connection-end-time` — The end time of the connection. The value is `NA` if the connection is still in progress or if the connection attempt failed. + `posture-compliance-statuses` — The posture compliance statuses returned by the [client connect handler](connection-authorization.md), if applicable. + `username` — The username is recorded when user-based authentication (AD or SAML) is used for the endpoint. + `connection-duration-seconds` — The duration of a connection in seconds. Equal to the difference between "connection-start-time" and "connection-end-time". For more information about enabling connection logging, see [AWS Client VPN connection logs](cvpn-working-with-connection-logs.md). # Client VPN scaling considerations When you create a Client VPN endpoint, consider the maximum number of concurrent VPN connections that you plan to support. You should take into account the number of clients that you currently support, and whether your Client VPN endpoint can scale to meet additional demand if needed. The following factors affect the maximum number of concurrent VPN connections that can be supported on a Client VPN endpoint: **Client CIDR range size** When you [create a Client VPN endpoint](cvpn-working-endpoint-create.md), you must specify a client CIDR range, which is an IPv4 CIDR block between a /12 and /22 netmask. Each VPN connection to the Client VPN endpoint is assigned a unique IP address from the client CIDR range. A portion of the addresses in the client CIDR range are also used to support the availability model of the Client VPN endpoint, and cannot be assigned to clients. You cannot change the client CIDR range after you create the Client VPN endpoint. In general, we recommend that you specify a client CIDR range that contains twice the number of IP addresses (and therefore concurrent connections) that you plan to support on the Client VPN endpoint. **Number of associated subnets** When you [associate a subnet](cvpn-working-target.md) with a Client VPN endpoint, you enable users to establish VPN sessions to the Client VPN endpoint. You can associate multiple subnets with a Client VPN endpoint for high availability, and to enable additional connection capacity. The following are the number of supported concurrent VPN connections based on the number of subnet associations for the Client VPN endpoint. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/scaling-considerations.html) You cannot associate multiple subnets from the same Availability Zone with a Client VPN endpoint. Therefore, the number of subnet associations also depends on the number of Availability Zones that are available in an AWS Region. For example, if you expect to support 8,000 VPN connections to your Client VPN endpoint, specify a minimum client CIDR range size of `/18` (16,384 IP addresses), and associate at least 2 subnets with the Client VPN endpoint. If you’re unsure what the number of expected VPN connections is for your Client VPN endpoint, we recommend that you specify a size `/16` CIDR block or larger. For more information about the rules and limitations for working with client CIDR ranges and target networks, see [Rules and best practices for using AWS Client VPN](what-is-best-practices.md). For more information about quotas for your Client VPN endpoint, see [AWS Client VPN quotas](limits.md).