Troubleshooting Client VPN Connectivity with Access Server
Troubleshoot connectivity issues between VPN clients and Access Server, your VPN server.
Important
This page helps you troubleshoot problems with an OpenVPN client program failing to connect to Access Server. It doesn't address problems reaching a target system once you've established the VPN connection. For help, refer to VPN Destination.
Overview
Here, you can find help resolving connectivity issues between OpenVPN clients and Access Server, such as an error when making a connection that disconnects an end user.
Here, we provide tips on locating log files and known error messages with possible solutions.
Locating log files
It's helpful to review log files for diagnosing problems. Access Server and our OpenVPN client program, OpenVPN Connect, store log files on their machines.
Access Server stores log files in this directory: /var/log/. Look for the openvpnas.log file there.
If you have a failover setup, you'll find the log files named openvpnas-node.log.
Tip
If you're encountering issues starting Access Server or portions of it, such as the web services, you can try stopping the Access Server service, moving the log file aside, restarting the service, and stopping it again immediately.
This creates a new, clean log file containing the startup and shutdown Access Server sequences without extraneous information, making your log file easier to analyze. Use these commands to do this:
service openvpnas stop mv /var/log/openvpnas.log /var/log/openvpnas.log.old service openvpnas start service openvpnas stop
Grab the /var/log/openvpnas.log file for analysis and start the service again:
service openvpnas start
To locate VPN client log files, use the location below that matches the operating system.
Log file path: C:\Users\<Username>\AppData\Roaming\OpenVPN Connect\log. Double-click to open ovpn.log.
Notice
If you're using the older client, OpenVPN Connect v2, this is the log file path: C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\etc\log.
The log file path is /Users/<your username>/Library/Application Support/OpenVPN Connect/log/. There you'll find the log, ovpn.log.
Tip
On macOS, the folder may be hidden. If needed, follow these steps:
Open Finder.
From the top menu, click Go > Go to folder.
Enter the path /Library.
You can then navigate to the log file path.
Once you've located the log file, OpenVPN Connect on macOS has permissions set on it, so you can't normally open it. To bypass that, follow these steps:
Right-click on ovpn.log.
Click Get info.
Click Sharing & Permissions.
Click the yellow padlock icon to unlock the settings and give everyone read access.
Close the window.
Right-click again on ovpn.log.
Click Open with.
Choose a text editor to view the contents.
Known error messages and possible solutions
The following are known error messages. Expand the section for possible solutions to resolve the error. If you need more support, send us a support ticket.
A variety of situations could cause this error message. One possibility is an old client program that only supports TLS 1.0, but Access Server expects TLS 1.2 or higher. To check if this is the case:
Find your Access Server log file (refer to the above section that explains this).
If the error is due to an older VPN client, you'll find a message in the log similar to this:
OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol' TLS_ERROR: BIO read tls_read_plaintext error' TLS Error: TLS object -> incoming plaintext read error' TLS Error: TLS handshake failed' SIGUSR1[soft,tls-error] received, client-instance restarting'
To resolve this issue, upgrade to the latest OpenVPN Connect version.
Another possible reason for this error is the TLS minimum requirement level setting. This error may display if you've changed TLS settings in Access Server, but the OpenVPN client uses an older connection profile with incorrect instructions. TLS settings must match between Access Server and the client.
To resolve this issue, install a new copy of the configuration profile.
A final possibility is a firewall blocking access or an internet service provider somehow interfering with the TLS handshake.
This error message means the negotiated TLS key used on the client side for encryption/decryption differs from the server side.
Initially, the client and server negotiate and agree upon a TLS key for encrypting and decrypting traffic. By default, Access Server renegotiates after six hours. That means that a TLS refresh kicks in, and the server and client agree upon a new key. There's a short overlap when the old and new keys are accepted until the old key expires. If one side doesn't go through this process, this error message displays.
A possible cause is an OpenVPN protocol bug in OpenVPN Connect that was resolved — the automatic TLS key refresh failed because the client and server couldn't properly agree on the encryption cipher to use.
To resolve this issue, upgrade to the latest OpenVPN Connect version.
We recommend you update if you're not running the latest Access Server version. You can then download OpenVPN Connect from your Client Web UI with the latest versions and bundled connection profiles.
If you're using other VPN client software, try to find and update to the latest version.
A final solution may be to change the TLS key refresh to something larger in the Advanced VPN page of the Admin Web UI; however, that lowers security.
This error message occurs when Acess Server can't be reached at the specified port.
When OpenVPN Connect tries to start a connection with Access Server, it sends a message requesting a reply. If the server doesn't respond, this error message is displayed. There are several possible solutions you can try to resolve this:
Check that the port is open. Security or firewall settings could be blocking it. By default, Access Server requires three ports to be reachable: TCP 443, TCP 943, and UDP 1194.
Check that the port is correct. Make sure you're not trying an incorrect port.
Check that the address is reachable via the internet. For instance, don't use a private IP address.
Set up a proper FQDN DNS name. You can set up Access Server to use a proper FQDNS name. Configure this in the Admin Web UI. Refer to Hostname for details.
If using an FQDN DNS name, ensure it's assigned to a public IP address. If your DNS A record points to a private IP address, that's inaccessible.
Access Server uses a session-based-token system for server-locked and user-locked profiles, not auto-login profiles. After a user authenticates with a server-locked or user-locked profile, they're given a session token to identify themselves. Each session token is unique and uniquely identifies the connection. This avoids storing credentials in the memory or requiring the user to authenticate if they temporarily lose contact with the server.
For security, the session token can be locked to the IP address where the original authentication attempt originated. This message displays when the session token offered by the client was generated from a different IP address. This might happen if, for example, you switch internet connections, like moving your laptop home, and the VPN client tries to reconnect automatically with the session token.
You can remove the session token IP lock if it's been turned on by running these commands:
./sacli --key "vpn.server.session_ip_lock" --value 'false' ConfigPut ./sacli start
Access Server uses a session-based-token system for server-locked and user-locked profiles, not auto-login profiles. After a user authenticates with a server-locked or user-locked profile, they're given a session token to identify themselves. Each session token is unique and uniquely identifies the connection. This avoids storing credentials in the memory or requiring the user to authenticate if they temporarily lose contact with the server.
By default, the session token expires after five minutes of inactivity when not connected to the server and after 24 hours.
You can adjust session token settings if needed. Refer to How to Adjust Access Server's Session Tokens.
You can also switch to an auto-login profile that doesn't use the session tokens.
You may encounter this session ID related error message in the Connect logs and also shown in the popup message in Windows or macOS when you use OpenVPN Connect for Windows or macOS. This error message indicates that a server-locked connection profile is being used, which is the default on Access Server when you download and install OpenVPN Connect. A server-locked connection profile is designed to be user-agnostic, meaning it doesn't carry any user-identifiable information, and is a sort of a universal profile. This allows any valid user account to start a connection with OpenVPN Connect. The credentials are passed over a secure HTTPS channel to the XML-RPC services of the Access Server for verification, and if approved, the client will receive a copy of the user-locked profile for this user, and a session token. Those will be used to start the OpenVPN tunnel. After the tunnel is disconnected, the user-locked profile and session token are deleted. But for this to work, there must be a working HTTPS connection to the web services of the Access Server.
This could indicate that OpenVPN Connect can reach some services but has issues with the Access Server web services or that a firewall or proxy solution is mangling traffic.
We've seen situations where Access Server is installed with default settings, OpenVPN Connect is installed and working, and then the port was changed on the server system from TCP 443 to TCP 444 where there was another web server on that same server system with an HTTPS website running on port TCP 443. OpenVPN Connect didn't receive an update to the new Access Server port settings, so it tries to talk to the old port where a different web server runs.
If you encounter this problem, investigate if the port the client is trying to reach is reachable by the client and if it's where the Access Server web services are running. Then you may need to reinstall connection profiles or OpenVPN Connect to update settings.
This indicates that the address and port that OpenVPN Connect is trying to reach doesn't have an Access Server web service running there. This can sometimes occur if your server address is misconfigured.
To resolve this, ensure you've configured your server address correctly:
Sign in to the Admin Web UI.
Click Configuration > Network Settings.
Check the field for Hostname or IP Address.
This address should be publicly reachable. We recommend using a DNS name instead of an IP address.
After checking this, download and install OpenVPN Connect on your client computers.
This indicates that the Access Server web service's XML-RPC interface is unreachable. OpenVPN Connect uses this interface to obtain the necessary certificates and configuration to start the OpenVPN connection when you are using a server-locked profile. You don't need the XML-RPC interface when you use user-locked or auto-login profiles. The advantage of server-locked profiles is that they are universal — any valid Access Server user can sign in and connect. The timeout error means the connection timed out, usually a firewall is blocking the connection.
To resolve this, ensure the web interface is reachable from this OpenVPN client, or use a user-locked or auto-login type profile.
This error message may occur if the XML-RPC/REST API interface is disabled.
By default, OpenVPN Connect uses server-locked profiles. These contain only the information necessary to talk to Access Server's XML-RPC web interface to authenticate a user and obtain the required certificates and connection information to start the OpenVPN tunnel. This is done so this client is universal. It works for all valid users on the server and isn't locked to a specific user. This does require that the web interface is reachable. To check the functionality of the XML-RPC interface:
Sign in to the Admin Web UI.
Click Configuration > CWS Settings.
Set Configure XML-RPC/REST API to Enable limited API (default) or Enable complete API.
You can also stop using server-locked profiles and switch to user-locked or auto-login profiles.
This indicates that the serial number isn't found in the database, which means the server doesn't recognize the certificate.
By default, Access Server comes with an internal PKI structure, which means a self-signed root certificate with unique certificates generated for each OpenVPN client for that server. These are all unique and tied together. This is part of the strength of OpenVPN, the identity of a VPN client and a VPN server are verified in both directions when making a connection: the client verifies the server, and the server verifies the client. So, for each user account you add to Access Server, a unique certificate is generated. The certificate is bound to the user account name, so you can't log in with the credentials for user Bob with the certificates for user Billy. Each certificate also has a serial number, a unique number identifying the certificate. You may be using a certificate from a completely different Access Server by mistake, or maybe you started with a new setup of Access Server on your server, and the certificates are wiped and new ones generated for the new setup while you're still using old certificates from the previous installation.
To resolve this problem, make sure to delete the wrong connection profile from your client computer and obtain a new one from your current Access Server installation and use that to connect.
This error can occur when the OpenVPN Connect 3.x server stops or doesn't resume when you sign back into the computer.
This error message occurs more often on macOS systems. In the past, this was caused by antivirus programs, but most don't flag OpenVPN Connect app as a threat anymore. It may still happen with very aggressive and unorthodox security settings configured with an antivirus program.
For troubleshooting, refer to this support link.