http://blog.backslasher.net/ssh-openvpn-tunneling.html
The Story
I was asked to take care of a security challange - setup Redis replication between two VMs over the internet.
The VMs were in different continents, so I had keep the bandwidth impact to a minimum. I thought of 3 options:stunnel, which uses tunnels TCP connections via SSL
SSH, which has TCP tunneling over it's secure channel (amongst its weponary)
OpenVPN, which is designed to encapsulate, encrypt and compress traffic among two machinesI quickly dropped stunnel because its setup is nontrivial compared to the other two (no logging, no init file...), and decided to test SSH and OpenVPN.
I was sure that when it comes to speed, OpenVPN will be the best, because:The first Google results say so (and they even look credible)
http://superuser.com/a/238801
http://security.stackexchange.com/a/68367
http://support.vpnsecure.me/articles/tips-tricks/comparison-chart-openvpn-pptp-ssh-tunnel
Logic dictates that SSH tunneling will suffer from TCP over TCP, since SSH runs over TCP, [while] OpenVPN, being a VPN software, is solely designed to move packets from one place to another.I was so sure of that, that I almost didn't test [but, after testing, the results showed that as] long as you only need one TCP port forwarded, SSH is a much faster choice, because it has less overhead. I was quite surprised.
(Score: 3, Offtopic) by Whoever on Sunday November 26 2017, @01:42AM (7 children)
First of all, you can forward multiple ports with SSH.
Secondly, I am going to suggest that either there is something odd about what he is trying to do, or he has messed up the setup somehow.
I can run an OpenVPN tunnel and get test results with speedtest.net which are almost the same as the test run without the VPN. It's possible that what I am seeing is the effect of the compression when using the VPN, but even so, this shows that OpenVPN performs well.
Note that in his tests SSH is faster when compression is off. This is a clear indication that either his test methodology has a problem, or there is something very strange about the data transfers he is doing.
I don't buy his explanation of the speed difference that the VPN has to encapsulate additional source/destination information. This may well be true, but it should not be significantly more data: not enough to explain a speed difference of 3x.
He doesn't show his configuration files, depite urging people who criticize him to do so.
Lastly, this blog posting is almost 3 years old. I now that SoylentNews can be slow, but this is ridiculous.
(Score: 1, Informative) by Anonymous Coward on Sunday November 26 2017, @04:21AM
> Lastly, this blog posting is almost 3 years old. I now that SoylentNews can be slow, but this is ridiculous.
It's a repost from HackerNews (discussion [ycombinator.com]), which regularly features old articles (though they usually tag them with the year). Even seeing stuff from the 70s is not unusual over there.
(Score: -1, Troll) by Anonymous Coward on Sunday November 26 2017, @07:16AM (2 children)
"Offtopic"? Really?
Wow, the moderation here is based on spite, isn't it.
Well, fuck you, whoever modded me down. Probably one of the snowflake Libertarians, who can't stand it when I point out that their ideas are based on falsehoods and ignorance.
(Score: 1, Offtopic) by The Mighty Buzzard on Sunday November 26 2017, @12:18PM (1 child)
Nope. That was your one guess. You'll just have to remain in ignorance now.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Monday November 27 2017, @02:51AM
Snowflake Libertarian detected!
(Score: 0) by Anonymous Coward on Sunday November 26 2017, @07:50AM
The SSH compression is indeed a smell of bad methodology, however if You transfer binary or compressed data, trying to compress it further will only result in a slowdown.
(Score: 2) by TheRaven on Sunday November 26 2017, @02:42PM (1 child)
Nope, that's the expected behaviour for SSH on a modern network. The compression adds latency and this ends up triggering TCP congestion control on a fast network. I seem to recall that the OpenSSH man page documents this and warns you not to use compression on a fast network - it was great for X forwarding on a MODEM, where the compression saved a lot of bandwidth and didn't add much to the 100+ms latency of the connection, but it typically results in a slowdown on modern fast networks.
sudo mod me up
(Score: 2) by Whoever on Sunday November 26 2017, @06:13PM
I think that it depends on the relative speeds of the network and the processor. If the CPU can't compress and encrypt as fast as the data can be transmitted over the wire, then the limitation is CPU cycles.
Following this idea, perhaps the real issue was the different ciphers used by SSH and OpenVPN in his setup. Perhaps the cipher used by OpenVPN is slower than the one used by SSH.