Troubleshooting access to the web interface

Upgrade to Latest Version

Introduction

This document provides troubleshooting tips for the web services with OpenVPN Access Server. For a detailed reference guide on how the web services work, refer to OpenVPN Access Server Web Services, which details the difference between the Admin Web UI and Client Web UI. We recommend reading through that first to understand how the web services work and how you reach them.

Troubleshooting connection problems:

After initial installation web interface cannot be reached

We recommend that you begin troubleshooting by checking common causes for why you can’t reach the web interface.

Verify you’ve completed the initial configuration

If you can’t reach your web interface directly after installing Access Server, you may need to fully complete the initial configuration. Refer to the section below for the platform where you’re deploying Access Server.

  • Complete the initial configuration of Access Server on an AWS instance:
    • After launching an Amazon AWS instance with Access Server, connect to the instance through SSH with the username openvpnas and your private/public key pair you used to launch the instance. You don’t use a password for this connection; AWS authenticates with the SSH keys. If you’ve lost the key pair on a new installation of Access Server on AWS, it’s easiest to terminate the instance and start again. Ensure to save the key pair when you launch the new instance.
    • 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 you complete the initial configuration, take note of the randomly generated password for your administrative account openvpn. The configuration output also displays the addresses for the Admin Web UI and Client Web UI. Access Server versions older than 2.10 do not automatically generate a password. On older versions you set the password manually by typing passwd openvpn on the command line.
  • 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. 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 you complete the initial configuration, take note of the randomly generated password for your administrative account openvpn. The configuration output also displays the addresses for the Admin Web UI and Client Web UI. Access Server versions older than 2.10 do not automatically generate a password. On older versions you set the password manually by typing passwd openvpn on the command line.
  • 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.
    • After you complete the initial configuration, take note of the randomly generated password for your administrative account openvpn. The configuration output also displays the addresses for the Admin Web UI and Client Web UI. Access Server versions older than 2.10 do not automatically generate a password. On older versions you set the password manually by typing passwd openvpn on the command line.

For detailed instructions on launching Access Server, refer to our platform-specific guides:

Using the correct external IP address

If you’ve completed the initial configuration and can’t connect, verify that you have the correct external IP address.

Verify the external IP address for your server:

After you complete the initial configuration, Access Server provides the URLs for the Admin Web UI and the Client Web UI, using the server’s IP address. Check that it’s an external IP address.

  • On some cloud instances, these IP addresses are internal only, which 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 instance of the cloud provider.
  • For installations in your private network you may need to ensure you set up a static IP address so that it will not suddenly change private IP on a restart of your router or server.

If you still encounter issues accessing the web interface, refer to the section, “Check if the Access Server web services are listening.”

Check if the Access Server web services are listening

Access Server must be listening on specific TCP ports for the web services.

Verify the ports for the web services with netstat

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.

  • To run netstat, sign in to your OpenVPN Access Server’s operating system through console or via SSH and obtain root privileges.
  • Start by running netstat to print out the tcp and udp ports where a program is listening and on what IP addresses:
    • netstat -tulpn
    • You should see an output similar to this:
      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.168.70.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.168.70.3:443    0.0.0.0:*         LISTEN    5683/openvpn-openssl
      tcp6       0      0 :::22               :::*              LISTEN    1084/sshd
      udp        0      0 192.168.70.3:1194   0.0.0.0:*                   5713/openvpn-openssl
    • Our example output shows that OpenVPN Access Server listens on the IP address, 192.168.70.3 with various components of Access Server running. The Access Server in our example manages only one TCP and one UDP daemon.
    • If the ports that Access Server should be listening on aren’t configured correctly, refer to set the interface and ports for the web services.

Note: The default setting listens on all interfaces. The output would then show a line such as this:

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

Verify the ports for web services with ifconfig

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.

Verify that Access Server listens on the correct TCP ports for the web services with iptables:

When Access Server manages multiple OpenVPN daemons, the program leverages iptables for load-balancing between the processes. 

  • 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 where OpenVPN Access Server offers the Admin Web UI and Client Web UI. Compare this to the output of your ifconfig results to see if this IP address is present on your system or not.
  • To see which IP addresses are available on your server, run ifconfig:
    • ifconfig
  • If our example IP address 192.168.70.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.168.70.3:943/ | grep -i -m 1 "OpenVPN"
      wget -O- -q --no-check-certificate https://192.168.70.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. Examples:
    • <!-- Copyright (C) 2010-2021 OpenVPN Inc. - http://openvpn.net/ →
      <title>OpenVPN Login</title>
  • Next, you can 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.168.70.3:943/.

Set up port forwarding

Ensure you set up port forwarding for an Access Server behind an internet gateway:

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.168.70.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.

Assign an Elastic IP for AWS instance

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 Web and Client Web UIs.

Ensure security groups allow access on AWS

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.

Configure tcpdump to listen to requests to and from Access Server:

You can use tcpdump to listen to requests on a specific port and IP address on your system server and see what those are.

  • Install tcpdump:
    • apt-get update
      apt-get install tcpdump
  • Run tcpdump and listen on the specified IP and port (from our example, 192.168.70.3 on port 943 TCP):
    • tcpdump -eni any "dst host 192.168.70.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.168.70.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.168.70.3.46136 > 192.168.70.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.168.70.3.46136 > 192.168.70.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.168.70.3.46136 > 192.168.70.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.168.70.3.46136 > 192.168.70.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.168.70.3.46136 > 192.168.70.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.
  • Next, enter the Admin Web UI address, for example, https://192.168.70.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.168.70.186.63233 > 192.168.70.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.168.70.186.63233 > 192.168.70.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.168.70.186.63233 > 192.168.70.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.168.70.186.63233 > 192.168.70.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.168.70.186.63233 > 192.168.70.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.168.70.186.63255 > 192.168.70.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.168.70.186.63256 > 192.168.70.3.943: Flags [S], seq 3849647674, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

If the web services don’t respond, verify you’ve configured iptables firewall rules correctly:

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: You likely have a firewall issue 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.

If tcpdump shows no output:

  • Verify you’ve properly configured firewall or security groups outside of the Access Server itself.
  • Verify that web browser requests from client computers can access Access Server through any firewall or security groups on our network.

Reset Access Server web interface settings to default ports

If Access Server web interfaces don’t respond:

Request additional support

You can submit a support ticket for additional help.

Why does Access Server use TCP 443 and TCP 943 ports

OpenVPN Access Server hosts both the Admin Web and Client Web UIs on TCP ports 443 and 943. Access Server uses both ports, not because there are two separate components to the web interface, but to work better with basic firewalls in use.

The OpenVPN protocol works best over UDP. We have an IANA port registration for UDP 1194 for the OpenVPN protocol. However, basic firewalls on public networks may block everything except HTTP, HTTPS, FTP, and e-mail traffic. For these networks, it’s not possible to make a successful VPN connection to UDP port 1194. To get around this, Access Server runs OpenVPN daemons on the TCP port 443, the default HTTPS port. Such firewalls would allow an OpenVPN connection over TCP 443 through in that case, since it is on an allowed port (HTTPS is over TCP 443). TCP-over-TCP is not the best method but serves as a workaround.

The default port that web browsers use for HTTPS connections is TCP 443. But with the OpenVPN TCP daemon listening on that port, we can’t run a web server there. So OpenVPN Access Server runs its web services on port TCP 943, which you can reach directly from a web browser by specifying the port number in the URL: https://vpn.yourserver.com:943/.

Why OpenVPN Access Server uses port sharing

Adding the port number to your URL isn’t intuitive. We recommend setting up a custom domain instead, such as https://vpn.yourserver.com/. To make this happen without including 943 in the URL, OpenVPN Access Server uses port sharing:

  • A web browser connects to the custom domain.
  • The DNS A record points this domain to the server IP address.
  • The OpenVPN TCP daemon recognizes that this isn’t an incoming OpenVPN tunnel but an incoming HTTPS web browser request.
  • OpenVPN Access Server redirects the request to the web services.
  • This happens transparently to the end-user, allowing both the OpenVPN TCP connection and the web services to function simultaneously on TCP port 443.

Web service forwarding settings

You can turn off this port sharing in the Admin Web UI. When you turn off web service forwarding, you must include port 943 in the URL to connect with your Admin Web or Client Web UIs—https://vpn.yourserver.com:943/admin/ for example.

To turn on or off the web service forwarding:

  1. Sign in to the Admin Web UI.
  2. Click Configuration > Network Settings.
  3. Under “Web Service forwarding settings,” turn on or off the forwarding for the Admin Web Server and the Client Web Server.
  4. Click Save and Update Running Server.