leet
Three other independent IT professionals and I have done over 30 hours of testing and have concluded that OpenVPN itself slows down maximum data transfer rates, and can very noticeably decrease speed.
The purpose of this post is to help generate awareness of OpenVPN's throughput (data transfer rate) inefficiency in hopes that it could be fixed by one of the bright minds within this community.
Even if you don't take my word on anything I say, please take the time to test for yourself, and remember that these opinions are from three IT professionals who independently validated the claims on different hardware, with different configuration files, and in different parts of the world.
To start, the Windows OpenVPN Community client is much slower and inefficient at transferring data than the Linux (CentOS) OpenVPN Community Client.
How much faster is the Linux client? There is not a consistent number, we have seen it vary from anywhere between 1.5 to 7 times faster. On average, it's around 2 to 5 times faster. However, there also appears to be an inefficiency in Linux's OpenVPN data transfer rate, although much less noticeable than the Windows inefficiency. These Linux and Windows inefficiencies not only limit the bandwidth you achieve to a fraction of potential bandwidth, but they also effectively limit maximum bandwidth to around 85mbps on all tests that we've done. Furthermore, our speed testing methodology has effectively ruled out flaws in the speed testing mechanism itself, so we are virtually 100% confident that the throughput inefficiency lies within OpenVPN's design or the way it interacts with the OS. We have tried varying the MTU (up to 1500) and other config options with no success. We have heard that raising the MTU above 1500 may help improve speeds, but we've also heard that it may cause data transmission issues for many people over the internet (as opposed to a LAN).
Among Windows OpenVPN clients, the OpenVPN community client's speed is inferior to that of Viscosity.
According to Eric, the main Viscosity developer, "Any noticeable difference is in the way Viscosity engages and sets up the TAP adapter, not in the TAP driver code itself." Right now, we believe Viscosity is the fastest of all the Windows OpenVPN clients on the market (testing on average about 1.5 to 4 times faster than OpenVPN community client), however, even Viscosity has a flaw. Its speed can be very inconsistent. One speed test can be 1.5 to as much as 10 times slower than the next. Another Windows OpenVPN client called Securepoint is also inferior to Viscosity and about equally as fast as the OpenVPN Community Client.
It is surprising to the four of us that despite all the intelligence and ingenuity in this community that almost nobody seems to have noticed or addressed OpenVPN's data transfer rate inefficiency. We have a few theories as to why:
First, most people don't know what the maximum transfer rate they can expect from their VPN servers is (something they must measure by downloading directly from their server through http or ftp), and therefore they don't know what they're missing out on speedwise.
Second, most people who use VPNs expect a loss of speed and performance so they don't attribute it to anything but internet routing inefficiency rather than the OpenVPN software itself. Many of us who use VPNs are often using servers in different parts of the world, and the distinction between normal expected loss of speed (a loss that would also be seen on a direct file transfer from the server) and the loss of speed caused by the OpenVPN client-server link itself becomes difficult to distinguish.
Third, many of us are happy as long as the VPN speed is fast enough to do what we want, and don't bother to say anything.
To give you an idea of the speed differences we've observed:
While running the Windows 7 OpenVPN Community client vs the Linux client, we would typically see a download rate of 4-6mbps on Windows and 15-25 on Linux. On a faster server, a download of 15-35mbps through Windows would be around 65-85 through Linux. Viscosity would typically test on par and sometimes faster than Linux, however, Viscosity's results would fairly regularly plummet to 1/4 or 1/2 of their norm without any reason. To summarize, Viscosity seems to be faster than the Community client and sometimes even slightly faster than Linux, however, it just doesn't seem to deliver this speed as consistently as Linux.
In conclusion, there is a significant loss of speed that takes place due to client-side inefficiencies using the Windows and Linux OpenVPN Community clients (it's most profound on the Windows Community client), and there is also a maximum cap on speed of around 85mbps through any OpenVPN client.
Given that there are some issues to be addressed, I would really love to hear feedback, experiences, or advice from any of you. If you believe that you have or can develop a solution to the issue, that's even better and I may even offer a monetary reward 😉
I will be checking back on this thread regularly in the coming days and weeks
Many thanks to the community for making all this possible!
tlhackque
If you expect a response, drop the generalities and post specifics of your tests:
Each endpoint's hardware config, OS, patchlevels, client & server versions, configs. Same for intermediate hardware, e.g. routers, modems, etc.
Document the test methodology so that someone else can reproduce your results. Say how you characterized the underlying network - without OpenVPN. If you wrote software/scripts - post them too. If you didn't: stop waiting and write scripts to automate and summarize the testing. Then post them with the configs and detailed results from running those scripts.
On linux, dump the network configuration from /proc - there are lots of tuning parameters there.
On windows, do the same for the registry.
In my experience, saying "hey, we did a lot of tests and your stuff is slow -- go test it yourself" is inadequate documentation of a problem.
You need to make it possible for your results to be reproduced - easily - if you want anyone to pay attention.
That won't guarantee a response - but not doing your part will guarantee the lack of one.
Unless you're just trolling.
