Slow page loads with OpenVPN Access Server

alsmola

I'm using OpenVPN Access Server 2.1.9, from the AWS Marketplace AMI.

When I load the root page from the web interface it takes nearly a minute to load the entire page. Looking at the traffic inspector, I can see the individually loaded HTML pages (login.html, login-challenge.html, downloads.html, etc) all take just over five seconds to load (5.12s, 5.09s, 5.29s, etc), which means that the UI doesn't finish loading for a considerable amount of time.

Why would there be a consistent five second delay in loading each of these pages? Is there some sort of timeout I'm hitting?

Note that reloading eventually causes the page to be returned quickly (without the delay) but closing and re-opening the incognito window causes the issue to re-appear.

The Johan

Check if the address you're using to access the web interface matches the address in the 'host name or IP address' field in the Server Network Settings.
Check that the DNS servers are actually working on your Access Server's operating system.

alsmola

I've checked the "Host Name or IP Address" field, it's correct.

The DNS on the Access Server's OS appears to be working as well (e.g. nslookup google.com and nslookup <vpnhostname>.com both work).

Do you have a reason to think why this five second latency would be related to DNS/host resolution?

The Johan

In other cases the issue was resolved by making sure DNS was working right, and the names were configured right, so yeah.

alsmola

As far as I can tell it's working right, but I'm hoping that understanding previous cases where it was misconfigured would help me understand exactly what "working right" means.

The Johan

By working right we mean the web interface loads in like a second. Well, aside from the 'connect' option but that's being phased out as soon as possible.

alsmola

It's surprising that DNS resolution on the server would affect the loading time of a page. If that is the case, then somehow serving of that page requires the server to resolve DNS hostnames, and understanding that process would help me troubleshoot the issue.

The Johan

I don't understand it either to be honest, it doesn't really make sense, to me, anyways. But in a few cases where we saw this problem, that fixed it. That's all I know about the issue at this time.

medal

I'm experiencing this issue as well.

Scenario/How to Reproduce

* I installed a fresh pay as you go license for OpenVPNAS on AWS. Version 2.5.
* Set up this EC2 instance using whatever public IP amazon gave it
* I didn't notice any problems in the web UI.
* Then I attached an elastic IP address to the instance.
* Added a hostname/FQDN that resolved publicly via Route53.
* Installed a real TLS cert for the web server.
* Changed the "Hostname or IP Address" setting under "Network Settings" to match the public hostname.
* verified that I can resolve this hostname and IP from my workstation and from a command line on the VPN server.
* I restarted the openvpnas service

Suddenly the webUI very slow. The https://myserver.com/admin URL takes 40 seconds to finish loading. Individual components take about 5.0 seconds each. In chrome's dev tools the Waiting (time to first byte) is at least 5.0 seconds for every item.

What it is not:

* DNS resolution (nslookup/dig work fine from the host and from laptop)
* CPU/Disk/IO Load (oversized instance, nothing else weird running. htop/sar show near zero utilization)
* Weird cipher suite/Slow TLS negotiation

What it Might Be

When I go to http://myserver.com/admin:943 the page loads are normal (less than 2 seconds).
When I do the same on port 443 (default https), then that's where the slowness is.

So I suspect the problem lies here: https://docs.openvpn.net/command-line/managing-settings-for-the-web-services-from-the-command-line/#Set_the_interface_and_ports_for_the_web_services

I'm not sure what changes need to happen in the web service forwarding settings though.

How I solved it

Basically disable this business where the VPN server forwards connections on 443 to 943. Its slow AF, don't know why.
In the admin console flip these two sliders (about 1/4th way down the page in the VPN Server section)
Network settings is the menu item on the left side of the page.

Network Settings -> Admin Web Server -> Off
Network Settings -> Client Web Server -> Off

The Johan

I want to advise against this. There are very specific reasons for having the ports on the numbers they are on. Also, changing ports on an existing installation with VPN clients already installed can have negative consequences as well. I implore you not to implement the solution mentioned above.

We actually very recently (like a few days ago) had a breakthrough on this. It turns out that in modern kernels on Ubuntu 16, possibly other OSes as well, in combination with macOS devices, using port-sharing in OpenVPN, with the default settings that Access Server uses for buffer settings, on Amazon AWS, causes a rather weird TCP window scaling problem which slows things down considerably. We have already implemented a fix in the next release of access server. If you want to fix it in an Access Server experiencing this problem now run these commands:

Log on through SSH to the Access Server and obtain root privileges. Then run these commands:
cd /usr/local/openvpn_as/scripts
./sacli --key vpn.client.client_sockbuf --value 0 ConfigPut
./sacli --key vpn.server.server_sockbuf_tcp --value 0 ConfigPut
./sacli --key vpn.server.server_sockbuf_udp --value 0 ConfigPut
./sacli start

Note that this will disconnect your VPN clients momentarily, but they should reconnect by themselves. This should solve the slow web UI issue immediately.

bthurber

"We have already implemented a fix in the next release of access server"

novaflash, will a new AWS marketplace version be available that includes this fix?

The Johan

When we make a new stable release, with the fix in it, yes, we will be making a new AWS marketplace and ESXi and HyperV image release with that fix, and other new features, included in it.

By the way the fix for this particular issue is just making the default implied setting the same as the explicit setting defined above. Comes down to the same thing, just set at a different level.

CarstenB

We have the same Problem in AWS after Update to v2.7.4

If i open the AdminUI from the client who ist conected its open the website faster then a second.
Whe i want to open the AdemUI frim the manage Server the website will be loding >30 Sec and mostly it logged me out in the time. So i see the landing page in two of three attemps.