New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
OpenVPN slow on Windows
Hi,
I am running an OpenVPN server on my KVM VPS.
If I connect to it from a Linux Client, it works great and the speed is ok, I reach around 100-160Mbit/s (170Mbit/s is the maximum on my connection).
If I use the Windows Client, I sometimes get the 160 Mbit/s, but most of the time only around 10-20Mbit/s.
According to some instructions, it should help to add the following to the config.
sndbuf 393216 rcvbuf 393216
Unfortunately, the speed on the windows client is still too slow.
Anyone have any idea?
Client Config: https://pastebin.com/BeJTDDnU
Server Config: https://pastebin.com/FpDj8ERu
Thanked by 1nunuigti
Comments
It'd help to know your Windows and hardware config.
As a generic answer, there are some patches for WinXP-7 to allow more connections than the default. Pretty sure they're available with wherever ShadowSocks is.
Windows 10, i7-5820k, Windows 850 Evo, 24GB DDR4 RAM.
The Linux system was running inside a VM on the same pc.
So it ran faster through a virtualized interface than Windows native interface? There's something weird with how that clients' setup, then..
I'm using the official OpenVPN GUI client.
But the problem seems to be common.
https://www.lowendtalk.com/discussion/40099/why-openvpn-is-so-slow-cool-story
If you're using the 32 bit client under Windows 10, it's your own fault.You're actually running the stock client. Nevermind.Changing your MTU and messing with that goodness will/can cause issues. I'd consider playing with the latest TUN modules, but I've never run Windows stock OVPN.
Which client do you recommend?
Plenty of folk seem to claim Viscosity works "better" for them, but I have no experience with it. I don't use Windows as a direct OVPN client, so I'm not as useful as I'd like to pretend to be.
I tried Viscosity, but I have the same problem with it...
The virtual NIC under Linux is likely breaking up the packets for the host NIC. Without knowing the NIC or issues it might have, I really don't know how to be more helpful- check out your NIC model on Google and check for MTU settings, fragmented packets, etc..
I will setup a Windows VM on the same pc and will try it again.
Have you tried SecurePoint?
I don't think it is related to the client, rather some server config(?).
I just tested Viscosity on a fresh Windows 10 Pro VM on the same system, but the results were the same.
Sometimes I can max out the connection, but mostly it is much slower.
The person who gives the deciding clue gets $10 from me via PayPal.
Viscosity uses a 64 bit TAP system, which I pointed at earlier to poke at. The fact that your same machine works fine under a Linux VM (client), but not Windows locally, or via VM points away from it being a server issue.
Sorry, I didn't mean directly a server problem, but rather a problem with the client or server config.
I don't have any suggestion, but I want to say that I've used Viscosity and the normal OpenVPN GUI on Windows 10 and I never had this problem. Most of them were setup using one of the main OpenVPN install scripts on Github on various CentOS 7 VMs. Edit: Using PCIe WiFi adapter
If it's only Windows on the same hardware which is bitching, and works OK with a virtualized Linux client at the lower level, it's an issue, sure, but it's not hardware or network related on layer 2.
So, what NIC do you have in the machine? I've asked this before, and pointed what to look at/for as a possible issue.
Look to see if "Big frames" are enabled/disabled, or even an option.
At this point, run OpenVPN with
--mtu-test
Sorry, didn't see it.
The system has an Intel I218V.
Try turning off all power management and see if it works any better.
Alternatively, run the --mtu-test as mentioned above, and then set --fragment to whatever it says above.
The only option I found was, to disable that the PC could turn off the NIC to save energy.
Is that correct?
I will give the MTU test a try. I have to test it under windows, or?
BTW: I just ran the speedtest again on the linux client, and I had a short burst of around 27-29Mb/s, which equals around 230 Mbit/s.
But I only have a 170Mbit/s connection.
Can it have anything to do with the fact, that I have downloaded the file several times? Or is it somehow calculated wrong due to the VPN?
https://pastebin.com/QbDu98CR
Yes, that should disable some energy savings issues; Also check under any Advanced management tab. It still doesn't make sense that it changes with a sub-client unless it's automatically fragmenting the packets. You should be able to do an MTU test from the client side.
Since you're saving the same file to /dev/null and using wget, a non-caching program, I can't outright explain the speed difference, unless you're being traffic shaped down to 170Mbit.
There was common issue on windows 7 with slow speed, the issue was the windows tap driver. Try with their tap driver, maybe will work for you. I had same issue on win 7 and this solved it.
Tutorial here : https://helpdesk.privateinternetaccess.com/hc/en-us/articles/226694948-I-can-connect-to-the-VPN-but-my-speeds-are-really-slow-using-Windows
That could be one reason I never had this issue (mentioned in my post above), I am actually using the one PIA provides.
I will do some more tests later when I’m at home.
I will let you know the results.
Try Pritunl?
If it works fine on a Linux VM but not on Windows it sounds like a driver issue specific to Windows.
He's using Pritunl already
Didn't help unfortunately.
The speed still varies a lot.
I just installed the OpenVPN client on my Linode VPS with Debian 9 installed and tested the throughput there and I can't get over around 60 Mbit/s.
Without the VPN 2Gbit/s without a problem.
Looks like the problem is related to something else. It makes less and less sense to me
I increase the reward to 15$ for the person who gives the deciding clue.
Well, I think we've isolated the problem to you.
I don't think so.
It's a normal OpenVPN setup from the installer script.
https://github.com/Nyr/openvpn-install
Have you tried using default buffer sizes?
Try these as well: