Skip to main content

Fix VPN Connection Issues Between OpenVPN Connect and Access Server

Abstract

Diagnose and fix VPN connection issues in Access Server. Covers TLS, authentication, routing, and DNS errors for OpenVPN Connect.

๐Ÿ“ Purpose

Use this guide to diagnose and fix issues when OpenVPN Connect can't connect to your Access Server.

You'll learn where to find logs, how to identify common errors, and the steps to resolve them.

Important

If your VPN connects successfully, but you can't reach network resources afterward, refer to VPN Destination.

๐ŸŒ 1. Check your environment

Before troubleshooting:

  1. Confirm the client device has internet access.

  2. Ensure your Access Server is running and reachable.

    Protocol

    Port

    Purpose

    TCP

    443

    Web services & XML-RPC

    TCP

    943

    Admin Web UI

    UDP

    1194

    OpenVPN data channel

  3. Download fresh connection profiles after reinstalling or upgrading Access Server.

Check

Command/Action

Access Server service status

sudo service openvpnas status

Server IP / DNS resolves

ping <your-server-hostname>

Ports open (default 443 or 1194)

sudo netstat -tuln

๐Ÿ“‚ 2. Review log files

If the VPN connection fails, check logs on both the server and client.

System

Log Location

Notes

Access Server

/var/log/openvpnas.log

Contains connection attempts, auth errors, and TLS negotiation info.

OpenVPN Connect Windows app

C:\Users\<Username>\AppData\Roaming\OpenVPN Connect\log

Double click to open ovpn.log.

OpenVPN Connect macOS app

/Users/<your username>/Library/Application Support/OpenVPN Connect/log/

Use the Console app to open the ovpnagent.log.

Tip

Look for lines starting with ERROR: or TLS:, which indicate handshake or authentication problems.

Tip

If Access Server or its web services won't start properly, you can create a fresh log that only contains startup and shutdown details:

systemctl stop openvpnas
mv /var/log/openvpnas.log /var/log/openvpnas.log.old
systemctl start openvpnas
systemctl stop openvpnas

Then, analyze the clean log:

cat /var/log/openvpnas.log

Finally, restart Access Server:

systemctl start openvpnas

โš ๏ธ 3. Common error messages and fixes

Expand each section below to find causes and recommended resolutions.

Cause:

  • Client is using an outdated TLS version (e.g., TLS 1.0).

  • TLS level mismatch between client and server.

  • Firewall/ISP interference.

Fix:

  1. Check the Access Server log file for lines like:

    OpenSSL: error:140760FC: SSL routings:SSL23_GET_CLIENT_HELLO:unknown protocol
  2. If TLS settings were changed on the server, install a fresh connection profile to update client TLS parameters.

  3. Verify ports (UDP 1194/TCP 443) aren't blocked by a firewall or ISP.

Cause: The negotiated TLS key for encryption/decryption differs between client and server, often due to a renegotiation issue or cipher mismatch.

Fix:

  1. Upgrade to the latest OpenVPN Connect and Access Server.

  2. If necessary, extend the TLS key renegotiation interval in the Admin Web UI.

    Important

    Extending TLS renegotiation reduces security.

Cause: Access Server can't be reached at the specified port.

Fix:

  1. Verify required ports are open:

    • TCP 443

    • TCP 943

    • UDP 1194

  2. Confirm you're connecting to the correct port and reachable address.

  3. Configure a valid FQDN for your Access Server's hostname.

  4. Ensure the DNS points to a public IP address.

Cause: Invalid credentials or expired session token.

Fix:

  1. Verify the username and password.

  2. If using SAML or LDAP, confirm the user account is active.

  3. Delete the connection profile from OpenVPN Connect and download a new one from the Client Web UI.

Cause: Session tokens for server-locked and user-locked profiles expire after inactivity (five minutes) or 24 hours, by default.

Fix:

  1. Adjust the token lifetime. Refer to Session Tokens.

  2. Or switch to an auto-login profile, which doesn't use tokens.

Cause: Session timeout or token reuse.

Fix:

  1. Reconnect and re-authenticate.

  2. If the issue persists, the admin can reset the session via the command line:

    ./sacli --user <username> --deactivate-sessions

Cause: If session tokens are IP-locked for security, this message displays when the session token offered by the client was generated from a different IP. If your IP changes (e.g., switching networks), the old token becomes invalid.

Fix: You can disable session IP locking via CLI if needed:

./sacli --key "vpn.server.session_ip_lock" --value 'false' ConfigPut
./sacli start

Cause: Routing or NAT configuration issue.

Fix:

  1. Check Access Server's Routing and NAT settings.

  2. Ensure correct subnets are defined in the Admin Web UI Subnets.

  3. Confirm the client's local firewall allows routed traffic.

  4. Test DNS resolution (try nslookup openvpn.net while connected).

Cause: Expired certificate or incorrect hostname.

Fix:

  1. Verify Access Server SSL certificate validity.

  2. Reinstall or update the SSL Certificate in the Admin Web UI.

  3. If using a custom domain, update the server's hostname configuration.

Variant A: Generic failure

Cause: Indicates a server-locked profile was used, but web services weren't reachable.

Fix:

  • Verify that Access Server web services run on the expected port.

  • Update or reinstall connection profiles if the port has changed.

Variant B: Other SSL errors, such as SSL23_READ ssl handshake failure

Cause: Client connecting to wrong host or port.

Fix:

  1. Verify that Access Server web services run on the expected port.

  2. Update or reinstall connection profiles if the port has changed.

Variant C: ConnectionRefusedError: 10061

Cause: Client connecting to the wrong host or port.

Fix:

  1. Check the server hostname/IP in the Admin Web UI.

  2. Ensure it's reachable from the internet.

  3. Download new profiles.

Variant D: XML-RPC: TimeoutError

Cause: XML-RPC interface is unreachable.

Fix:

  • Confirm the firewall allows traffic on port 443.

  • Use a user-locked or auto-login profile if the XML-RPC interface must remain closed.

Variant E: XML-RPC function GetSession may not be called at the configured relay level

Cause: XML-RPC/REST API interface disabled.

Fix:

  1. Sign in to the Admin Web UI.

  2. Click Configuration > CWS Settings.

  3. Under Configure XML-RPC/REST API, select:

    • Enable limited API or

    • Enable complete API.

Cause: Certificate mismatch โ€” client uses an outdated certificate not present in the current PKI.

Fix:

  • Download the old profile.

  • Download a new one from your current Access Server instance.

Cause: The OpenVPN Connect service stopped or didn't resume after login (common on macOS or strict antivirus setups).

Fix:

๐Ÿงช 4. Advanced diagnostics

For deeper investigation:

  • Run packet capture:

    sudo tcpdump -i eth0- port 1194 -nn
  • Check iptables/nftables rules for dropped packets:

    sudo iptables -L -n

    or

    sudo nft list ruleset
  • Enable verbose logging in Access Server for detailed output:

    ./sacli --key "log_level" --value 7 ConfigPut
    ./sacli start

๐Ÿงญ 5. If you still can't connect

Try these next steps:

  1. Test with a fresh profile downloaded from the Client Web UI.

  2. Try another network (mobile hotspot or home connection).

  3. Temporarily disable the antivirus or local firewall to isolate the cause.

  4. Review known issues in your version's release notes.

  5. Reach out to our support team.