Hi,
I have been using OpenVPN for a few years and it always worked fine. However, since a few weeks the VPN became practically unusable. Within minutes it is slowing down the connection to unusable speeds. I have constant ping speeds to my ipfire and server behind the firewall with 200ms. I have tried various speed testers from the internal servers to the WAN and it works fine. It only seems to be the Roadwarriors that are extremely slow. I also tried switching intrusion detection on/off without any change.
Are the Roadwarriors using a consistent wifi point to connect or can it be all over the place. WiFi connection point can sometimes change their conditions or throttle stuff.
Looking at the wiki OpenVPN Troubleshooting page it mentions an addon that might help you called MTR. I have never used it myself but it apparently combines the functions of traceroute and ping so might help you identify where in the tunnel route the problem is occurring.
Thank you everyone for the quick replies. I will go through your suggestions in the next days to get some data and statistics. Might also set up a parallel ipfire server to see if it is the same issue. Wifi is good at my place and other VPNs work well.
I remember I true the MTR tool before and it somehow did not reveal any abnormalities, but I run it again.
Hi again everyone,
I have setup a completely new ipfire instance via Hetzner, just to make sure I have a clean start. Then I created an OpenVPN Roadwarrior and only connect with that one client.
I have tried the MTR with the following result:
I’m not sure what the “4. (waiting for reply)” means and how to get more information about it. The rest looks normal to me.
I also manually set the MTU size to 1400, but still no change.
Download speed from my Laptop 15 KB/sec .
I also could not find any errors in the logs.
I’m very puzzled since I’m using a completely new setup. So I assume it must be an issue with my laptop. Or did anything change in a recent release that could cause this?
I have no idea if they would cause the problems you are seeing. It also depends what version you are using now (CU174?) and what version was being used before that.
The last update of the OpenVPN package itself was in CU172.
The use of 2FA/OTP was added into the perl cgi page for OpenVPN in Core Update 169. Looking at the code, it does a one time authentication when setting up the connection with 2FA. It also is not used for any connection not using 2FA. I can’t see how it would affect the speed of the connection when no 2FA is used.
Between CU169 and CU174 there have been minor changes to the perl code for the OpenVPN cgi page but I can’t see any of those causing a speed problem. They are things such as an update to a translation string, correction of a table style rendering bug, a bug fix to allow the use of spaces when defining a static ip address pool name, fixing the download of the insecure .p12 file to not provide a corrupted file due to double quotes used at a certain location in the code, etc.
If that happens all the time then that might suggest there is a problem there with part of the route that you use. MTR sends its request to each stage of the route and repeats this to give average and standard deviation. That message suggests that MTR has never got any reply from that host.
EDIT:
I just tried running mtr to ipfire.org and got one of the hops that showed waiting for reply for a short while but then it gave a response that showed 68% packet loss.
Re-starting the statistics gave the same result - waiting for a reply - for some seconds and then showing 60% to 70% packet loss.
I would suspect you might have a host in your route that has a problem with losing the packets so badly that it stays showing - waiting for a reply.
EDIT2:
I just changed my command to mtr -T ipfire.org which uses TCP Syn packets instead of ICMP packets.
That caused the dropped packets to reduce to around 20% but increased the time from around 20 to 30 milliseconds to greater than 1700 milliseconds, ie around 1.7 seconds due to trying to correct the lost packets. The worst result is 7 seconds.
This is a glass fibre operator here in the Netherlands. All the other host hops show 20 to 30 milliseconds and 0% lost packets.
Maybe if you try the -T option you might get some response back rather than just waiting for reply.
Thank you for all you information. I tried it again with -T and the loss was almost 100% and still 2 host with “waiting for reply”. I wonder if it is my location. However, I use ExpressVPN and it works perfectly fine. Also streaming has no glitches.
I will wait until I’m in another location this summer and then see if that is really the issue. If it is, then I’m not sure that there is much I can do. I even used 443 as port of OpenVPN, so it is very hard to detect and differentiate from normal https traffic.