Error: TLS Error: TLS key negotiation failed to occur within 60 seconds
OpenVPN may display the error message "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" in the OpenVPN log if is unable to connect to the remote VPN server. The 60 second value may vary (for example, 30 seconds) depending on the configuration.
Troubleshooting for Viscosity Users
Viscosity performs a "reachability check" before attempting to connect a VPN connection. This check allows Viscosity to determine whether the remote VPN server can theoretically be reached over the network so a connection can be established. As this check is passing it means the fault is unlikely to lie with your computer. It is more likely one of the following is the case:
- The remote VPN server is down or unavailable. You will need to get in touch with your VPN Provider to check on the VPN server's status. If you are unsure of who your VPN Provider is, please see How Do I Find Out Who My VPN Provider Is?.
- You are being blocked from contacting the remote VPN server. This is not uncommon in countries that attempt to censor the Internet, or in some workplaces for security reasons. It is recommended you get in contact with your VPN Provider in this instance as well.
- Your connection's configuration details may be incorrect or out of date. If you have set up the connection yourself, you should edit your connection in Viscosity and check that the Remote Server Address, Port, and Protocol options are correctly set. Some VPN Providers may periodically update their VPN servers, so you may need to download updated connections to import. Again, you will need to get in contact with your VPN Provider to ensure your configuration details are correct and up to date.
Troubleshooting for VPN Providers
If you're the administrator of a VPN server and have a user encountering this error (and you're sure the OpenVPN server is operational), here are some troubleshooting tips for common mistakes:
- Check the OpenVPN log on the server. If the server is rejecting the client's connection or authentication attempt the reason should be logged here. If there is no indication of a connection attempt in the log, make sure that a firewall or router isn't blocking access to the OpenVPN server. Check both local firewall rules, as well as firewall and port-forwarding rules on any routers.
- When checking the connection log in Viscosity, look for "VERIFY ERROR" or "OpenSSL: error" messages. These typically indicate that the client was unable to validate the server and hence it is rejecting the connection attempt. More information should be available as part of the message. These typically indicates a CA/Certificate mismatch between the server and the client.
- When checking the connection log in Viscosity, if there are no error messages indicated in the point above, instead check the time difference between the "UDP link remote" message and the "TLS Error: TLS key negotiation failed to occur within 60 seconds". If the failure happens quickly, then in most instances it means that a network link was established however the server has rejected the client. More information about why should be available in the server's OpenVPN log.
- Make sure both the OpenVPN server and client are using the correct Certificate Authority (CA) file. If this file is incorrect, or there is a mismatch between the client and server, the TLS session will be rejected by the server or client.
- Make sure that the client is using a valid certificate and key. A common cause of this error message is the server being updated with new CA/Cert/Key files, however clients not also being updated. Also check that the user's certificate hasn't expired.
- Make sure that the "Use Username/Password authentication" checkbox is properly configured on the client. Enabling this when it's not required by the server, or disabling it when it is required, can cause connection attempts to fail.
- Make sure that compression settings on both the server and client match. OpenVPN changed the compression options in OpenVPN 2.4, and so this is a common problem with servers running an older version of OpenVPN. More information can be found in the Migrating from OpenVPN 2.3 to OpenVPN 2.4 article.