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.<p>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.<p>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.<p>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.<p>Honest question
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:<p><a href="http://sshuttle.readthedocs.io/en/stable/usage.html" rel="nofollow">http://sshuttle.readthedocs.io/en/stable/usage.html</a><p>Basically "vpn over ssh" (not really, but close enough).
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.<p>The problem is that in the presence of any packet loss at all, every packet lost causes a stall of the <i>whole tunnel</i> 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.
Using SSH Tunnels is not TCP over TCP.<p>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.<p>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.
There should be some catch in the setup. Maybe the CPUs he used are old and don't support hardware AES acceleration?<p>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.
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.<p>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”<p>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.
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.
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.
A very intelligent write up with one small, possibly fatal flaw.<p>When you are comparing one thing to another and writing up your pearls of wisdom for the masses you need to control <i>every</i> variable (within reason).<p>I can't see a LAN based test acting as a baseline.
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.<p>[0] <a href="https://www.tinc-vpn.org/" rel="nofollow">https://www.tinc-vpn.org/</a>
SSH tunnel as proxy is easier and simpler to use if you have a VPS.<p>Setup the tunnel: ssh -D 8080 vv@xx.xx.xx.xxx<p>Change your system proxy settings: Socks proxy, 127.0.0.1, 8080<p>Done!
[Zerotier](<a href="https://zerotier.com" rel="nofollow">https://zerotier.com</a>) 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.
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.<p>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.<p>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.<p>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.
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.
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.<p>All you need is an SSH server running at home or in the "cloud".<p>I documented this a few years back:<p><a href="http://www.foxhop.net/ssh-tunnel" rel="nofollow">http://www.foxhop.net/ssh-tunnel</a><p>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.
I recently had to set up a 3 computer SSH tunnel and wrote about it, maybe people will find it interesting:<p><a href="https://vadosware.io/post/ssh-tunneling-using-an-intermediary-computer/" rel="nofollow">https://vadosware.io/post/ssh-tunneling-using-an-intermediar...</a><p>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.
>"As long as you only need one TCP port forwarded, SSH is a much faster choice, because it has less overhead than SSH."<p>OpenVPN is way more robust solution for tunneling though.<p>I've found that UDP tunnels work sometimes better in when there is considerable packet loss and high latency (poor radio links).
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.
I use both actually, where the best tool is applicable.<p>Some commenters have mentioned StrongSwan (or OpenSwan which is more known to me).<p>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.
What's the fastest option when you do need UDP?<p>Generally I just use SSH, but for gaming i've resorted to 160bit OpenVPN.<p>Incidentally setting up a OpenVPN server on dd-wrt is a rather hellish experience.
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.<p>EDIT: did not see UDP results. There is still something else going on here, thats still much too slow for openVPN (without tweaking).<p>[1] <a href="http://sites.inka.de/bigred/devel/tcp-tcp.html" rel="nofollow">http://sites.inka.de/bigred/devel/tcp-tcp.html</a>
I use <a href="https://github.com/apenwarr/sshuttle" rel="nofollow">https://github.com/apenwarr/sshuttle</a> but it's often too slow. I am wonder if their exist any go/rust equivalent of this project.