Troubleshooting AWS Client VPN

The following topic can help you troubleshoot problems that you might have with a Client VPN endpoint.

For more information about troubleshooting OpenVPN-based software that clients use to connect to a Client VPN, see Troubleshooting Your Client VPN Connection in the AWS Client VPN User Guide.

Unable to resolve Client VPN endpoint DNS name

Problem

I am unable to resolve the Client VPN endpoint's DNS name.

Cause

The Client VPN endpoint configuration file includes a parameter called remote-random-hostname. This parameter forces the client to prepend a random string to the DNS name to prevent DNS caching. Some clients do not recognize this parameter and therefore, they do not prepend the required random string to the DNS name.

Solution

Open the Client VPN endpoint configuration file using your preferred text editor. Locate the line that specifies the Client VPN endpoint DNS name, and prepend a random string to it so that the format is random_string.displayed_DNS_name. For example:

• Original DNS name: cvpn-endpoint-0102bc4c2eEXAMPLE.clientvpn.us-west-2.amazonaws.com

• Modified DNS name: asdfa.cvpn-endpoint-0102bc4c2eEXAMPLE.clientvpn.us-west-2.amazonaws.com

Traffic is not being split between subnets

Problem

I am trying to split network traffic between two subnets. Private traffic should be routed through a private subnet, while internet traffic should be routed through a public subnet. However, only one route is being used even though I have added both routes to the Client VPN endpoint route table.

Cause

You can associate multiple subnets with a Client VPN endpoint, but you can associate only one subnet per Availability Zone. The purpose of multiple subnet association is to provide high availability and Availability Zone redundancy for clients. However, Client VPN does not enable you to selectively split traffic between the subnets that are associated with the Client VPN endpoint.

Clients connect to a Client VPN endpoint based on the DNS round-robin algorithm. This means that their traffic can be routed through any of the associated subnets when they establish a connection. Therefore, they might experience connectivity issues if they land on an associated subnet that does not have the required route entries.

For example, say that you configure the following subnet associations and routes:

• Subnet associations

  • Association 1: Subnet-A (us-east-1a)

  • Association 2: Subnet-B (us-east-1b)

• Routes

  • Route 1: 10.0.0.0/16 routed to Subnet-A

  • Route 2: 172.31.0.0/16 routed to Subnet-B

In this example, clients that land on Subnet-A when they connect cannot access Route 2, while clients that land on Subnet-B when they connect cannot access Route 1.

Solution

Verify that the Client VPN endpoint has the same route entries with targets for each associated network. This ensures that clients have access to all routes regardless of the subnet through which their traffic is routed.

Authorization rules for Active Directory groups not working as expected

Problem

I have configured authorization rules for my Active Directory groups, but they are not working as I expected. I have added an authorization rule for 0.0.0.0/0 to authorize traffic for all networks, but traffic still fails for specific destination CIDRs.

Cause

Authorization rules are indexed on network CIDRs. Authorization rules must grant Active Directory groups access to specific network CIDRs. Authorization rules for 0.0.0.0/0 are handled as a special case, and are therefore evaluated last, regardless of the order in which the authorization rules are created.

For example, say that you create five authorization rules in the following order:

• Rule 1: Group 1 access to 10.1.0.0/16

• Rule 2: Group 1 access to 0.0.0.0/0

• Rule 3: Group 2 access to 0.0.0.0/0

• Rule 4: Group 3 access to 0.0.0.0/0

• Rule 5: Group 2 access to 172.131.0.0/16

In this example, Rule 2, Rule 3, and Rule 4 are evaluated last. Group 1 has access to 10.1.0.0/16 only, and Group 2 has access to 172.131.0.0/16 only. Group 3 does not have access to 10.1.0.0/16 or 172.131.0.0/16, but it has access to all other networks. If you remove Rules 1 and 5, all three groups have access to all networks.

Client VPN uses longest prefix matching when evaluating authorization rules. See Route priority in the Amazon VPC User Guide for more details.

Solution

Verify that you create authorization rules that explicitly grant Active Directory groups access to specific network CIDRs. If you add an authorization rule for 0.0.0.0/0, keep in mind that it will be evaluated last, and that previous authorization rules may limit the networks to which it grants access.

Clients can't access a peered VPC, Amazon S3, or the internet

Problem

I have properly configured my Client VPN endpoint routes, but my clients can't access a peered VPC, Amazon S3, or the internet.

Solution

The following flow chart contains the steps to diagnose internet, peered VPC, and Amazon S3 connectivity issues.

1. For access to the internet, add an authorization rule for 0.0.0.0/0.

   For access to a peered VPC, add an authorization rule for the IPv4 CIDR range of the VPC.

   For access to S3, specify the IP address of the Amazon S3 endpoint.

2. Check whether you are able to resolve the DNS name.

   If you are unable to resolve the DNS name, verify that you have specified the DNS servers for the Client VPN endpoint. If you manage your own DNS server, specify its IP address. Verify that the DNS server is accessible from the VPC.

   If you're unsure about which IP address to specify for the DNS servers, specify the VPC DNS resolver at the .2 IP address in your VPC.

3. For internet access, check if you are able to ping a public IP address or a public website, for example, amazon.com. If you do not get a response, make sure that the route table for the associated subnets has a default route that targets either an internet gateway or a NAT gateway. If the route is in place, verify that the associated subnet does not have network access control list rules that block inbound and outbound traffic.

   If you are unable to reach a peered VPC, verify that the associated subnet's route table has a route entry for the peered VPC.

   If you are unable to reach Amazon S3, verify that the associated subnet's route table has a route entry for the gateway VPC endpoint.

4. Check whether you can ping a public IP address with a payload larger than 1400 bytes. Use one of the following commands:

   • Windows

     C:\> ping  8.8.8.8 -l 1480 -f

   • Linux

     $ ping -s 1480 8.8.8.8 -M do

   If you cannot ping an IP address with a payload larger than 1400 bytes, open the Client VPN endpoint .ovpn configuration file using your preferred text editor, and add the following.

   mssfix 1328

Access to a peered VPC, Amazon S3, or the internet is intermittent

Problem

I have intermittent connectivity issues when connecting to a peered VPC, Amazon S3, or the internet, but access to associated subnets is unaffected. I need to disconnect and reconnect in order to resolve the connectivity issues.

Cause

Clients connect to a Client VPN endpoint based on the DNS round-robin algorithm. This means that their traffic can be routed through any of the associated subnets when they establish a connection. Therefore, they might experience connectivity issues if they land on an associated subnet that does not have the required route entries.

Solution

Verify that the Client VPN endpoint has the same route entries with targets for each associated network. This ensures that clients have access to all routes regardless of the associated subnet through which their traffic is routed.

For example, say that your Client VPN endpoint has three associated subnets (Subnet A, B, and C), and you want to enable internet access for your clients. To do this, you must add three 0.0.0.0/0 routes - one that targets each associated subnet:

• Route 1: 0.0.0.0/0 for Subnet A

• Route 2: 0.0.0.0/0 for Subnet B

• Route 3: 0.0.0.0/0 for Subnet C

Client software returns TLS error

Problem

I used to be able to connect my clients to the Client VPN successfully, but now the OpenVPN-based client returns one of the following errors when it tries to connect:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 
TLS Error: TLS handshake failed

Connection failed because of a TLS handshake error. Contact your IT administrator.

Possible cause #1

If you use mutual authentication and you imported a client certificate revocation list, the client certificate revocation list might have expired. During the authentication phase, the Client VPN endpoint checks the client certificate against the client certificate revocation list that you imported. If the client certificate revocation list has expired, you cannot connect to the Client VPN endpoint.

Solution #1

Check the expiry date of your client certificate revocation list by using the OpenSSL tool.

$ openssl crl -in path_to_crl_pem_file -noout -nextupdate

The output displays the expiry date and time. If the client certificate revocation list has expired, you must create a new one and import it to the Client VPN endpoint. For more information, see Client certificate revocation lists.

Possible cause #2

The server certificate being used for the Client VPN endpoint has expired.

Solution #2

Check the status of your server certificate in the AWS Certificate Manager console or by using the AWS CLI. If the server certificate is expired, create a new certificate and upload to ACM. For detailed steps to generate the server and client certificates and keys using the OpenVPN easy-rsa utility, and import them into ACM see Mutual authentication.

Alternatively, there might be an issue with the OpenVPN-based software that the client is using to connect to the Client VPN. For more information about troubleshooting OpenVPN-based software, see Troubleshooting Your Client VPN Connection in the AWS Client VPN User Guide.

Client software returns user name and password errors (Active Directory authentication)

Problem

I use Active Directory authentication for my Client VPN endpoint and I used to be able to connect my clients to the Client VPN successfully. But now, clients are getting invalid user name and password errors.

Possible causes

If you use Active Directory authentication and if you enabled multi-factor authentication (MFA) after you distributed the client configuration file, the file does not contain the necessary information to prompt users to enter their MFA code. Users are prompted to enter their user name and password only, and authentication fails.

Solution

Download a new client configuration file and distribute it to your clients. Verify that the new file contains the following line.

static-challenge "Enter MFA code " 1

For more information, see Export and configure the client configuration file. Test the MFA configuration for your Active Directory without using the Client VPN endpoint to verify that MFA is working as expected.

Client software returns user name and password errors (federated authentication)

Problem

Trying to log in with a user name and password with federated authentication and getting the error "The credentials received were incorrect. Contact your IT administrator."

Cause

This error can be caused by not having at least one attribute included in the SAML response from the IdP.

Solution

Make sure at least one attribute is included in the SAML response from the IdP. See SAML-based IdP configuration resources for more information.

Clients cannot connect (mutual authentication)

Problem

I use mutual authentication for my Client VPN endpoint. Clients are getting TLS key negotiation failed errors and timeout errors.

Possible causes

The configuration file that was provided to the clients does not contain the client certificate and the client private key, or the certificate and key are incorrect.

Solution

Ensure that the configuration file contains the correct client certificate and key. If necessary, fix the configuration file and redistribute it to your clients. For more information, see Export and configure the client configuration file.

Client returns a credentials exceed max size error (federated authentication)

Problem

I use federated authentication for my Client VPN endpoint. When clients enter their user name and password in the SAML-based identity provider (IdP) browser window, they get an error that the credentials exceed the maximum supported size.

Cause

The SAML response returned by the IdP exceeds the maximum supported size. For more information, see Requirements and considerations for SAML-based federated authentication.

Solution

Try to reduce the number of groups that the user belongs to in the IdP, and try connecting again.

Client does not open browser (federated authentication)

Problem

I use federated authentication for my Client VPN endpoint. When clients try to connect to the endpoint, the client software does not open a browser window, and instead displays a user name and password popup window.

Cause

The configuration file that was provided to the clients does not contain the auth-federate flag.

Solution

Export the latest configuration file, import it to the AWS provided client, and try connecting again.

Client returns no available ports error (federated authentication)

Problem

I use federated authentication for my Client VPN endpoint. When clients try to connect to the endpoint, the client software returns the following error:

The authentication flow could not be initiated. There are no available ports. 

Cause

The AWS provided client requires the use of TCP port 35001 to complete authentication. For more information, see Requirements and considerations for SAML-based federated authentication.

Solution

Verify that the client's device is not blocking TCP port 35001 or is using it for a different process.

VPN connection terminated due to IP mismatch

Problem

VPN connection terminated and the client software returns the following error: "The VPN connection is being terminated due to a discrepancy between the IP address of the connected server and the expected VPN server IP. Please contact your network administrator for assistance in resolving this issue."

Cause

The AWS provided client requires that the IP address that it is connected to matches the IP of the VPN server backing the Client VPN endpoint. For more information, see Rules and best practices of AWS Client VPN.

Solution

Verify that there is no DNS proxy between the AWS provided client and the Client VPN endpoint.

Routing traffic to LAN not working as expected

Problem

Trying to route traffic to local area network (LAN) not working as expected when the LAN IP address ranges are not within the following standard private IP address ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16.

Cause

If the client LAN address range is detected to fall outside of the above standard ranges, the Client VPN endpoint will automatically push the OpenVPN directive "redirect-gateway block-local" to the client, forcing all LAN traffic into the VPN. For more information, see Rules and best practices of AWS Client VPN.

Solution

If you require LAN access during VPN connections, it is advised that you use the conventional address ranges listed above for your LAN.

Verify the bandwidth limit for a Client VPN endpoint

Problem

I need to verify the bandwidth limit for a Client VPN endpoint.

Cause

The throughput depends on multiple factors, such as the capacity of your connection from your location, and the network latency between your Client VPN desktop application on your computer and the VPC endpoint. There is also a 10 Mbps bandwidth limit per user connection.

Solution

Run the following commands to verify the bandwidth.

sudo iperf3 -s -V

On the client:

sudo iperf -c server IP address -p port -w 512k -P 60