Troubleshooting 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 adminitsrator.

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.

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.

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.

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