Troubleshooting access to the web interface
It is important in these steps to understand how the web services work and where and how they can be reached. Therefore there is going to be some explanation first before we get to the troubleshooting parts. The OpenVPN Access Server comes with a web interface that exists of 2 main components:
The Admin UI web interface is the web interface that lets the administrator of the Access Server see and change the configuration of the Access Server. You can for example use it to change the authentication system it is using, and if you’re using the local authentication system you can add new users through the web interface, set passwords for them, define access rules to configure which IP address(es) these users have access to through the VPN server, and change which ports the Access Server listens to, and so on. This is your first stop when it comes to setting up and configuring your Access Server. For advanced settings not configured in the Admin UI, or for complete control of the Access Server without ever using the web interface, we also have command line tools available.
The Client UI web interface is the web interface that lets users that wish to make a VPN connection to the Access Server to see and download their unique connection profiles and software required to make a connection. The web interface will offer the option to download and install the OpenVPN Connect Client for Windows or the OpenVPN Connect Client for macOS, and also offers information for other platforms on how to make a connection. It also offers connection profiles like a user-locked profile or an auto-login type profile that can be used with compatible OpenVPN client software. While the OpenVPN Connect Client for Windows and macOS is also available on this website for download separately, it is generally advisable to download and install the version your Access Server offers, as it then comes preconfigured for a connection to your server, whereas our generic version is completely blank and without any configuration.
How to access the web interface
In order to make a connection to the web interface you obviously need a suitable browser like Google Chrome, Opera, Firefox, Internet Explorer, Microsoft Edge, etcetera. Really old browsers will generally have problems accessing an HTTPS secured website, for example if you’re still on Windows XP you will likely need to use a more modern system to access it. By default the Access Server web interface is reachable on the address of your server. If your server has only an IP address, then use that in your browser. For example if your OpenVPN Access Server has the IP address 220.127.116.11 then by default the Access Server should listen on that address. By default the OpenVPN Access Server installs the web interfaces on port TCP 943, and also makes them available at port TCP 443. The reason why this is present on two ports is technically complicated and is explained in a separate section further down on this page.
If your Access Server has IP address 18.104.22.168 then you should be able to open the web interface by pointing your web browser at the addresses mentioned below:
- Admin UI: https://22.214.171.124/admin/
- Admin UI: https://126.96.36.199:943/admin/
- Client UI: https://188.8.131.52/
- Client UI: https://184.108.40.206:943/
If you have already set up your Access Server but have simply forgotten your access codes, see these steps to reset the administrative user access codes. However if this is your first time setting up Access Server please read on.
When you first start out it is very likely that your server does not have a DNS name set up yet and that it uses a self-signed certificate. There is no possible way to ensure that a freshly setup Access Server has a properly validated SSL certificate immediately out of the box in all situations. Therefore the server starts out with a self-signed certificate which cannot be automatically validated by your web browser. You will therefore receive warnings that look like the screenshots shown below. You should override the warning or add an exception to continue with accessing your server’s web interface. This is normal in this situation and can be rectified later by setting up a DNS host name that resolves to the public IP address of your Access Server, and installing a valid SSL certificate that corresponds to that DNS host name, and then always using that name to access your server instead of by IP address directly.
The Admin UI web interface is protected with a username and password. The username by default is openvpn (unless you have been given the option to change it, and did change it). But there is no password set on the account by default. An account without password cannot be used to log on, so you will need to set a password first. You can do so on the command line of the Access Server as root user.
Set password for openvpn administrative user:
You can then access the Admin UI web interface and log on with username openvpn installation instructions for your chosen platform and the password you just set. We recommend you read the documentation to finish up configuration properly, and to also check the security recommendations page on how to properly secure your Access Server.
The Client UI web interface can be reached with a valid user account that is created on the Access Server in LOCAL authentication mode or in the chosen authentication backend (LDAP, RADIUS, PAM). It can also be reached and use with an administrative user account but we advise against that, and we advise that you create standard unprivileged user accounts for VPN tunnel access instead.
Once you have access to the web interface you can find more information here on how to configure the Access Server using the web interface.
After initial installation web interface cannot be reached
If you have just installed or launched your Access Server installation and your web interface does not work there are a number of things that can be diagnosed and tried to find out what is going wrong.
If you have launched an Amazon AWS instance and the web interface isn’t responding please note that you must first logon through SSH with the username openvpnas and your private/public key pair that you used to launch the instance. There is no password, it uses the SSH key for authentication. If you have lost this key pair on a new installation of Access Server on Amazon AWS, then it is easiest to terminate this instance and try again, but this time pay attention to creating a new key pair and saving it carefully. Once you have launched the instance and have successfully connected to it through SSH, you must accept the license agreement to continue, and accept some default settings. You can change these later at any time and the defaults are usually fine. Once that’s done, the Access Server web interface will come online. You will then have to set a password for the openvpn administrative user account in order to log on to the Admin UI web interface. To learn more about how to do all of this we advise that you read the installation instructions for your chosen platform. If you still encounter problems with the web interface not working then we advise that you check your security groups settings. It is very likely that if you have changed them from the defaults that you are accidentally blocking the web interface traffic with your security groups settings. To determine if this is the case then please read on for further troubleshooting steps in the next section that explains how to determine if the Access Server web services are actually listening and how to do some basic tests to determine if the issue is possibly firewall related or in the Access Server configuration itself.
If you have deployed a Microsoft HyperV or VMWare ESXi virtual appliance that you obtained from us and the web interface isn’t responding please note that you must first logon at the virtual console of the virtual machine itself using the user name root and the password openvpnas. SSH access to the root account is by default not possible on these virtual appliances, but this can be enabled if you really want to. We advise instead that you create your own user for SSH access and enable sudo access on it, if you want to access the server via SSH. Once you have deployed the virtual appliance and have successfully logged in to the virtual console, you must accept the license agreement to continue, and accept some default settings. You can change these later at any time and the defaults are usually fine. Once that’s done the Access Server web interface will come online. You will then have to set a password for the openvpn administrative user account in order to log on to the Admin UI web interface. To learn more about how to do all of this we advise that you read the installation instructions for your chosen platform. If you still encounter problems with the web interface not working then please read on for further troubleshooting steps in the next section that explains how to determine if the Access Server web services are actually listening.
If you have installed on a cloud platform or VPS provider other than Microsoft Azure or Amazon AWS, and the OpenVPN Access Server installer package file installs successfully, but the web interface isn’t responding at the stated IP address, there are two common things that could be preventing the Access Server from being reachable or starting properly. One of the things we have encountered with some of the VPS images on for example OVH or Kimsufi is that the kernel for some of the operating systems they provide you with are compiled with a static kernel that does not have certain iptables related kernel modules and does not allow loading of such kernel modules either. This leads to the Access Server only being able to start partway but the web interface simply does not come online at all. In such a situation the issue was resolved by reverting to the stock kernel that comes with the OS which does allow loading of the required modules and the web interface then becomes available normally. We advise however that you read on and use the tests to determine if the Access Server web interface is listening first before altering the kernel, this is explained in the next section. If the web interface is indeed listening on the correct port and IP address then the issue could be simply a firewall issue. The other issue we have encountered on some cloud platforms like Digital Ocean is that there is a type of duality with network interface configuration, where there is the IP address that the cloud provider uses for management and additional functionality of the VPS, and the IP address that you use for accessing your server and reaching the Internet, both on the same network interface. The Access Server can be confused by this and bind to the wrong IP address. This can be fixed by altering the address that the Access Server listens to. This is explained in the next section that explains how to determine if the Access Server web services are actually listening.
Check if the Access Server web services are listening
While logged on to the OpenVPN Access Server’s operating system through the console or via SSH, and having obtained root privileges, you can run a number of tests to determine if the web services of the Access Server are actually listening. By doing this test locally on the command line we are able to bypass any issues in regards to firewalls or port forwarding problems, and test it directly on the server itself. We are assuming that you are using a Debian/Ubuntu type system. We by default use Ubuntu and so we have created our guides for that specifically. If you have another system these commands may need to be adjusted slightly.
Check the output of the netstat command:
Output: 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/python tcp 0 0 127.0.0.1:905 0.0.0.0:* LISTEN 5669/python tcp 0 0 127.0.0.1:906 0.0.0.0:* LISTEN 5669/python tcp 0 0 127.0.0.1:907 0.0.0.0:* LISTEN 5669/python tcp 0 0 127.0.0.1:908 0.0.0.0:* LISTEN 5669/python tcp 0 0 127.0.0.1:909 0.0.0.0:* LISTEN 5669/python tcp 0 0 192.168.70.3:943 0.0.0.0:* LISTEN 5669/python 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-openss tcp6 0 0 :::22 :::* LISTEN 1084/sshd udp 0 0 192.168.70.3:1194 0.0.0.0:* 5713/openvpn-openss
From the output above we can see a typical situation where the OpenVPN Access Server is configured to listen on a specific IP address, in this case 192.168.70.3. We can see the various components of the Access Server running here. This output is from an Access Server installation that manages only 1 TCP daemon and 1 UDP daemon. If you have more, then the items on ports 443 and 1194 will not be listed in the netstat output, even though the ports are open. The process list will then also be larger. The reason for this is that when multiple OpenVPN daemons are managed, iptables is leveraged to do a type of load-balancing between the processes. This is visible in the NAT iptables table. In the output above it’s a simple setup with all the main components listed. There are a number of these that are easy to understand, and a number that have generic names that are less easy to understand. For the purposes of this troubleshooting guide that focuses on the web services, we are going to focus on the processes involved with the web services specifically.
To 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
This is the OpenVPN Access Server’s default port (TCP 943) where the Admin UI and Client UI should be offered on. Compare this to the output of your ifconfig results to see if this IP address is actually present on your system or not.
To see which IP addresses are available on your server run ifconfig:
If the IP address 192.168.70.3 in our example is not even present in the ifconfig output, then you already know now that the Access Server is listening on the wrong IP address on this system, and you will want to fix that. You should skip ahead 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’re seeing output that looks like some of these samples, then you have confirmed that you have reached a web service that does indeed appear to be serving up web pages for the
Access Server web interfaces:
<!-- Copyright (C) 2010-2018 OpenVPN Inc. - http://openvpn.net/ -->
So now that you have confirmation that the web services are at least listening on the stated IP and port, you should verify that you can reach that IP address and port from your own computer. In this example I would try to open the web interface in my web browser at https://192.168.70.3:943/.
If your Access Server is on a private network behind an Internet gateway in your own infrastructure, you will need to make sure that you have port forwarding setup correctly so you can reach the Access Server in your private network from the outside at your Internet gateway’s public IP address. Port forwarding or NAT forwarding has to be setup for the ports TCP 443, TCP 943, and UDP 1194, assuming default settings and similar output of netstat as seen here, and in the example here in this troubleshooting guide, the port forwards would have to go from the WAN interface to the LAN IP address 192.168.70.3. If you are sure this is set up right and the Access Server can be reached from inside your LAN directly, but cannot be reached on the public WAN, try verifying this by connecting to your public WAN address from a computer that is not inside of your own private network. In rare cases, hairpinning or NAT reflection is not working in some routers, and this causes the situation that while you are inside your own LAN, you cannot access services on your public WAN IP that port forward to a server in your own LAN. If you want to rule out Access Server itself as a cause, try the troubleshooting steps in the next section.
In some setups, like for example on Amazon AWS, where your virtual machine is on a private subnet which you cannot reach from the outside directly on its private IP address, you will need to attach a public IP address to the virtual instance. On Amazon AWS for example a public IP address gets attached to your AWS instance in such a way that any connection you make to the public IP, gets relayed automatically and transparently to the internal private IP address of your AWS instance. In such a case you would need to find the public IP of your instance and use that to connect to your server from the outside, while your Access Server service is configured to listen on the internal private IP address of your AWS instance. For example the public IP could be 220.127.116.11 and then I should be able to reach the web services at https://18.104.22.168:943/, and Amazon AWS then ensures that those requests are internally relayed to (in our example) 192.168.70.3. If that doesn’t work then it is extremely likely that your security groups settings are blocking access. The security groups on Amazon work like a firewall. The default settings we provide with our instance are correct and block all incoming access except to TCP 22 (for SSH), TCP 443, TCP 943, and UDP 1194, and allow all outgoing traffic (required for normal operation). But let’s say you believe you have this already set up properly. If you want to rule out Access Server itself as a cause, try the troubleshooting steps in the next section.
Using TCPdump to test connectivity from outside
With the program tcpdump it is possible to listen in on network traffic that goes over a network interface. If you configure tcpdump to listen to requests on a specific port and IP address on your server system, you can see on your screen any requests that come in on that IP address and port. If you do this on the server where Access Server is running on an IP address and port that you believe should be reachable from the Internet, and then open that IP address and port in your web browser, you can be absolutely sure that these packets of information are actually reaching your server or not. If not, then the issue is not a problem with Access Server, but a problem in your firewall or security groups settings, or your IP address and port are somehow unreachable from your client computer for other unknown reasons. But if this test with tcpdump works, but the Access Server web interfaces don’t respond, then the issue may likely be resolved by resetting your Access Server web interface settings to the default ports, and to listen on all available IP addresses on your server system.
First install tcpdump:
apt-get update apt-get install tcpdump
Now run tcpdump to 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, and there is no activity on that IP and port, you will see no additional output showing up. You can trigger some sample output by running the local wget test again to see if your tcpdump monitoring process is working. You can do so by running this command while tcpdump is still running:
wget -O- -q --no-check-certificate https://192.168.70.3:943/ | grep -i -m 1 "OpenVPN"
You should be seeing output that looks a bit like this in the tcpdump process:
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
So now we have established that tcpdump is listening on the specified port and IP address we can try next to reach it from the outside. We are going to assume that we are on a computer that has access to the IP address 192.168.70.3, and as such we will open the web browser on address https://192.168.70.3:943/. The tcpdump process should now show us output that looks a bit like this, if the web services open successfully:
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 the web services don’t open successfully but I can still at least reach the server at the specified IP and port then results look a bit like 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
When you see this it appears the web services are not able to respond to the request coming from outside. The logical conclusion here would then be that iptables firewall rules in the operating system of the Access Server itself are then responsible for blocking access. In other words, the requests are making it to the target server system but cannot reach the web services because iptables blocks it. You should look into whatever firewall solution you have installed on your server’s operating system and clear these up so that they will allow traffic to pass to the correct port. From the test results it should be clear that if you can reach your web services locally successfully, and you can get requests from your web browser from outside to reach your system, but not able to successfully get to the web services, that the issue is in a local firewall on the operating system of the server itself, and it is not an Access Server problem by itself.
If however tcpdump shows no output at all, then you have a firewall or security groups issue that is outside of this server system itself and outside of Access Server itself. In such a case our recommendation is that you should investigate the external firewalls or security groups settings to ensure that web browser requests will actually make it from your client computer to the server system where the Access Server is installed. The results from tcpdump are very clear in determining where the issue lies.
Further troubleshooting is not available at this time, but if you still encounter a problem and you have run through these tests you may contact us through our support ticket system and provide us with details of the steps you have taken to determine where the problem is and what you have done to try to resolve it. Perhaps we will then have some additional tips for you to try.
Why does Access Server use TCP 443 and TCP 943 ports
This is not because there are 2 main components to the web interfaces (Admin UI and Client UI), but because of ease of use and trying to work around some of the more basic firewalls that are out there in use. On both TCP port 443 and TCP port 943, both the Client UI and the Admin UI are present and reachable by default.
The OpenVPN protocol works best over UDP, and we have an IANA port registration for UDP 1194 for the OpenVPN protocol, but basic firewalls on public networks may often choose to block everything except HTTP, HTTPS, FTP, and e-mail traffic. So on such a network it would not be possible to make a successful VPN connection. To get around this we also have the Access Server run OpenVPN daemons on the TCP port 443, the default HTTPS port. Such simple 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). While TCP-over-TCP is not the best method it is better than nothing. The OpenVPN clients will by default be configured by Access Server to try UDP 1194 connection first, and if that fails, to try a TCP 443 connection instead. To learn why TCP-over-TCP for a VPN system is not ideal, read about the phenomenon titled TCP Meltdown.
HTTPS on port TCP 443 is the default port that web browsers use when you type an address in your browser like https://vpn.yourserver.com/. But with OpenVPN TCP daemon listening on that port, we cannot run a web server there. A port cannot be used twice at the same time, it’s already taken by the OpenVPN TCP daemon. So we let our web services actually run on port TCP 943, since it does need an actual port to bind to, which can be reached directly when you specify the port number in your URL like so: https://vpn.yourserver.com:943/. Since adding the port number is not very intuitive, and because in the situation of a firewall blocking access to ports that do not fall under the default HTTP/HTTPS ports you won’t be able to access the web interface on TCP 943, we therefore use a feature built into the OpenVPN protocol called port-sharing. With this a web browser connecting to the OpenVPN TCP daemon running on port TCP 443, when accessing the server via a URL like https://vpn.yourserver.com/,the OpenVPN TCP daemon recognizes that this is not an incoming OpenVPN tunnel, but an incoming HTTPS web browser request, and internally redirects the request to the actual web services. This happens transparently to the end-user and allows both the OpenVPN TCP connection and the web services to function at the same time on TCP port 443.
Additionally, with the default configuration set up like this, if you were to click the ‘stop’ button for the OpenVPN daemons on the Access Server Admin UI, you would be stopping the OpenVPN TCP daemon on port TCP 443, and that also stops the port-sharing feature. In order to then still access the web interface and start the OpenVPN daemons from the web interface again, connect to https://vpn.yourserver.com:943/admin/ and click the ‘start’ button to start the OpenVPN daemons again.