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.
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).
For everyone else, I recommend https://pritunl.com or https://www.zerotier.com to get VPN access easily. Pritunl is more traditional client/server while ZeroTier creates 1 giant LAN between as many machines as you want.
1. My country bans a lot of websites, so I'm often using netherlands VPN to circumvent this ban. Also internet provider at my work sends angry emails when I'm downloading torrents, so I'm downloading them over VPN as well. I don't really see any alternative to VPN.
2. My home server contains some interesting services for me (file storage, movies, music, passwords), but I don't want to expose them to the internet, so I exposed it to VPN and protected with very minimal authorization (nginx checking value of specific cookie acting as a password). So I'm using VPN as a main protection for weakly protected services.
3. I didn't implement it yet, but I want to receive my mail on my home server. Currently mail server operates on VPN server, so I can't really be sure that nobody reads my mail. But operating e-mail requires static IP and reverse-ptr record which isn't available from my home internet provider. So I want to use some kind of port mapping with VPN to transfer everything to my home server. Though ssh would work well here, but I would need to think about reconnecting if network is down, I expect VPN to be more stable.
Many companies (including startups) have internal tools that are web applications. While the more adventurous firms put these on public IPs behind an employee login/SSO system, the more conservative will always have them behind VPN. VNC is a drastically worse UX than a local browser unless your endpoints are really bad.
Honestly, I think you can get a similar security posture with a reverse proxy enforcing client certificates and 2FA (this is what my employer does), but people feel more comfortable trusting VPN appliances from big-name vendors than their nginx configs. Harder to fail open, certainly.
Ssh to access various servers/git repos/my desktop. Ssh in a local window is always snappy. Terminal access in a RDP/VNC window is not. Not to mention modifier key issues etc...
"Wow a little googling on this subject led me to sshuttle, which I've never heard of before but looks awesome"
sshuttle is indeed awesome - a viable VPN that requires nothing on the endpoint but a functioning ssh login (and python on the remote host).
So any host, anywhere, with no configuration (and no permission required by the operators) that you can ssh into ... is now a VPN endpoint for you.
Sibling comments in this thread are pointing out that ssh has this functionality already and that is true, but some configuration and maintenance (and understanding) is required. Not so with sshuttle.
ALSO:
We (rsync.net) sponsored the reworking of the ipfw target for sshuttle so that it now works properly on FreeBSD with the --dns option, etc. We also sponsored proper UDP tunneling for sshuttle on FreeBSD but I am not sure those patches are in a -release version of FreeBSD yet ...
You need to use FreeBSD 11.0 (not 11.1) and you need to:
git clone https://github.com/sshuttle/sshuttle.git
cd sshuttle ; git checkout c746d6f7db3efbad6caddea76bdf916c46cf5c6e
... and that will get you a working sshuttle on FreeBSD with --dns support.
I mention this every time VPNs come up... It's just so much better than any of the other VPN clients if you are only interested in TCP, I've been using it for over 6 years.
The key difference between it and VPN protocols for anyone trying to compare is: TCP only, and TCP decompile/recompile with SSH in the middle. This has many advantages: speed (TCP over TCP is megga sucky obviously), server setup (basically none, you just need non-root access to an ssh server with python).
It really is as simple as making an SSH connection on the command line and you can route all your TCP traffic immediately.
It also has some really nice fine grained subnet routing features... On some strange occasions when I have needed it i have merged multiple remote subnets into the same virtual one one my machine by selecting ranges. It also has an auto discovery feature built in if you just want to route the specific IPs that exist on the other side.
sshuttle is also in a number of package managers now, it's in apt at least.
sshuttle is basically magic to me. Wherever someone with no idea about their threat model has deployed firewalls (ala every major business I've ever worked at) sshuttle is usually the key to being productive for me.
I've found that sshuttle with the --dns option still leaks dns queries occasionally so I set my web browser and curl to use SOCKS and run sshuttle to try to catch anything else.
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.
Your downside I don't think applies in this case. Because it's a single application wanting to make a single reliable connection. So if there was any packet loss at all it would have to stall the whole connection anyways regardless of whether it's wrapped in SSH, OpenVPN, or nothing.
Well-known unpredictable TCP-over-TCP performance would only explain OpenVPN/TCP results.
But OP has posed also OpenVPN/UDP performance that is 2x...3x slower than SSH port forwarding, so I'd guess there is more to this story (see also andmarios's impromtu test results above).
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.
`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:
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.
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.
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.
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.
Does anyone have any experience with ipop/groupvpn[0]? It seems like an interesting alternative to tinc in that it can do turn/stun using libjingle to bust nat. I'm not clear on how well tested or secure it is though.
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.
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.
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.
[Zerotier](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.
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.
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.
All you need is an SSH server running at home or in the "cloud".
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 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.
[+] [-] DrPhish|8 years ago|reply
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|8 years ago|reply
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
[+] [-] manigandham|8 years ago|reply
[+] [-] vbezhenar|8 years ago|reply
2. My home server contains some interesting services for me (file storage, movies, music, passwords), but I don't want to expose them to the internet, so I exposed it to VPN and protected with very minimal authorization (nginx checking value of specific cookie acting as a password). So I'm using VPN as a main protection for weakly protected services.
3. I didn't implement it yet, but I want to receive my mail on my home server. Currently mail server operates on VPN server, so I can't really be sure that nobody reads my mail. But operating e-mail requires static IP and reverse-ptr record which isn't available from my home internet provider. So I want to use some kind of port mapping with VPN to transfer everything to my home server. Though ssh would work well here, but I would need to think about reconnecting if network is down, I expect VPN to be more stable.
[+] [-] closeparen|8 years ago|reply
Honestly, I think you can get a similar security posture with a reverse proxy enforcing client certificates and 2FA (this is what my employer does), but people feel more comfortable trusting VPN appliances from big-name vendors than their nginx configs. Harder to fail open, certainly.
[+] [-] michaelmior|8 years ago|reply
Wow, didn't know that. Impressive!
[+] [-] pcl|8 years ago|reply
[+] [-] pletnes|8 years ago|reply
[+] [-] ryanschneider|8 years ago|reply
http://sshuttle.readthedocs.io/en/stable/usage.html
Basically "vpn over ssh" (not really, but close enough).
[+] [-] rsync|8 years ago|reply
sshuttle is indeed awesome - a viable VPN that requires nothing on the endpoint but a functioning ssh login (and python on the remote host).
So any host, anywhere, with no configuration (and no permission required by the operators) that you can ssh into ... is now a VPN endpoint for you.
Sibling comments in this thread are pointing out that ssh has this functionality already and that is true, but some configuration and maintenance (and understanding) is required. Not so with sshuttle.
ALSO:
We (rsync.net) sponsored the reworking of the ipfw target for sshuttle so that it now works properly on FreeBSD with the --dns option, etc. We also sponsored proper UDP tunneling for sshuttle on FreeBSD but I am not sure those patches are in a -release version of FreeBSD yet ...
You need to use FreeBSD 11.0 (not 11.1) and you need to:
... and that will get you a working sshuttle on FreeBSD with --dns support.[+] [-] tomxor|8 years ago|reply
The key difference between it and VPN protocols for anyone trying to compare is: TCP only, and TCP decompile/recompile with SSH in the middle. This has many advantages: speed (TCP over TCP is megga sucky obviously), server setup (basically none, you just need non-root access to an ssh server with python).
It really is as simple as making an SSH connection on the command line and you can route all your TCP traffic immediately.
It also has some really nice fine grained subnet routing features... On some strange occasions when I have needed it i have merged multiple remote subnets into the same virtual one one my machine by selecting ranges. It also has an auto discovery feature built in if you just want to route the specific IPs that exist on the other side.
sshuttle is also in a number of package managers now, it's in apt at least.
[+] [-] chx|8 years ago|reply
Edit: why the downvote? I thought I asked a legit question...?
[+] [-] Retr0spectrum|8 years ago|reply
sshuttle also claims to have avoided the "TCP over TCP" problem.
https://stackoverflow.com/questions/41427123/how-does-sshutt...
[+] [-] XorNot|8 years ago|reply
[+] [-] Scarbutt|8 years ago|reply
[+] [-] joveian|8 years ago|reply
[+] [-] noir_lord|8 years ago|reply
Handy when you want to do something private on a machine you don't have a VPN setup on.
[+] [-] xrisk|8 years ago|reply
[+] [-] dexterdog|8 years ago|reply
If you're using a windows client I recommend bitvise tunnelier.
[+] [-] GordonS|8 years ago|reply
A shame it's a bit more involved to get working with Windows, it's a pain to have to start a Linux VM to be able to use it :(
[+] [-] nyolfen|8 years ago|reply
[+] [-] zzzcpan|8 years ago|reply
[+] [-] ajross|8 years ago|reply
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.
[+] [-] Buge|8 years ago|reply
[+] [-] aexaey|8 years ago|reply
But OP has posed also OpenVPN/UDP performance that is 2x...3x slower than SSH port forwarding, so I'd guess there is more to this story (see also andmarios's impromtu test results above).
[+] [-] jacob019|8 years ago|reply
[+] [-] skarap|8 years ago|reply
[+] [-] jakobegger|8 years ago|reply
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|8 years ago|reply
Btw I use unix sockets on client and server to avoid the local connection TCP overhead.
[+] [-] andmarios|8 years ago|reply
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.
[+] [-] whalesalad|8 years ago|reply
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|8 years ago|reply
[+] [-] proctor|8 years ago|reply
[0] http://ipop-project.org/
[+] [-] ryan-c|8 years ago|reply
[+] [-] gerdesj|8 years ago|reply
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|8 years ago|reply
Why? I plunk down a lot of stuff on my blog, not everything is up to that pretty high standard you mention.
[+] [-] nly|8 years ago|reply
[0] https://www.tinc-vpn.org/
[+] [-] proctor|8 years ago|reply
[+] [-] k_vi|8 years ago|reply
Setup the tunnel: ssh -D 8080 [email protected]
Change your system proxy settings: Socks proxy, 127.0.0.1, 8080
Done!
[+] [-] morpheuskafka|8 years ago|reply
[+] [-] staunch|8 years ago|reply
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.
[+] [-] j_s|8 years ago|reply
[+] [-] pferde|8 years ago|reply
[+] [-] jonathanoliver|8 years ago|reply
[+] [-] foxhop|8 years ago|reply
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
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|8 years ago|reply
[+] [-] jstewartmobile|8 years ago|reply
[+] [-] hardwaresofton|8 years ago|reply
https://vadosware.io/post/ssh-tunneling-using-an-intermediar...
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|8 years ago|reply