What's new

OpenVPN Speed Slows Over Time

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Cherenkov

New Around Here
Apologies if this has been answered before, I couldn't find it if it has.

Running 386.2_4 on an Asus RT-AC5300. When I first boot the router, my connection speeds over the VPN are pretty good, around 60 mbps down, 11 up. Over time this speed degrades, dropping about 10 mbps per day, sometimes more, ending up in the teens within a few days. If I reboot the router, the speeds go right back up. I don't think it's a heat issue since the router immediately resumes after the reboot, it doesn't really have a chance to cool off. I've tried with several VPN providers and access points and all behave the same, so I don't think it's the VPN itself either. As a workaround I have the router set to reboot every night. Wondering if anyone has a better solution to this? Temps are solid around 149 deg f on the CPU, and CPU usage is minimal, less than 10%.
 
Just out of curiosity, what happens if you simply restart the VPN rather than reboot the router? The problem w/ rebooting is it provides no clues (it could be anything). But if it returns to normal w/ a simply restart, that would suggest it's directly related to the VPN client.

Also, any relevant information in the syslog?

I suppose the issue could be related to your ISP too. It's certainly possible for them to detect the use of a VPN and "mess w/ it". I'm NOT saying this is likely, but just trying to think a bit outside the box. Esp. given that if this was a bug or known issue, presumably others would be reporting it.

Btw, besides the GUI, you can restart from the CLI as well.

Code:
service restart_vpnclient1

Frankly, it's probably not a bad idea to restart the VPN regularly anyway. It adds to your stealthiness, esp. if you specify multiple servers (remote directives) in custom config and use the remote-random directive. Here's an example of my own w/ ExpressVPN.

Code:
server-poll-timeout 10
remote-random
remote us-new-york-2-ca-version-2.expressnetw.com 1195
remote usa-atlanta-ca-version-2.expressnetw.com 1195
remote usa-chicago-ca-version-2.expressnetw.com 1195
remote usa-dallas-2-ca-version-2.expressnetw.com 1195
remote usa-dallas-ca-version-2.expressnetw.com 1195
 
When I restart or change the VPN the speed recovers slightly, but not nearly as much as rebooting. Maybe a few mbps versus 30+. Likewise swapping providers helps a little but rebooting helps a lot. Previously I was running a standalone Pfsense server for years without issue, so I don't think my ISP is throttling the connection. That's interesting about the remote-random, I think I'll implement that either way! I'm guessing the server-poll-timeout command checks to make sure

What should I be looking for in syslog? The connection doesn't drop, it just gets progressively slower until I'm in single digits for speeds. Rebooting and connecting to the same node brings me back to full speed. Syslog has hourly updates on the vpn connection which always kick off with "TLS: tls_process: killed expiring key" but there are no errors, everything looks successful. Going further back, the only error of note I'm finding is for Crond - crond[450]: time disparity of 1587013 minutes detected. That's a pretty huge gap! Timestamp is just after the router rebooted. Using the defaults for NTP (pool.ntp.org and time.nist.gov). System time seems correct.

My feeling is that some buffer is filling that the reboot clears, but I don't know enough about merlin to even guess as to which. I used pfsense for years but had to drop it because it lacks a real kill switch.

Appreciate the help!
 
Had put in place automated nightly reboot as rt-ac88u was presenting same behavior. After upgrading to Asuswrt-Merlin 386.4 and disabling nightly reboot the slowdown is no longer present based on observation over past 3 days. Not sure if an update between the past summer and now addressed the issue although passing on that in my case, being on Asuswrt-Merlin 386.4 the issue is not there.
 
After observing this further I need to correct comments in above reply. the issue in fact still persisted while on 386.4 and also behavior continued on subsequent releases including 386.5_2.

There is another thread included below that has reported similar issues:

Below is data i can share that reflects behavior over 30 days with speeds returning to normal after reboots:

1651243280743.png


Traffic for 1 IP is shaped through VPN Director and routed to NordVPN provider, all other IP traffic remains responsive through normal WAN flow at a consistent band width rate.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top