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.
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).
Through the MQTT app on my phone I can view and control the home heating, see the output from various sensors (like house temp and outside temp) and control some of the lights - all without having to send my data to a commercial product's cloud service to manage things.
The IoT hub is an Atom-based Mini ITX machine running Ubuntu server, Mosquitto (MQTT message broker), Node-Red (MQTT message handler) and Home Assistant to manage some of the sensors and automation (although Node-Red does most of the work). I'll probably move the whole lot to a Raspberry Pi at some time.
This setup is more of a base to exercise my electronics hobby skills than a serious attempt to automate everything - for example, the home heating IoT stuff overlays (rather than replaces) the traditional electronic timer and temperature sensors on the heating/hot water system, so if the IoT cleverness goes offline, watchdog relays will return control to the old timer/sensors.
VPN access is through a Draytek xDSL Router (2860) - they have good inbuilt VPN support.
Are you always connected to your VPN on your mobile device? How much network traffic overhead does it add?
http://packetpushers.net/podcast/podcasts/pq-134-meet-zeroti... <- Here's a Pod with the creator of ZT, once you've listened to it you'll realize how it fits everyone =)
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.
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.
Wow, didn't know that. Impressive!
And since Flix has succesfully banned all commercial VPN's, I am more and more contemplating seting up a "share your own local IP for Flix affectionados" with a couple of people.
How do others solve / done / consider this?
Basically "vpn over ssh" (not really, but close enough).
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.
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
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.
Edit: why the downvote? I thought I asked a legit question...?
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
sshuttle also claims to have avoided the "TCP over TCP" problem.
I've never had to use them since as you say few are that hardcore in their lockdowns, but it's nice to know they exist.
> OpenSSH has built-in TUN/TAP support using -w<local-tun-number>:<remote-tun-number>. Here, a layer 3/point-to-point/ TUN tunnel is described. It is also possible to create a layer 2/ethernet/TAP tunnel.
Just with invalid terminology (s/ssh/OpenSSH) and the likelihood of the added slowdown mentioned in the article.
man 1 ssh:
Requests tunnel device forwarding with the specified tun(4)
devices between the client (local_tun) and the server
The devices may be specified by numerical ID or the keyword
``any'', which uses the next available tunnel device. If
remote_tun is not specified, it defaults to ``any''. See also
the Tunnel and TunnelDevice directives in ssh_config(5). If the
Tunnel directive is unset, it is set to the default tunnel mode,
which is ``point-to-point''.
Tunnel Request tun(4) device forwarding between the client and the
server. The argument must be yes, point-to-point (layer 3),
ethernet (layer 2), or no (the default). Specifying yes requests
the default tunnel mode, which is point-to-point.
Specifies the tun(4) devices to open on the client (local_tun)
and the server (remote_tun).
The argument must be local_tun[:remote_tun]. The devices may be
specified by numerical ID or the keyword any, which uses the next
available tunnel device. If remote_tun is not specified, it
defaults to any. The default is any:any.
Specifies whether tun(4) device forwarding is allowed. The argu-
ment must be yes, point-to-point (layer 3), ethernet (layer 2),
or no. Specifying yes permits both point-to-point and ethernet.
The default is no.
Independent of this setting, the permissions of the selected
tun(4) device must allow access to the user.
Handy when you want to do something private on a machine you don't have a VPN setup on.
If you're using a windows client I recommend bitvise tunnelier.
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 :(
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.
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).
$ 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
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.
Btw I use unix sockets on client and server to avoid the local connection TCP overhead.
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.
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.
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.
AutoSSH plus some firewall scripts to ensure data only travels through the VPN would suffice.
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.
Why? I plunk down a lot of stuff on my blog, not everything is up to that pretty high standard you mention.
Setup the tunnel: ssh -D 8080 email@example.com
Change your system proxy settings: Socks proxy, 127.0.0.1, 8080
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.
DHCP is IP/UDP.
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.
> 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.
All you need is an SSH server running at home or in the "cloud".
I documented this a few years back:
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.
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).
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.
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.
EDIT: did not see UDP results. There is still something else going on here, thats still much too slow for openVPN (without tweaking).
Possibly the SSH encryption could have been more optimal for their use case?
Its basically a script which takes care of ssh, the routing, and firewalling. Its crossplatform, should work on Windows/Linux/macOS and perhaps more.
https://github.com/apenwarr/sshuttle is the original, now abandoned, sshuttle. Development was taken over by:
... which is the current, maintained version that you should track.
I rely on both, and like having both options around.