
SSH vs. OpenVPN for Tunneling - setra
http://blog.backslasher.net/ssh-openvpn-tunneling.html
======
DrPhish
I used to maintain an ipsec VPN for road warrior type scenarios, but I've
found that mostly I just wanted to get a remote desktop on a computer within
the network.

So I've stopped mucking around with VPN and just published Apache Guacamole
HTML5 VNC/RDP tunnels. No plugins, no clients except a modern web browser and
good security with certbot+auto redirect to https+simple auth to keep badguys
away from possible exploits in the guacamole login form. Configs can be as
simple as the NoAuth plugin, all the way to full integration with eg. AD. I've
implemented this at a number of businesses, and it does what almost everyone
in the organization wants. It also supports things like printing (to a pdf
that comes thru the browser as a download) and file transfer. Super easy to
set up and is much more responsive than VNC or RDP thru ssh.

The times when I actually want full IP access to a network from my laptop are
so rare that it seemed silly to maintain IPSec.

What need do others have for full-connectivity VPNs? Not site-to-site VPNs of
course, but these ad-hoc on the road type ones.

Honest question

~~~
bhauer
I recently wrote about my home VPN setup in a previous HN thread [1]. But to
answer your question, the additional use-cases I have are:

1\. I connect to my home file server from all of my devices. This allows me to
access my singular master file system from everywhere, which includes all of
my documents and data. For example, I can reach my Keepass database from all
devices without any need for clumsy synchronization or a third-party "cloud"
provider.

2\. I view my security camera streams by reaching my on-premises NVR from
anywhere.

3\. I can print to home from anywhere.

4\. My entire media library is available from anywhere.

5\. I can reach my family's home intranet web-app from all of my devices
(e.g., my phone), natively.

It's true that all of this _could_ be done in a remote desktop window, but it
would be less smooth and less convenient. E.g., using Keepass in a remote
desktop window wouldn't be as convenient as running it locally (with the kdbx
loaded from the file server).

[1]
[https://news.ycombinator.com/item?id=15586997](https://news.ycombinator.com/item?id=15586997)

~~~
GordonS
What protocol do you use to access your Keepass database from your mobile
device?

Are you always connected to your VPN on your mobile device? How much network
traffic overhead does it add?

~~~
Fnoord
Plus, what's the performance impact on your smartphone? Battery life,
available resources.

------
ryanschneider
Wow a little googling on this subject led me to sshuttle, which I've never
heard of before but looks awesome, will try it out on Monday:

[http://sshuttle.readthedocs.io/en/stable/usage.html](http://sshuttle.readthedocs.io/en/stable/usage.html)

Basically "vpn over ssh" (not really, but close enough).

~~~
chx
What's the difference between that and
[https://github.com/darkk/redsocks](https://github.com/darkk/redsocks) ?

Edit: why the downvote? I thought I asked a legit question...?

~~~
aexaey
You can skip sshuttle's magic and do exactly the same thing manually with "ssh
-D" \+ "iptables -j REDIRECT" \+ redsocks, but that's a lot moving parts.

------
ajross
This has been known forever. Stream-based packet tunneling absolutely does
outperform packet wrapping in good network conditions, for the simple reason
that small packets can be combined by the transport layer and avoid the
overhead.

The problem is that in the presence of any packet loss at all, every packet
lost causes a stall of the _whole tunnel_ until it gets retransmitted, which
even in the best case recovery conditions requires two (three? I forget my
SACK details) round trips. If one side is using traditional TCP retransmit
timers it can be much, much longer.

~~~
jacob019
I've been using a VPN over TCP ssh for a year. The end point is across the
world. I get excellent bandwidth and no stalls. Latency is less than
anticipated. The thoretical arguments against TCP/TCP do not match my
experience.

~~~
ajross
Yeah, real world network paths, especially inter-data-center ones, generally
do operate at exactly zero packet loss. Until they don't, alas.

------
skarap
`ip link set qlen 1000 dev tun0` (so it matches the eth0 queue, instead of
being an order of magnitude smaller) on both ends of the tunnel, and you get
90% of direct connection speed from openvpn:

    
    
      $ iperf3 -c 10.1.0.2
      Connecting to host 10.1.0.2, port 5201
      [  4] local 10.1.0.1 port 38274 connected to 10.1.0.2 port 5201
      [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
      [  4]   0.00-1.00   sec  3.12 MBytes  26.1 Mbits/sec    0    802 KBytes
      [  4]   1.00-2.00   sec  22.3 MBytes   187 Mbits/sec    0   2.24 MBytes
      [  4]   2.00-3.00   sec  21.4 MBytes   179 Mbits/sec    0   2.45 MBytes
      [  4]   3.00-4.00   sec  23.3 MBytes   196 Mbits/sec    0   2.39 MBytes
      [  4]   4.00-5.00   sec  23.4 MBytes   196 Mbits/sec    0   2.58 MBytes
      [  4]   5.00-6.00   sec  21.5 MBytes   180 Mbits/sec    0   2.70 MBytes
      [  4]   6.00-7.00   sec  23.5 MBytes   197 Mbits/sec    0   2.68 MBytes
      [  4]   7.00-8.00   sec  22.6 MBytes   189 Mbits/sec    0   2.78 MBytes
      [  4]   8.00-9.00   sec  22.4 MBytes   188 Mbits/sec    0   2.45 MBytes
      [  4]   9.00-10.00  sec  23.5 MBytes   197 Mbits/sec    0   2.69 MBytes
      - - - - - - - - - - - - - - - - - - - - - - - - -
      [ ID] Interval           Transfer     Bandwidth       Retr
      [  4]   0.00-10.00  sec   207 MBytes   174 Mbits/sec    0             sender
      [  4]   0.00-10.00  sec   207 MBytes   174 Mbits/sec                  receiver
    
      iperf Done.

------
jakobegger
Using SSH Tunnels is not TCP over TCP.

You have a TCP connection between local app and SSH client, then a second TCP
connection between SSH client and SSH server, and a third TCP connection
between SSH server and remote app.

There is no TCP over TCP when you use SSH tunnels. Lost packets between SSH
client and SSH server do not cause retransmits on either application side.

~~~
erdewit
That's what I thought too, that there is just a byte stream being tunneled
between SSH server and client and not a TCP packet stream.

Btw I use unix sockets on client and server to avoid the local connection TCP
overhead.

------
andmarios
There should be some catch in the setup. Maybe the CPUs he used are old and
don't support hardware AES acceleration?

I just run iperf3 over OpenVPN / UDP with AES-256-GCM between two servers in
the same DC (but different rooms, through their public network, 1gE links) and
got an average of 750MBits/sec. I don't have any special setting.

~~~
SomeStupidPoint
Out of curiosity -- what's your SSH tunneling rate in the same setup?

~~~
andmarios
Just tested. Ssh has indeed better performance, at around 870Mbit/sec.

But the gap in my -anecdotal- testing is much smaller than OP's and maybe
predictable due to the differences (as OP described) on how OpenVPN and ssh
work.

------
whalesalad
It’s really not an apples to apples comparison. For my teammates on the
development team, yes an SSH tunnel is going to be easier for our needs due to
the reduced overhead. But if I want to give my customer support team access to
private web services in our production cluster, a VPN is the perfect solution.

At FarmLogs, each of our Kube clusters has a bastion VPN host that puts you
inside the VPC and handles DNS to Route53 (and the VPC) so <service>.farmlogs
“just works”

We use Foxpass to handle this with LDAP bridged to Google Apps so when an
employee joins or leaves their VPN access is immediately updated.

------
mirimir
A huge advantage of vpn tunnels is that they stay up indefinitely. I've had
openvpn links stay up for months. With ssh, you're lucky to get a few days.
I've tried scripts and even autossh, and ssh has never been as reliable as
openvpn or tinc.

~~~
perlgeek
Now I wonder if there's a way to combine mosh's automatic reconnecting with
ssh tunneling somehow...

~~~
Fnoord
That's latency related. Mosh uses UDP only, sshuttle uses TCP only.

AutoSSH plus some firewall scripts to ensure data only travels through the VPN
would suffice.

------
ryan-c
I found that OpenVPN benefited greatly from setting larger tunnel MTUs and
then allowing the IP packets to be fragmented. I think it's encrypting per-
packet which is somewhat inefficient.

------
gerdesj
A very intelligent write up with one small, possibly fatal flaw.

When you are comparing one thing to another and writing up your pearls of
wisdom for the masses you need to control _every_ variable (within reason).

I can't see a LAN based test acting as a baseline.

~~~
bartvk
> you need to control every variable

Why? I plunk down a lot of stuff on my blog, not everything is up to that
pretty high standard you mention.

------
nly
One thing I hate about OpenVPN is the ridiculous configuration. I'm a big fan
of tinc[0] personally, although you have to use 1.1pre releases to get half
decent encryption, it's configuration is wonderful.

[0] [https://www.tinc-vpn.org/](https://www.tinc-vpn.org/)

~~~
proctor
tinc 1.1pre seems pretty good, but I do worry about the legacy fallback for
encryption; There doesn't seem to be any way to e.g. --force-experimental to
prevent encryption falling back to the old RSA mode.

------
k_vi
SSH tunnel as proxy is easier and simpler to use if you have a VPS.

Setup the tunnel: ssh -D 8080 vv@xx.xx.xx.xxx

Change your system proxy settings: Socks proxy, 127.0.0.1, 8080

Done!

~~~
foxhop
Yup, even works using putty.exe on Windows ([http://www.foxhop.net/ssh-
tunnel](http://www.foxhop.net/ssh-tunnel))

~~~
fpoling
And with PAC JavaScript files one can redirect only specific hosts to ssh or
redirect to different ssh connections.

------
morpheuskafka
[Zerotier]([https://zerotier.com](https://zerotier.com)) is far nicer than all
of them, clients (Win, macOS, GNU\Linux, OpenWrt, iOS, Android, NAS) are open-
source and the hosted service allows up to 100 devices on one of unlimited
networks for free. Because it emulates the ethernet layer, there is no client
side configuration required and it can be used for non-IP packets (ex. DHCP).
By enabling the default route permission on the client it can also be used as
a gateway to the internet through a remote host on the network. All
communications are e2e AES-256 with certificate-based access for private
networks. Oh, and they also run a public earth network with unlimited members
billed as "the global LAN party." It's a really convenient service, and the
performance is good enough to be used between private clouds.

~~~
yjftsjthsd-h
I'm really tempted to use this, but I'm a little nervous about relying on a
company for this, especially because it doesn't look like they should be
profitable on their current offerings.

~~~
ac2u
Correct me if wrong, but I think that aside from their web based portal,
everything else is open source. So you could control everything via API.

So if they ever did go out of business, you could host it yourself and I'm
sure by then an open source web portal would emerge to take the main site's
place. (Not to mention that they'd probably just release the web app if they
were going out of business).

Hope it never comes to that though, I'd imagine their main bread and butter
would be larger enterprise licenses.

------
staunch
1\. Doesn't look like there were runs of iperf over UDP and TCP, with
simulated buffer sizes, so hard to know what the network connection is even
capable of.

2\. Also, how reliable is the network connection? Maybe it fluctuates every
minute in usable bandwidth due to congestion or jitter. VMs are subject to
noisy neighbor issues.

3\. It looks like the ciphers are different, which could of course affect
throughput greatly if one is not hardware accelerated or if its CPU bound.
Worth checking CPU and other system resource usage for differences.

4\. You could try OpenVPN with encryption and/or compression disabled entirely
in UDP mode for best possible performance IIRC. This, at least, you would
expect to beat an SSH tunnel.

~~~
stock_toaster

      > 2. It looks like the cipher "AWS128-CTR" is being used for
      > SSH, I'm not even sure what that is. I'd look at CPU and 
      > other system resource usage for differences.
    

My guess is just a typo, for AES128-CTR.

------
j_s
Worth looking at ZeroTier (commercial - actually running a hardware IndieGoGo
right now) and WireGuard (IPSec - 'The Next Generation' / 'Voyager' or
whichever you thought was best) as modern options.

~~~
pferde
I like that Wireguard is slowly sneaking into common use. Its performance
seems promising.
[https://www.wireguard.com/performance/](https://www.wireguard.com/performance/)

~~~
j_s
I believe it is headed for Linux kernel mainline soon-ish.

[https://news.ycombinator.com/item?id=15596963](https://news.ycombinator.com/item?id=15596963)

------
foxhop
If you are a road warrior (or you want to bypass security filters at work) you
can securely proxy Firefox web and DNS traffic over a VPN using just SSH.

All you need is an SSH server running at home or in the "cloud".

I documented this a few years back:

[http://www.foxhop.net/ssh-tunnel](http://www.foxhop.net/ssh-tunnel)

This is also a great way to access resources on the remote network, for
example your router/modem setup page or Jenkins, or whatever else is running
on that remote Network.

------
antonios
spiped would also be interesting to compare. Ridiculously easy to set up, and
made by cperciva.

------
jstewartmobile
Didn't see any mention of MTU in the post. If the defaults were sub-optimal
for OpenVPN, that alone would account for the reduced throughput.

------
hardwaresofton
I recently had to set up a 3 computer SSH tunnel and wrote about it, maybe
people will find it interesting:

[https://vadosware.io/post/ssh-tunneling-using-an-
intermediar...](https://vadosware.io/post/ssh-tunneling-using-an-intermediary-
computer/)

I first tried to setup OpenVPN and only wanted to use the the SSH tunnel for
DNS purposes (I couldn't use normal DDNS tools), but in the end, I ended up
running a SOCKS proxy over the tunnel and it was stunningly effective, enough
that watching Netflix despite intercontinental round trips.

------
unixhero
Any love for Softether vpn here? I use it every day to connect gome and it
just woeks. Always. It encapsulates ssh I think

------
qplex
>"As long as you only need one TCP port forwarded, SSH is a much faster
choice, because it has less overhead than SSH."

OpenVPN is way more robust solution for tunneling though.

I've found that UDP tunnels work sometimes better in when there is
considerable packet loss and high latency (poor radio links).

------
acd
IPSec on Linux has better performance than OpenVPN due to multi core support.
That said setting up VPN tends to be time consuming and error prone. But what
if the ssh connection drops, what restarts the tunnel then? IPSec has restart
mechanism for when the net drops which it will do.

------
INTPenis
I use both actually, where the best tool is applicable.

Some commenters have mentioned StrongSwan (or OpenSwan which is more known to
me).

I've actually seen OpenSwan perform better than Cisco VPN tunnels. And I love
pointing that out to our networking guys since we pay nothing for OpenSwan.

------
sireat
What's the fastest option when you do need UDP?

Generally I just use SSH, but for gaming i've resorted to 160bit OpenVPN.

Incidentally setting up a OpenVPN server on dd-wrt is a rather hellish
experience.

------
throwaway2048
The overhead of layer 2/3 packet headers in OpenVPN did not cause such a huge
slowdown, its much more likely that OpenVPN was operating in TCP mode, and
thus subject to the tcp-in-tcp[1] problem with tunnel internal tcp sessions.
Even an extraordinarily slow machine by modern standards can manage 100mbit
openVPN without much of an issue.

EDIT: did not see UDP results. There is still something else going on here,
thats still much too slow for openVPN (without tweaking).

[1] [http://sites.inka.de/bigred/devel/tcp-
tcp.html](http://sites.inka.de/bigred/devel/tcp-tcp.html)

~~~
sitharus
Reading TFA both TCP and UDP OpenVPN modes were tested. UDP was about three
times faster than TCP, but SSH was three times faster than that.

Possibly the SSH encryption could have been more optimal for their use case?

------
sanbor
There is a very simple test: fast.com. I tried fast.com over sshuttle and
OpenVPN and OpenVPN was faster while sshuttle kind of collapsed.

------
Yegorius
I wonder why nobody has mentioned StrongSwan (IPSec+IKEv2) or ShadowSocks,
which are both performant and very secure.

~~~
Canada
Shadowsocks is not very secure at all. Static keys and naive crypto. But that
doesn't matter much since its primary use is for obfuscation.

~~~
computerfriend
I would love to read more about Shadowsocks security, if you have a link.

------
throwaway613834
How do you redirect DNS over SSH though?

~~~
Fnoord
Sshuttle [1] takes care of that see --dns and --help and the documentation.
You might also wanna disable IPv6 --disable-ipv6

Its basically a script which takes care of ssh, the routing, and firewalling.
Its crossplatform, should work on Windows/Linux/macOS and perhaps more.

[1]
[https://github.com/apenwarr/sshuttle](https://github.com/apenwarr/sshuttle)

[2]
[https://sshuttle.readthedocs.io/en/stable/](https://sshuttle.readthedocs.io/en/stable/)

~~~
rsync
Just a clarification ...

[https://github.com/apenwarr/sshuttle](https://github.com/apenwarr/sshuttle)
is the original, now abandoned, sshuttle. Development was taken over by:

[https://github.com/sshuttle/sshuttle](https://github.com/sshuttle/sshuttle)

... which is the current, maintained version that you should track.

------
josteink
They're different beasts with different use-cases.

I rely on both, and like having both options around.

------
saasproduct
I use
[https://github.com/apenwarr/sshuttle](https://github.com/apenwarr/sshuttle)
but it's often too slow. I am wonder if their exist any go/rust equivalent of
this project.

------
khanjahanzaib27
Cool Keep it up.

