Troubleshooting Access to the Web Interface⁠

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:

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

  2. Accept the Access Server license agreement and complete the initial configuration. This step is necessary for the web interfaces to become available.

  3. 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):

  1. Connect to the virtual machine with the username root and the password openvpnas.

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

  3. 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:

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

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

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

1. Complete the initial configuration.

2. Note the URLs for the Admin and Client Web UIs in the configuration output.

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

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

1. Connect to your console and get root privileges.

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

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

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

1. Connect to the console and get root privileges.

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

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

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

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

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

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

2. Verify this by connecting to your public WAN address from a computer, not inside your private network.

We recommend assigning an elastic IP address for Access Server launched through Amazon AWS for the following reasons:

1. An elastic IP address is a public IP attached to your AWS instance.

2. 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:

1. Sign in to your Amazon AWS console.

2. Allocate an Elastic IP address to the EC2 instance with Access Server.

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

1. Sign in to your Amazon AWS console.

2. 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 and cluster communication

   • UDP 1194 — OpenVPN client communication

   • TCP 945 — Deprecated: Used in versions prior to 3.0.0 for cluster API communication

3. Allow all outgoing traffic.

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

1. Connect to your console and get root privileges.

2. Install tcpdump:

   apt update
   apt install tcpdump

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

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

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

1. Refer to the firewall solution installed on your system’s operating system.

2. Allow traffic to pass through the firewall to the correct port.

If Access Server web interfaces don’t respond, refer to this tutorial:

• Tutorial: Reset OpenVPN Web Services and Daemons to Default Settings

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.

  1. Sign in to the Admin Web UI.

  2. Click Configuration > Network Settings.

  3. Turn off port sharing under Web Service forwarding settings.

  4. Select Save Settings and Update Running Server.