# Troubleshooting AWS Client VPN
<a name="troubleshooting"></a>

The following sections 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](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/troubleshooting.html) in the *AWS Client VPN User Guide*.

**Topics**
+ [Unable to resolve the Client VPN endpoint DNS name](resolve-host-name.md)
+ [Traffic is not being split between subnets](split-traffic.md)
+ [Authorization rules for Active Directory groups not working as expected](ad-group-auth-rules.md)
+ [Clients can't access a peered VPC, Amazon S3, or the internet](no-internet-access.md)
+ [Access to a peered VPC, Amazon S3, or the internet is intermittent](intermittent-access.md)
+ [Client software returns TLS error](client-cannot-connect.md)
+ [Client software returns user name and password errors — Active Directory authentication](client-user-name-password-mfa.md)
+ [Client software returns user name and password errors — federated authentication](missing-attribute.md)
+ [Clients cannot connect — mutual authentication](client-cannot-connect-mutual.md)
+ [Client returns a credentials exceed max size error — federated authentication](client-credentials-exceeded.md)
+ [Client does not open browser — federated authentication](client-no-browser.md)
+ [Client returns no available ports error — federated authentication](client-no-port.md)
+ [VPN connection terminated due to IP mismatch](server-ip-mismatch.md)
+ [Routing traffic to LAN not working as expected](routing-to-lan.md)
+ [Verify the bandwidth limit for an endpoint](test-throughput.md)
+ [Client VPN tunnel connectivity](VPNTunnelConnectivityTroubleshooting.md)

# Troubleshooting AWS Client VPN: Unable to resolve the Client VPN endpoint DNS name
<a name="resolve-host-name"></a>

**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\$1string.displayed\$1DNS\$1name*. 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`

# Troubleshooting AWS Client VPN: Traffic is not being split between subnets
<a name="split-traffic"></a>

**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.

# Troubleshooting AWS Client VPN: Authorization rules for Active Directory groups not working as expected
<a name="ad-group-auth-rules"></a>

**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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-tables-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.

# Troubleshooting AWS Client VPN: Clients can't access a peered VPC, Amazon S3, or the internet
<a name="no-internet-access"></a>

**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.

![\[Client VPN troubleshooting steps\]](http://docs.aws.amazon.com/vpn/latest/clientvpn-admin/images/cvpn-flow.png)


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.

1. 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.

1. 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.

1. 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
   ```

# Troubleshooting AWS Client VPN: Access to a peered VPC, Amazon S3, or the internet is intermittent
<a name="intermittent-access"></a>

**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

# Troubleshooting AWS Client VPN: Client software returns a TLS error when trying to connect to Client VPN
<a name="client-cannot-connect"></a>

**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 \$11**  
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 \$11**  
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 [AWS Client VPN client certificate revocation lists](cvpn-working-certificates.md).

**Possible cause \$12**  
The server certificate being used for the Client VPN endpoint has expired.

**Solution \$12**  
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](https://github.com/OpenVPN/easy-rsa), and import them into ACM see [Mutual authentication in AWS Client VPN](mutual.md).

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](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/troubleshooting.html) in the *AWS Client VPN User Guide*.

# Troubleshooting AWS Client VPN: Client software returns user name and password errors — Active Directory authentication
<a name="client-user-name-password-mfa"></a>

**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 [AWS Client VPN endpoint configuration file export](cvpn-working-endpoint-export.md). Test the MFA configuration for your Active Directory without using the Client VPN endpoint to verify that MFA is working as expected.

# Troubleshooting AWS Client VPN: Client software returns user name and password errors — federated authentication
<a name="missing-attribute"></a>

**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](federated-authentication.md#saml-config-resources) for more information.

# Troubleshooting AWS Client VPN: Clients cannot connect — mutual authentication
<a name="client-cannot-connect-mutual"></a>

**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 [AWS Client VPN endpoint configuration file export](cvpn-working-endpoint-export.md).

# Troubleshooting AWS Client VPN: Client returns a credentials exceed max size error in Client VPN — federated authentication
<a name="client-credentials-exceeded"></a>

**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](federated-authentication.md#saml-requirements).

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

# Troubleshooting AWS Client VPN: Client does not open browser for an endpoint — federated authentication
<a name="client-no-browser"></a>

**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](cvpn-working-endpoint-export.md), import it to the AWS provided client, and try connecting again.

# Troubleshooting AWS Client VPN: Client returns no available ports error — federated authentication
<a name="client-no-port"></a>

**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](federated-authentication.md#saml-requirements).

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

# Troubleshooting AWS Client VPN: A connection is terminated due to an IP mismatch
<a name="server-ip-mismatch"></a>

**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 for using AWS Client VPN](what-is-best-practices.md).

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

# Troubleshooting AWS Client VPN: Routing traffic to LAN not working as expected
<a name="routing-to-lan"></a>

**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 for using AWS Client VPN](what-is-best-practices.md).

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

# Troubleshooting AWS Client VPN: Verify the bandwidth limit for a Client VPN endpoint
<a name="test-throughput"></a>

**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. A minimum bandwidth of 10 Mbps is supported 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
```

# Troubleshooting AWS Client VPN: Tunnel connectivity issues to a VPC
<a name="VPNTunnelConnectivityTroubleshooting"></a>

When experiencing connectivity issues with your AWS Client VPN connection, follow this systematic troubleshooting approach to identify and resolve the problem. This section provides step-by-step procedures to diagnose common Client VPN connectivity issues between remote clients and Amazon VPC resources. 

**Topics**
+ [Network connectivity prerequisites](#NetworkConnectivityPrerequisites)
+ [Check Client VPN endpoint status](#CheckClientVPNEndpointStatus)
+ [Verify client connections](#VerifyClientConnections)
+ [Verify client authentication](#ClientAuthentication)
+ [Check authorization rules](#AuthorizationRules)
+ [Validate Client VPN routes](#ValidateClientVPNRoutes)
+ [Verify security groups and network ACLs](#SecurityGroupNACLVerification)
+ [Test client connectivity](#TestClientConnectivity)
+ [Diagnose the client device](#ClientSideDiagnostics)
+ [Troubleshoot DNS resolution](#DNSTroubleshooting)
+ [Troubleshoot performance](#PerformanceTroubleshooting)
+ [Monitor Client VPN metrics](#MonitorClientVPNMetrics)
+ [Check Client VPN logs](#CheckClientVPNLogs)
+ [Common issues and solutions](#CommonIssues)

## Network connectivity prerequisites
<a name="NetworkConnectivityPrerequisites"></a>

Before troubleshooting Client VPN connectivity, verify these network prerequisites:
+ Ensure the Client VPN endpoint subnet has internet connectivity (via Internet Gateway or NAT Gateway).
+ Verify that the Client VPN endpoint is associated with subnets in different Availability Zones for high availability.
+ Check that the VPC has sufficient IP address space and doesn't conflict with client CIDR blocks.
+ Confirm that target subnets have proper route table associations.

## Check Client VPN endpoint status
<a name="CheckClientVPNEndpointStatus"></a>

First, verify that your Client VPN endpoint is in the correct state:

1. Use the AWS CLI to check the Client VPN endpoint status:

   ```
   aws ec2 describe-client-vpn-endpoints --region your-region
   ```

1. Look for the endpoint state in the output. The state should be `available`.

1. Verify that the endpoint has associated target networks (subnets).

1. If the state is not `available`, check for any error messages or pending states that might indicate configuration issues.

## Verify client connections
<a name="VerifyClientConnections"></a>

Check the status of client connections to your Client VPN endpoint:

1. Check active client connections:

   ```
   aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-id --region your-region
   ```

1. Review connection status and any error messages in the output.

1. Check client authentication logs for failed authentication attempts.

1. Verify that clients are receiving IP addresses from the configured client CIDR block.

**Note**  
If clients cannot connect, the issue is likely with authentication configuration, authorization rules, or network connectivity.

## Verify client authentication
<a name="ClientAuthentication"></a>

Authentication issues are common causes of Client VPN connectivity problems:
+ For mutual authentication, ensure client certificates are valid and not expired.
+ For Active Directory authentication, verify user credentials and domain connectivity.
+ For SAML-based federated authentication, check IdP configuration and user permissions.
+ Review authentication logs in CloudWatch for detailed error information.
+ Verify that the authentication method configured on the endpoint matches the client configuration.

## Check authorization rules
<a name="AuthorizationRules"></a>

Authorization rules control which network resources clients can access:

1. List current authorization rules:

   ```
   aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-id --region your-region
   ```

1. Verify that rules exist for the target networks clients need to access.

1. Check that the rules specify the correct Active Directory groups (if using AD authentication).

1. Ensure that authorization rules are in `active` state.

## Validate Client VPN routes
<a name="ValidateClientVPNRoutes"></a>

Proper routing configuration is essential for Client VPN connectivity:

1. Check Client VPN endpoint routes:

   ```
   aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-id --region your-region
   ```

1. Verify routes exist for target networks that clients need to access.

1. Check Amazon VPC route tables to ensure return traffic can reach the Client VPN endpoint:

   ```
   aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-id" --region your-region
   ```

1. Verify that target network associations are configured correctly.

## Verify security groups and network ACLs
<a name="SecurityGroupNACLVerification"></a>

Security groups and network ACLs can block Client VPN traffic:

1. Check security groups for target EC2 instances:

   ```
   aws ec2 describe-security-groups --group-ids sg-xxxxxxxxx --region your-region
   ```

1. Verify inbound rules allow traffic from Client VPN CIDR block:
   + SSH (port 22) from Client VPN CIDR: `10.0.0.0/16`
   + HTTP (port 80) from Client VPN CIDR: `10.0.0.0/16`
   + HTTPS (port 443) from Client VPN CIDR: `10.0.0.0/16`
   + Custom application ports as needed

1. For Client VPN endpoint security group (if applicable), ensure it allows:
   + UDP port 443 (OpenVPN) from 0.0.0.0/0
   + All traffic outbound to VPC CIDR blocks

1. Check that network ACLs are not blocking the traffic. Network ACLs are stateless, so both inbound and outbound rules must be configured.

1. Verify both inbound and outbound rules for the specific traffic you're trying to send.

## Test client connectivity
<a name="TestClientConnectivity"></a>

Test connectivity from Client VPN clients to Amazon VPC resources:

1. From a connected Client VPN client, test connectivity to Amazon VPC resources:

   ```
   ping vpc-resource-ip
   traceroute vpc-resource-ip
   ```

1. Test specific application connectivity:

   ```
   telnet vpc-resource-ip port
   ```

1. Verify DNS resolution if using private DNS names:

   ```
   nslookup private-dns-name
   ```

1. Test connectivity to internet resources if split tunneling is enabled.

## Diagnose the client device
<a name="ClientSideDiagnostics"></a>

Perform these checks on the client device:

1. Verify client configuration file (.ovpn) contains correct settings:
   + Correct server endpoint URL
   + Valid client certificate and private key
   + Proper authentication method configuration

1. Check client logs for connection errors:
   + Windows: Event Viewer → Applications and Services Logs → OpenVPN
   + macOS: Console app, search for "Tunnelblick" or "OpenVPN"
   + Linux: `/var/log/openvpn/` or systemd journal

1. Test basic network connectivity from client:

   ```
   ping 8.8.8.8
   nslookup cvpn-endpoint-id.cvpn.region.amazonaws.com
   ```

## Troubleshoot DNS resolution
<a name="DNSTroubleshooting"></a>

DNS issues can prevent access to resources using private DNS names:

1. Check if DNS servers are configured in the Client VPN endpoint:

   ```
   aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-id --query 'ClientVpnEndpoints[0].DnsServers'
   ```

1. Test DNS resolution from client:

   ```
   nslookup private-resource.internal
   dig private-resource.internal
   ```

1. Verify Route 53 Resolver rules if using custom DNS resolution.

1. Check that security groups allow DNS traffic (UDP/TCP port 53) from Client VPN CIDR to DNS servers.

## Troubleshoot performance
<a name="PerformanceTroubleshooting"></a>

Address performance issues with Client VPN connections:
+ Monitor bandwidth utilization using CloudWatch metrics for ingress/egress bytes.
+ Check for packet loss using continuous ping tests from clients.
+ Verify that Client VPN endpoint is not hitting connection limits.
+ Consider using multiple Client VPN endpoints for load distribution.
+ Test with different client locations to identify regional performance issues.

## Monitor Client VPN metrics
<a name="MonitorClientVPNMetrics"></a>

Monitor Client VPN endpoint metrics using CloudWatch:

1. Check active connection metrics:

   ```
   aws cloudwatch get-metric-statistics \
     --namespace AWS/ClientVPN \
     --metric-name ActiveConnectionsCount \
     --dimensions Name=Endpoint,Value=cvpn-endpoint-id \
     --start-time start-time \
     --end-time end-time \
     --period 300 \
     --statistics Average
   ```

1. Review authentication failure metrics:

   ```
   aws cloudwatch get-metric-statistics \
     --namespace AWS/ClientVPN \
     --metric-name AuthenticationFailures \
     --dimensions Name=Endpoint,Value=cvpn-endpoint-id \
     --start-time start-time \
     --end-time end-time \
     --period 300 \
     --statistics Sum
   ```

1. Review other available metrics such as ingress and egress bytes and packets.

## Check Client VPN logs
<a name="CheckClientVPNLogs"></a>

Client VPN connection logs provide detailed information about connection attempts and errors:
+ Enable Client VPN connection logging if not already configured.
+ Review CloudWatch logs for connection attempts, authentication failures, and authorization errors.
+ Look for specific error codes and messages that indicate the root cause of connectivity issues.
+ Check for patterns in failed connections that might indicate configuration problems.

## Common issues and solutions
<a name="CommonIssues"></a>

Common issues that can affect Client VPN connectivity:

Authentication failures  
Client certificates expired or invalid, or Active Directory credentials incorrect. Verify authentication configuration and credential validity.

Missing authorization rules  
Clients cannot access target networks due to missing or incorrect authorization rules. Add appropriate authorization rules for the required networks.

Split tunneling issues  
Traffic routing incorrectly due to split tunneling configuration. Review and adjust split tunneling settings as needed.

Client IP pool exhaustion  
No available IP addresses in the client CIDR block. Expand the client CIDR range or disconnect unused clients.

MTU issues  
Large packets are being dropped due to MTU size limitations. Try setting the MTU to 1436 bytes or enable Path MTU Discovery on client devices.

DNS resolution problems  
Clients cannot resolve private DNS names. Verify DNS server configuration and ensure DNS traffic is allowed through security groups.

Overlapping IP ranges  
Client CIDR blocks conflict with local network ranges. Check for and resolve any overlapping IP address ranges between client CIDR and local networks.

TLS handshake failures  
Connection fails during TLS negotiation. Check certificate validity, ensure correct cipher suites, and verify that client and server certificates are properly configured.

Route propagation delays  
New routes not immediately available to clients. Allow 1-2 minutes for route propagation after making changes to Client VPN routes.

Connection drops/instability  
Frequent disconnections or unstable connections. Check for network congestion, firewall interference, or power management settings on client devices.