Tutorial: Test and Troubleshoot Access Server Cluster Connectivity⁠

First, confirm that your computer can reach the Admin Web UI on each cluster node. These tests validate administrative web connectivity and are separate from VPN client connectivity.

Access Server uses TCP port 943 for web services by default. Replace the port in the examples if your deployment uses a different value.

Confirm that each cluster node is configured to use the expected Admin Web UI port and is listening for connections on that port.

Access Server includes sacli, its command-line administration utility. For an introduction to the tool and its syntax, refer to Tutorial: An Intro to the sacli Command-Line Utility.

1. Connect to the console and get root privileges.

2. Verify the Admin Web UI port configured:

   sacli ConfigQuery | grep admin_ui.https.port

   • Example output:

     "admin_ui.https.port": "943"

3. Verify that Access Server is listening on the configured port:

   netstat -tulpn | grep 943

   • Example output:

     tcp        0      0 0.0.0.0:943             0.0.0.0:*               LISTEN      699419/python3

4. If netstat isn't installed, install the net-tools package:

   • Ubuntu/Debian:

     apt install net-tools

   • RHEL:

     dnf install net-tools

5. Verify that iptables/nftables rules exist for that Admin Web UI port.

   1. If the host uses iptables, run:

      iptables-save -c | grep '943'

      • Example output:

        [6:336] -A INPUT -p tcp -m state --state NEW -m tcp --dport 943 -j AS0_WEBACCEPT

   2. If the host uses nftables, run:

      nft -a list chain ip as_filter INPUT | grep 943

      • Example output:

        counter packets 91448 bytes 4634926 ct state new tcp dport 943 jump AS_WEBACCEPT # handle 63

   3. Repeat these checks on every cluster node.

Access Server 3.0.0 and newer use the Admin Web UI port for cluster communication. The default is TCP 943. Earlier releases used TCP 945.

1. Verify that traffic to the configured web service port is allowed through any host firewall, cloud security group, network firewall, or router between the cluster nodes.

2. Verify the Admin Web UI port configured:

   sacli ConfigQuery | grep admin_ui.https.port

   • Example output:

     "admin_ui.https.port": "943"

3. Run the following on either cluster node to verify that the api_endpoint has the Admin Web UI port:

   sacli --method GET --url 'api/cluster/nodes/list' --value '{}' apicall

   • Example output:

     {
       "nodes": {
         "Node1": {
           "api_endpoint": "https://198.51.100.5:943",
           "certificate_fingerprint": "50:05:D6:08:98:81:16:A1:BE:CC:CD:61:3D:DC:AD:95:A0:8F:1D:72:32:A5:19:2E:99:D1:0D:DD:76:10:98:32",
           "name": "Node1",
           "restart_pending": false
         },
         "Node2": {
           "api_endpoint": "https://198.51.100.6:943",
           "certificate_fingerprint": "50:05:D6:08:98:81:16:A1:BE:CC:CD:61:3D:DC:AD:95:A0:8F:1D:72:32:A5:19:2E:99:D1:0D:DD:76:10:98:32",
           "name": "Node2",
           "restart_pending": false
         }
       }
     }

4. Confirm that each api_endpoint contains the correct IP address or hostname and web service port for that cluster node.

5. Test TCP connectivity between the nodes:

   • From Node1, test connectivity to Node2:

     nc -z -v 198.51.100.6 943

   • Example output:

     Connection to 198.51.100.6 943 port [tcp/*] succeeded!

   • From Node2, test connectivity to Node1:

     nc -z -v 198.51.100.5 943

   • Example output:

     Connection to 198.51.100.5 943 port [tcp/*] succeeded!

6. Ensure both tests succeed for reliable inter-node communication.

7. If an API endpoint contains an incorrect address or port, update it with the following remote API call:

   sacli --method POST --url 'api/cluster/<NODE_NAME>/set' --value '{"api_endpoint": "https://<ACCESS_SERVER_IP>:<ACCESS_SERVER_PORT>"}' apicall

8. Restart the Access Server services:

   sacli --method POST --url 'api/server/restart?restartMode=warm' --value '' apicall

9. Repeat the node list and TCP connectivity tests after the restart.

Use sacli to confirm that all cluster nodes are registered and reachable.

1. View the configured cluster nodes:

   sacli ClusterQuery

   • Example output:

     {
       "Node1": {
         "api_endpoint": "https://198.51.100.5:943",
         "certificate_fingerprint": "58:DF:12:B8:D1:A7:D4:F2:77:23:9F:5E:D6:69:B2:55:10:5F:6B:BF:6E:6D:CC:E9:1B:92:93:30:28:9B:C0:A6",
         "name": "Node1"
       },
       "Node2": {
         "api_endpoint": "https://198.51.100.6:943",
         "certificate_fingerprint": "58:DF:12:B8:D1:A7:D4:F2:77:23:9F:5E:D6:69:B2:55:10:5F:6B:BF:6E:6D:CC:E9:1B:92:93:30:28:9B:C0:A6",
         "name": "Node2"
       }
     }

2. Confirm that every expected cluster member appears with the correct API endpoint.

3. View the runtime status of the cluster nodes:

   sacli ClusterNodesStatus

   • Example output:

     {
       "Node1": {
         "activation_type": "Not Activated",
         "api_endpoint": "https://198.51.100.5:943",
         "as_build": "e22fe316",
         "as_version": "3.1.0 (e22fe316)",
         "auth": "local",
         "certificate_fingerprint": "58:DF:12:B8:D1:A7:D4:F2:77:23:9F:5E:D6:69:B2:55:10:5F:6B:BF:6E:6D:CC:E9:1B:92:93:30:28:9B:C0:A6",
         "cipher": "AES-256-CBC",
         "current_users": 0,
         "license": "2",
         "name": "Node1",
         "osi_layer": "3 (routing/NAT)",
         "restart_pending": false,
         "server_name": "198.51.100.5",
         "status": "reachable",
         "user_data": {
           "n_clients": 0,
           "ovpn_dco_available": true,
           "ovpn_dco_ver": "ovpn-dco version 0.2.20251017-2+noble"
         },
         "vlis": "all interfaces",
         "vpn_port": "tcp/443, udp/1194",
         "vserv_priv_access": "NAT"
       }
     }

4. Confirm that each cluster node reports:

   • The expected API endpoint.

   • The expected Access Server version.

   • "status": "reachable".

   • No unexpected pending restart.

   • The expected VPN ports and routing mode.

Use this procedure to confirm that a remote client can authenticate to the Web API and call API endpoints on an individual cluster node.

1. Generate an authentication token for an admin user using cURL (ensure the account has administrative privileges):

   curl -X 'POST' 'https://198.51.100.5:943/api/auth/login/userpassword' -H 'accept: */*' -H 'Content-Type: application/json' -d '{"request_admin": true, "username": "<ADMIN_USERNAME>","password": "<ADMIN_PASSWORD>"}' -k

   • Example output:

     {
       "auth_token": "<AUTH_TOKEN>",
       "expires_after": "2025-10-23T21:00:23.000000Z",
       "renewable_until": "2025-10-24T00:50:23.000000Z",
       "user_properties": {
         "user_type": "admin",
         "username": "openvpn"
       }
     }

2. Use the token to call the following endpoints on each cluster node:

   curl -k -v "https://<ACCESS_SERVER_IP>:943/api/config-profile/list" -H "x-openvpn-as-authtoken: <AUTH_TOKEN>"

   curl -k -v "https://<ACCESS_SERVER_IP>:943/api/server/config" -H "x-openvpn-as-authtoken: <AUTH_TOKEN>"

   curl -k -v "https://<ACCESS_SERVER_IP>:943/api/license/info" -H "x-openvpn-as-authtoken: <AUTH_TOKEN>"

   curl -k -v "https://<ACCESS_SERVER_IP>:943/api/helper/status-overview" -H "x-openvpn-as-authtoken: <AUTH_TOKEN>"

3. Repeat the calls using the IP address or hostname of each cluster node.

   • Successful responses confirm that the remote client can reach and authenticate to the Web API on the tested node.

Use sacli apicall to call API endpoints locally on a cluster node.

1. Run the following commands to call API endpoints directly from a node:

   sacli --method GET --url "api/config-profile/list" apicall

   sacli --method GET --url 'api/server/config' apicall

   sacli --method GET --url 'api/license/info' apicall

   sacli --method POST --url 'api/helper/status-overview' apicall

   • Successful responses confirm that the local Access Server service can process the API calls.

2. Use ClusterRPC to route a remote API call through the cluster communication layer, even when targeting the node from which you run the command:

   1. For example, from Node1, run:

      sacli --node_name "Node1" --method GET --url '/api/server/info' ClusterRPC

      sacli --node_name "Node1" --method GET --url '/api/server/config' ClusterRPC

      sacli --node_name "Node1" --method GET --url '/api/license/info' ClusterRPC

      sacli --node_name "Node1" --method POST --url '/api/helper/status-overview' ClusterRPC

   • These tests help distinguish a local Web API failure from a ClusterRPC or inter-node communication failure.

Use ClusterRPC to execute API calls on one cluster node from another cluster node.

1. Run the following commands from Node1 to execute API calls on Node2:

   sacli --node_name "Node2" --method GET --url '/api/server/info' ClusterRPC

   sacli --node_name "Node2" --method GET --url '/api/server/config' ClusterRPC

   sacli --node_name "Node2" --method GET --url '/api/license/info' ClusterRPC

   sacli --node_name "Node2" --method POST --url '/api/helper/status-overview' ClusterRPC

2. Repeat the test in the opposite direction by running the commands on Node2 and setting --node_name to Node1.

   • Successful calls in both directions confirm that:

     • Each node can reach the other node's API endpoint.

     • Inter-node TLS communication succeeds.

     • ClusterRPC can route and process remote API calls.

     • The cluster communication path required for coordinated operations is functioning.

The previous steps verify administrative, Web API, and inter-node connectivity. They don’t confirm that VPN clients can connect successfully through the cluster.

To test VPN client connectivity:

1. Import a valid connection profile into OpenVPN Connect or another supported VPN client.

2. Connect using the round-robin DNS hostname.

3. Confirm that the VPN connection succeeds.

4. In the Admin Web UI, select Status → Active Connections.

5. Identify the cluster node handling the connection.

6. Disconnect and reconnect the VPN client several times.

7. Confirm that the client can connect successfully when directed to either cluster node.

These tests help verify that DNS distribution, VPN listener ports, certificates, authentication, and routing are working across the cluster.