SSL-VPN connection FAQ

Category

Cause

Solution

Configuration error

The SSL server or the client is configured incorrectly.

1. Check the Local CIDR Block configuration of the SSL server. Ensure that the CIDR block of the target VPC is added to the Local CIDR Block. For more information, see Modify an SSL server.

2. Verify that the VPN software on the client is correctly configured. For more information about how to configure a client, see Configure a client.

Expired SSL client certificate

The SSL client certificate is expired or invalid.

1. Verify the validity of the SSL client certificate.

   By default, an SSL client certificate is valid for three years.

2. Delete the existing SSL client certificate and all its configurations. Then, download and install a new SSL client certificate.

   You must re-download and install the SSL client certificate after enabling or disabling two-factor authentication, or modifying the SSL server configuration. For more information, see Download an SSL client certificate.

Connection limit exceeded

The number of clients connected to the SSL server exceeds the limit.

1. Check whether the number of clients that are connected to the VPN Gateway instance exceeds the limit.

   • If the number of concurrent SSL connections exceeds the limit, upgrade the SSL server specification. For more information, see Change the number of concurrent SSL connections.

   • Alternatively, disconnect idle clients. Resources are released approximately 5 minutes after disconnection.

     To view client connection information, see View SSL client information.

2. Change the Protocol of the SSL server to TCP. Then, re-download and install the SSL client certificate. For more information, see Modify an SSL server and Download an SSL client certificate.

   Use TCP for better reliability. As an unreliable protocol, UDP can cause connection slots to be occupied by unstable connections.

IP address issue

The CIDR block of the VPC overlaps with the CIDR block of the client.

Modify the Local CIDR Block (the CIDR block of the VPC or vSwitch) or the Client CIDR Block of the SSL server to prevent IP address conflicts. For more information, see Modify an SSL server.

The Client CIDR Block of the SSL server is too small. As a result, no IP addresses can be allocated to clients.

Make sure that the number of IP addresses in the specified client CIDR block is at least four times the maximum number of SSL-VPN connections. For more information, see Create and manage an SSL server.

For example, if you specify 192.168.0.0/24 as the client CIDR block, the system first divides a subnet CIDR block with a subnet mask of 30 from 192.168.0.0/24, such as 192.168.0.4/30. This subnet provides up to four IP addresses. Then, the system allocates an IP address from 192.168.0.4/30 to the client and uses the other three IP addresses to ensure network communication. In this case, one client consumes four IP addresses. Therefore, to ensure that an IP address can be allocated to your client, you must make sure that the number of IP addresses in the client CIDR block is at least four times the maximum number of SSL-VPN connections supported by the associated VPN gateway.

VPN software issue

A VPN software conflict occurs on the client.

1. If multiple VPN applications are installed on your client, we recommend that you use only one to establish the SSL-VPN connection.

2. Try to restart the client or reinstall the VPN software. For more information, see Configure a client.

Other

The cause is not listed above.

Check the logs of the SSL-VPN connection to troubleshoot the failure. For more information, see Troubleshoot SSL-VPN connection issues.

Category

Cause

Solution

Unreliable public network

Poor public network quality between the client and the VPN Gateway causes intermittent disconnections.

On the client, run the ping or mtr command to test the network quality from the client to the public IP address of the VPN Gateway.

If the network quality is poor (for example, high latency or packet loss), contact your internet service provider (ISP) for assistance.

Long-distance SSL-VPN connections, such as from US (Silicon Valley) to Singapore, may experience intermittent disconnections when the client accesses the VPC.

Change the Protocol of the SSL server to TCP for better reliability. For more information, see Modify an SSL server.

If the issue persists after changing the Protocol to TCP, we recommend that you use Cloud Enterprise Network (CEN) and Smart Access Gateway (SAG) to connect the client to the VPC.

SSL server configuration change

The client disconnects because the SSL server configuration is changed.

After you modify the SSL server configuration, reconnect the client.

Category

Cause

Solution

Unreliable public network

Long-distance SSL-VPN connections, such as from US (Silicon Valley) to Singapore, may experience intermittent disconnections when the client accesses the VPC.

Change the Protocol of the SSL server to TCP for better reliability. For more information, see Modify an SSL server.

If you use an SSL-VPN connection for long-distance communication, such as from US (Silicon Valley) to Singapore, and the issue persists after you change the Protocol to TCP, we recommend using Cloud Enterprise Network and Smart Access Gateway to connect your client to the VPC.

Connection limit exceeded

The number of clients connected to the SSL server exceeds the limit.

1. Check whether the number of clients that are connected to the VPN Gateway instance exceeds the limit.

   • If the number of concurrent SSL connections exceeds the limit, upgrade the SSL server specification. For more information, see Change the number of concurrent SSL connections.

   • Alternatively, disconnect idle clients. Resources are released approximately 5 minutes after disconnection.

     To view client connection information, see View SSL client information.

2. Change the Protocol of the SSL server to TCP. Then, re-download and install the SSL client certificate. For more information, see Modify an SSL server and Download an SSL client certificate.

   Use TCP for better reliability. As an unreliable protocol, UDP can cause connection slots to be occupied by unstable connections.

Client-side issue

The client fails to connect because the client or the VPN software is not working as expected.

Try to restart the client, or reinstall and reconfigure the VPN software. For more information about how to install and configure VPN software, see Configure a client.

Time out of sync

The time difference between the client and the SSL server is too large, causing SSL verification to fail.

The time difference between the client and the SSL server cannot exceed 10 minutes. Adjust the client's time to synchronize it with a standard time source.

1. Check the current time on the client.

   For example, on a Linux operating system, run the date command to view the current time. If it differs significantly from the standard time, you must adjust it.

2. Synchronize the time by using a Network Time Protocol (NTP) service.

   For example, on a Linux operating system, run the following commands to synchronize the time:

   yum install -y ntp    # Install the NTP service.
   ntpdate pool.ntp.org  # Synchronize the time.
   date                  # Check whether the time is synchronized.

Cause

Solution

The access control policy of the client application blocks ping requests.

Check whether the access control policy of the client application blocks ping requests. If it does, modify the access control policy. For more information, see the user guide of the client.

By default, the firewall of a Windows operating system blocks ping requests. You must modify the inbound rule of the firewall to allow ICMPv4-In.

The operating system firewall on the destination ECS instance is blocking ICMP packets.

If the route entries on the client are correct (you can see the route to the VPC CIDR block by running route print or ip route), but you still cannot ping the ECS instance in the VPC, check the operating system firewall settings on the destination ECS instance:

1. Check the firewalld status: Run systemctl status firewalld. If the output shows active (running), the firewall is active.

2. View the firewall details: Run firewall-cmd --list-all. Check if the icmp-blocks field contains echo-request.

3. Temporarily disable the firewall for verification: Run systemctl stop firewalld and try to ping again. If the ping is successful, the issue is caused by firewalld.

4. Check iptables rules: Run iptables -L INPUT -n to check for any DROP or REJECT rules for ICMP.

5. Check SELinux: Run getenforce. If it is Enforcing, you can temporarily set it to Permissive by running setenforce 0 to check if SELinux is the cause.

6. Verify that the network ACL for the instance's vSwitch allows ICMP traffic through its inbound and outbound rules.

Scenario

Cause

Solution

A client can successfully use the ping command to access the VPC, but the VPC fails when using ping to access the client.

The access control policy of the client application blocks ping requests.

Check whether the access control policy of the client application blocks ping requests. If it does, modify the access control policy. For more information, see the user guide of the client.

By default, the firewall of a Windows operating system blocks ping requests. You must modify the inbound rule of the firewall to allow ICMPv4-In.

Using ping to access the client from the VPC is successful, but using the ping command to access the VPC from the client fails.

The outbound and return traffic paths between the client and the VPC are different.

1. If you use Cloud Enterprise Network (CEN) in your network, check the route configurations of all forwarding nodes between the client and the VPC. Make sure that traffic between the client and the VPC follows the same path in both directions.

2. Check whether the VPC resource, such as an ECS instance, has a public IP address. If the resource has a public IP address and the destination IP address for the traffic from the VPC to the client is a public IP address, traffic may be routed over the Internet instead of the private network.

Cause

Solution

The client has no route to the DNS server, so domain name resolution is unavailable.

1. Add the CIDR block of the DNS server to the Local CIDR Block of the SSL server so that the client can learn the route to the DNS server.

   For example, if you use Alibaba Cloud DNS PrivateZone for domain name management, you can add 100.100.2.136/32 and 100.100.2.138/32 to the Local CIDR Block of the SSL server. This way, the client can use the domain name resolution service.

2. On the client, run the ping or mtr command to test the connectivity to the application. If the connection is normal, the SSL-VPN connection, the client, the server, and the routes are working as expected. In this case, you need to perform further troubleshooting based on the deployed cloud services and the application.

Category

Cause

Solution

Routing issue

The Local CIDR Block of the SSL server is not specified or is incorrectly configured.

1. Check the Local CIDR Block configuration of the SSL server. Ensure that the CIDR block to be accessed by the client is correctly added to the Local CIDR Block of the SSL server. For more information, see Modify an SSL server.

2. Verify that the client has received the routes to the Local CIDR Block of the SSL server.

   • On a Windows client, run the ipconfig command to view the IP address assigned to the client. Then, run the route print command to verify that the client has received the routes to the Local CIDR Block of the SSL server.

   • On a Linux client, run the ifconfig command to view the IP address assigned to the client. Then, run the ip route show all command to verify that the client has received the routes to the Local CIDR Block of the SSL server.

CIDR block configuration issue

The Local CIDR Block overlaps with the Client CIDR Block of the SSL server.

Check the SSL server configuration. Make sure that the Local CIDR Block and the Client CIDR Block do not overlap. For more information, see Modify an SSL server.

The Destination CIDR Block of a route entry for an IPsec-VPN connection on the same VPN Gateway conflicts with the Client CIDR Block of the SSL server.

Change the route entry for the IPsec-VPN connection to a more specific one, or change the Client CIDR Block of the SSL server to a different CIDR block. This prevents the Destination CIDR Block from conflicting with the Client CIDR Block. For more information, see Modify a policy-based route, Modify a destination-based route, or Modify an SSL server.

Security group rule issue

The security group rules of the VPC application or the access control policies of the client application do not allow communication between the client and the VPC.

1. Check the security group rules of the VPC application. Make sure that the security group rules allow traffic between the client and the VPC. For more information, see View security group rules and Add a security group rule.

2. Check the access control policies of the client application. Make sure that the access control policies allow traffic between the client and the VPC.

VPN software issue

Incompatible OpenVPN versions on the client (too old or too new) may prevent the client from receiving or processing response packets from the VPN Gateway.

For example, a Windows client that has OpenVPN 2.6.6 installed may fail to ping cloud resources.

We recommend that you download and use the OpenVPN version provided in the VPN Gateway documentation. For more information, see Configure a client.

Category

Cause

Solution

VPN Gateway specification issue

A traffic burst exceeds the bandwidth of the VPN Gateway instance.

Check the traffic monitoring data of the VPN Gateway instance in the VPN Gateway console for traffic bursts.

You can upgrade the VPN Gateway instance or temporarily upgrade it. For more information, see Upgrade or renew a VPN gateway.

SSL server configuration

The SSL server uses UDP, an unreliable protocol, to establish an SSL-VPN connection with the client.

1. Change the Protocol of the SSL server to TCP. This allows the SSL server to establish a reliable SSL-VPN connection with the client. For more information, see Modify an SSL server.

2. Re-download the SSL client certificate and install it on the client. For more information, see Download an SSL client certificate and Configure a client.

Unreliable public network

The client intermittently disconnects due to poor public network quality between the client and the VPN Gateway.

On the client, run the ping or mtr command to test the network quality from the client to the public IP address of the VPN Gateway.

If the network quality is poor, contact your ISP for assistance.

Category

Cause

Solution

VPN Gateway specification issue

A traffic burst exceeds the bandwidth of the VPN Gateway instance.

Check the traffic monitoring data of the VPN Gateway instance in the VPN Gateway console for traffic bursts.

You can upgrade the VPN Gateway instance or temporarily upgrade it. For more information, see Upgrade or renew a VPN gateway.

Outdated VPN Gateway version

Older VPN Gateway versions have lower forwarding performance, which can cause high latency under heavy traffic.

Upgrade VPN Gateways created before April 1, 2021. Newer versions offer optimized SSL-VPN forwarding performance. For more information, see Upgrade a VPN gateway.