# OpenVPN very slow **URL:** \ **Category:** OpenVPN\ **Created:** [27 May 2023 07:43 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805 "2023-05-27T07:43:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mrichtsfeld](https://community.ipfire.org/user_avatar/community.ipfire.org/mrichtsfeld/32/7271_2.png) [@mrichtsfeld](https://community.ipfire.org/u/mrichtsfeld)\ **Post date:** [27 May 2023 07:43 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/1 "2023-05-27T07:43:08Z")
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. Any help on how to debug this is welcome. Thank you, Martin ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [27 May 2023 08:04 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/2 "2023-05-27T08:04:15Z")
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. [https://wiki.ipfire.org/configuration/services/openvpn/troubles](https://wiki.ipfire.org/configuration/services/openvpn/troubles) [https://wiki.ipfire.org/addons/mtr](https://wiki.ipfire.org/addons/mtr) ---
**Author:** ![tphz](https://community.ipfire.org/user_avatar/community.ipfire.org/tphz/32/16551_2.png) [@tphz](https://community.ipfire.org/u/tphz)\ **Post date:** [27 May 2023 08:04 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/3 "2023-05-27T08:04:37Z")
I hope that the information on the following pages may be helpful > **[Troubleshooting OpenVPN - The IPFire Wiki](https://wiki.ipfire.org/configuration/services/openvpn/troubles)** > [@IPFire weird behaviour with standard MTU ( fragmentation )](https://community.ipfire.org/t/ipfire-weird-behaviour-with-standard-mtu-fragmentation/8971): > > Hello, I have create a IPSec VPN between two IPFire this is working… but when I do a ping to the other site of the VPN like: Pinging 10.0.0.138 with 32 bytes of data: Reply from 10.0.0.138: bytes=32 time=15ms TTL=62 Reply from 10.0.0.138: bytes=32 time=15ms TTL=62 Reply from 10.0.0.138: bytes=32 time=15ms TTL=62 Reply from 10.0.0.138: bytes=32 time=15ms TTL=62 this is working. When I do a ping with more data in it like: Pinging 10.0.0.138 with 65500 bytes of data: Request timed out. R… [https://www.speedguide.net/analyzer.php](https://www.speedguide.net/analyzer.php) BR ---
**Author:** ![mrichtsfeld](https://community.ipfire.org/user_avatar/community.ipfire.org/mrichtsfeld/32/7271_2.png) [@mrichtsfeld](https://community.ipfire.org/u/mrichtsfeld)\ **Post date:** [27 May 2023 09:29 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/4 "2023-05-27T09:29:27Z")
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. Will post an update in the next days. Thanks again, Martin ---
**Author:** ![mrichtsfeld](https://community.ipfire.org/user_avatar/community.ipfire.org/mrichtsfeld/32/7271_2.png) [@mrichtsfeld](https://community.ipfire.org/u/mrichtsfeld)\ **Post date:** [30 May 2023 09:28 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/5 "2023-05-30T09:28:38Z")
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: ```auto My traceroute [v0.95] My-MacBook-Pro.local (xx.xxx.xxx.x) -> ipfire.org (81.3.27.38) 2023-05-30T16:52:11+0800 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. xx.xxx.xxx.x 0.0% 432 211.5 217.1 211.4 266.7 6.6 2. xxx.xx.x.x 0.5% 432 214.8 220.4 213.7 241.1 6.3 3. 10439.your-cloud.host 0.9% 432 212.0 217.4 211.6 236.1 6.4 4. (waiting for reply) 5. spine2.cloud1.hel1.hetzner.com 0.7% 432 212.9 221.2 168.7 323.4 12.4 6. core32.hel1.hetzner.com 0.7% 432 216.5 220.6 211.9 280.6 8.6 7. core9.fra.hetzner.com 0.7% 432 233.1 240.8 231.6 288.3 9.5 8. cr01.h.as24679.net 0.7% 432 239.6 245.6 239.1 263.9 6.6 9. fr4a.h.as24679.net 0.7% 432 239.5 245.4 239.0 268.1 6.5 10. fw01.ipfire.org 0.7% 431 239.9 245.4 239.4 267.4 6.3 ``` 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? Thanks for any help, Martin ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [30 May 2023 12:16 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/6 "2023-05-30T12:16:13Z")
> [@mrichtsfeld](#): > > 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. > [@mrichtsfeld](#): > > ` 4. (waiting for reply)` 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](http://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](http://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. ---
**Author:** ![mrichtsfeld](https://community.ipfire.org/user_avatar/community.ipfire.org/mrichtsfeld/32/7271_2.png) [@mrichtsfeld](https://community.ipfire.org/u/mrichtsfeld)\ **Post date:** [31 May 2023 09:11 UTC](https://community.ipfire.org/t/openvpn-very-slow/9805/7 "2023-05-31T09:11:59Z")
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. Thanks again for all your help.