Troubleshooting Access to the Web Interface
Access Server has a web interface consisting of two main components. Learn more about these and how to troubleshoot access.
This topic provides troubleshooting tips for Access Server's web services. For a detailed reference guide on how the web services work, refer to Web Services, which details the difference between the Admin and Client Web UIs. We recommend reading through that first to understand how the web services work and how you reach them.
Note
In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
Ensure you replace them with valid IPv4 addresses and subnets for your network(s).
After initial installation web interface can't be reached
Issue: After installing Access Server, you can't access the Admin or Client Web UIs.
Resolution: We recommend that you begin troubleshooting by checking common causes of why you can’t reach the web interface. Two possible issues are an incomplete initial configuration or finding the correct external IP address.
If an incomplete initial configuration causes the issue, refer to these tips based on your Access Server deployment:
Complete the initial configuration on an AWS instance:
After launching Access Server on an Amazon AWS instance, connect to the instance through SSH using the username openvpnas and the private/public key pair you used to launch the instance. AWS authenticates using SSH keys, not passwords.
Accept the Access Server license agreement and complete the initial configuration. This step is necessary for the web interfaces to become available.
After the configuration, note the randomly generated password for the openvpn administrative account and the addresses for the Admin and Client Web UIs.
Complete the initial configuration of Access Server on a virtual machine (Microsoft Hyper-V or VMWare):
Connect to the virtual machine with the username root and the password openvpnas.
Tip
By default on virtual machines, SSH access for the root account isn’t enabled. If you want to connect with SSH, we recommend creating a user for SSH access and enabling sudo privileges.
Accept the Access Server license agreement and run the initial configuration. You must complete this initial configuration for the Access Server web interfaces to come online.
After the configuration, note the randomly generated password for the openvpn administrative account and the addresses for the Admin and Client Web UIs.
Complete the initial configuration of Access Server on Google Cloud, DigitalOcean, Oracle, or Azure:
Connect to the instance and run the initial configuration for Access Server. How you connect depends on whether you set up access with the cloud provider using a key pair or a username and password.
Accept the Access Server license agreement and run the initial configuration. You must complete this initial configuration for the Access Server web interfaces to come online.
After the configuration, note the randomly generated password for the openvpn administrative account and the addresses for the Admin and Client Web UIs.
For more information about installation on the supported platforms, refer to the Installation topic.
If you’ve completed the initial configuration and can’t connect, verify that you have the correct external IP address.
Complete the initial configuration.
Note the URLs for the Admin and Client Web UIs in the configuration output.
Check that the provided IP address in the URLs is an external IP address.
On some cloud instances, these IP addresses are internal only and cannot be accessed from the internet.
On AWS, you may need to set up an Elastic IP address. We recommend this step to avoid using an auto-assigned public IP address, which can change after a restart of the instance.
If the IP addresses from the initial configuration don’t work, check the IP address of the cloud provider's instance.
For installations in your private network, you may need to ensure you set up a static IP address so that your private IP won't suddenly change when your router or server restarts.
If you still encounter issues, refer to the next section.
Check if the Access Server web services are listening
Access Server must be listening on specific TCP ports for the web services.
Important
We provide instructions specific to Ubuntu/Debian. If you use another Linux system, adjust for that.
Verify that Access Server listens on the correct TCP ports for the web services with the netstat utility:
Connect to your console and get root privileges.
Run netstat to print out the TCP and UDP ports where a program is listening and on what IP addresses:
netstat -tulpn
An output similar to this displays:
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:904 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 127.0.0.1:905 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 127.0.0.1:906 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 127.0.0.1:907 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 127.0.0.1:908 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 127.0.0.1:909 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 192.0.2.3:943 0.0.0.0:* LISTEN 5669/python3 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1084/sshd tcp 0 0 192.0.2.3:443 0.0.0.0:* LISTEN 5683/openvpn-openssl tcp6 0 0 :::22 :::* LISTEN 1084/sshd udp 0 0 192.0.2.3:1194 0.0.0.0:* 5713/openvpn-openssl
Our example output shows that Access Server listens on IP address 192.0.2.3 with various components running. Our example Access Server manages only one TCP and one UDP daemon.
Tip
Access Server's default is to listen on all interfaces. That output would show a line like this;
tcp 0 0 0.0.0.0:943 0.0.0.0:* LISTEN 2383/python3
If the ports Access Server should listen on aren't configured correctly, refer to this tutorial: Set the Interface and Ports for the Web Services.
If you configure Access Server with multiple daemons, the items on ports 443 and 1194 won’t be listed in the netstat output, even though the ports are open; the process lists will also be larger.
Important
When Access Server manages multiple OpenVPN daemons, the program leverages iptables for load-balancing between the processes.
Verify that Access Server listens on the correct TCP ports for the web services with iptables:
Connect to the console and get root privileges.
List the iptables rules that govern internal process load-balancing:
iptables -t nat -L -n | grep "dpt:443"
This line indicates a process listening on port TCP 943:
tcp 0 0 192.168.70.3:943 0.0.0.0:* LISTEN 5669/python
TCP 943 is the default port on which Access Server offers the Admin and Client Web UIs. Compare this to the output of your ifconfig results to see if this IP address is present on your system.
To see which IP addresses are available on your server, run ifconfig:
ifconfig
If our example IP address 192.0.2.3 isn’t present in the ifconfig output, Access Server is listening on the wrong IP address on this system, which must be fixed. Refer to the documentation that shows how to set the IP address and port for your web services through the command line.
If the IP address is present on your system and the process is listening, then continue troubleshooting.
Test locally if the found process is indeed offering the Access Server web services:
wget -O- -q --no-check-certificate https://192.0.2.3:943/ | grep -i -m 1 "OpenVPN" wget -O- -q --no-check-certificate https://192.0.2.3:943/admin | grep -i -m 1 "OpenVPN"
If you successfully reach the web service, these commands return copyright or title text from the hosted pages. Example:
<!-- Copyright (C) 2010-2024 OpenVPN Inc. - http://openvpn.net/ → <title>OpenVPN Login</title>
Verify that you can reach that IP address and port from your computer. Enter the address in your web browser (replacing the example IP address with your server’s external IP address): https://192.0.2.3:943/.
If your Access Server is on a private network behind an internet gateway in your infrastructure, ensure you have port forwarding set up correctly.
Set up port forwarding or NAT forwarding for TCP 443, TCP 943, and UDP 1194.
From our example, the port forwarding goes from the WAN interface to the LAN IP address 192.0.2.3.
Verify this by connecting to your public WAN address from a computer, not inside your private network.
Note
In rare cases, hairpinning or NAT reflection doesn’t work for certain routers. This causes the situation where you can’t access services on your public WAN IP—from inside the LAN—that port forward to a server in your LAN.
We recommend assigning an elastic IP address for Access Server launched through Amazon AWS for the following reasons:
An elastic IP address is a public IP attached to your AWS instance.
AWS relays connections to the public IP automatically and transparently to your AWS instance’s internal private IP address.
Determine the correct public IP to connect to your web services for AWS instances:
Sign in to your Amazon AWS console.
Allocate an Elastic IP address to the EC2 instance with Access Server.
Use the Elastic IP address to reach your Admin and Client Web UIs.
If you’ve allocated an Elastic IP address for Access Server on an AWS instance but still can’t connect, review the security groups.
Sign in to your Amazon AWS console.
Ensure that the security groups—which work like a firewall on Amazon—allow incoming traffic on these ports:
TCP 22 (SSH)
TCP 443 (web interface)
TCP 943 (web interface)
TCP 945 (API port for clustering feature)
UDP 1194 (UDP port for client communication)
Allow all outgoing traffic.
Using TCPdump to test connectivity from outside
You can use the program tcpdump to help troubleshoot issues connecting to the web services.
You can use tcpdump to listen to requests on a specific port and IP address on your system server and see what those are.
Connect to your console and get root privileges.
Install tcpdump:
apt update apt install tcpdump
Run tcpdump and listen on the specified IP and port (from our example, 192.0.2.3 on port 943 TCP):
tcpdump -eni any "dst host 192.0.2.3 and port 943 and tcp"
While this is running, any activity on that IP and port displays.
Trigger some sample output by rerunning the local wget test to see if your tcpdump monitoring process is working:
wget -O- -q --no-check-certificate https://192.0.2.3:943/ | grep -i -m 1 "OpenVPN"
This should give an output similar to our example:
20:57:54.588184 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 76: 192.0.2.3.46136 > 192.0.2.3.943: Flags [S], seq 1799812121, win 43690, options [mss 65495,sackOK,TS val 19185213 ecr 0,nop,wscale 7], length 0 20:57:54.588201 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 68: 192.0.2.3.46136 > 192.0.2.3.943: Flags [.], ack 907672144, win 342, options [nop,nop,TS val 19185213 ecr 19185213], length 0 20:57:54.589026 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 373: 192.0.2.3.46136 > 192.0.2.3.943: Flags [P.], seq 0:305, ack 1, win 342, options [nop,nop,TS val 19185213 ecr 19185213], length 305 20:57:54.590206 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 68: 192.0.2.3.46136 > 192.0.2.3.943: Flags [.], ack 2001, win 1365, options [nop,nop,TS val 19185214 ecr 19185214], length 0 20:57:54.590750 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 194: 192.0.2.3.46136 > 192.0.2.3.943: Flags [P.], seq 305:431, ack 2001, win 1365, options [nop,nop,TS val 19185214 ecr 19185214], length 126 Etcetera
This establishes that tcpdump is listening on the specified port and IP address.
Enter the Admin Web UI address, for example, https://192.0.2.3:943/.
If the web services open successfully, you see an output similar to this:
21:01:05.968700 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 617: 192.0.2.186.63233 > 192.0.2.3.943: Flags [P.], seq 6064:6625, ack 146791, win 2051, length 561 21:01:05.970575 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 62: 192.0.2.186.63233 > 192.0.2.3.943: Flags [.], ack 150440, win 2053, length 0 21:01:05.994020 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 605: 192.0.2.186.63233 > 192.0.2.3.943: Flags [P.], seq 6625:7174, ack 150440, win 2053, length 549 21:01:05.995930 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 62: 192.0.2.186.63233 > 192.0.2.3.943: Flags [.], ack 165040, win 2053, length 0 21:01:05.996881 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 583: 192.0.2.186.63233 > 192.0.2.3.943: Flags [P.], seq 7174:7701, ack 166412, win 2047, length 527 etcetera
If, however, the web services don’t open, but I reach the server at the specified IP and port, the output looks similar to this:
21:03:56.046032 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 68: 192.0.2.186.63255 > 192.0.2.3.943: Flags [S], seq 4052604850, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 21:03:56.310601 In 00:0c:29:18:e8:2c ethertype IPv4 (0x0800), length 68: 192.0.2.186.63256 > 192.0.2.3.943: Flags [S], seq 3849647674, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
If you can reach the server at the specified IP and port, but the web services don’t open, the iptables firewall rules on the Access Server operating system block access.
Refer to the firewall solution installed on your system’s operating system.
Allow traffic to pass through the firewall to the correct port.
Note
If the tests with tcpdump show the web services accessible from inside the network and requests from an external web browser can reach the system but not the web services, you likely have a firewall issue.
If Access Server web interfaces don’t respond, refer to this tutorial:
Why does Access Server use TCP 443 and TCP 943 ports?
Purpose of using TCP 443:
Firewall Compatibility: Many public networks block traffic on all ports except a few (e.g., HTTP, HTTPS, FTP, email). By running OpenVPN on TCP 443 (the default port for HTTPS), VPN connections can bypass these restrictions.
Fallback for UDP Blockage: OpenVPN works best over UDP (default port 1194), but if UDP is blocked, TCP 443 can be used as an alternative.
Purpose of using TCP 943:
Web Services Availability: Since TCP 443 is used for the OpenVPN TCP daemon, the web services (Admin and Client Web UIs) run on TCP 943. This can be accessed via https://vpn.yourserver.com:943/.
Benefits of port sharing:
Simplified User Access: Allows users to connect to https://vpn.yourserver.com/ without specifying port 943.
Functionality: The OpenVPN TCP daemon on TCP 443 can differentiate between VPN connections and web browser requests, forwarding the latter to web services.
Turning off port sharing: Disables the transparent forwarding mechanism, requiring users to specify port 943 in the URL.
Sign in to the Admin Web UI.
Click Configuration > Network Settings.
Turn off port sharing under Web Service forwarding settings.