Not to diminish this important work at all, just a question for HN: do I have a minority viewpoint in thinking key-based SSH to a bastion host and forwarding traffic via SOCKS (ssh -D) or ProxyCommands serves 99% of the use cases for a sysadmin’s need for a VPN? (Corp networks and L2 privacy needs notwithstanding.)
I used such a setup at my last job for all my work (which had the advantages that I could use a Chromebook; I definitely couldn't install some random vendor VPN client on it). It was great. We primarily had the SSH bastion box for emergencies when the $network_vendor VPN acted up, but you were allowed to use it as your day-to-day VPN if you wanted and I definitely did.
The big downside in my eyes is that it's TCP-based, so your latency properties with non-TCP connections aren't what you want (e.g., you can't meaningfully use Mosh) and if the connection drops / your IP changes, your single connection goes down and you have to restart it manually. Wireguard is UDP-based and handles roaming, so even if you switch networks, your tunneled TCP connections are fine.
Also, it's a real network connection, so non-TCP/UDP things like ping work, you get an actual failed connection when the remote server doesn't respond instead of a successful one that drops immediately, etc. If you have root on both sides of the connection, ssh -w will also get you a real network device. (But also if you have root on both sides, you might as well set up an actual VPN.)
It’s a fine way to get started; sure. You probably need ssh anyway and getting forwarding up for free is neat. It also had the historical advantage of existing; wireguard is new. Perf is sometimes not great, but at least you’re likely to get better crypto than most default OpenVPN installations I’ve seen. But it’s not a great long-term solution; whereas wireguard will last you for a long time :-)
Sorry, I meant scale over number of boxes and services, not so much scale over time. Other people in this thread have given some rationale, but: perf, better baseline crypto (you always know what you’re getting), it’s a real network connection so you can talk to hosts with stuff like ICMP, smaller trusted codebase, more confidence in the underlying protocol...
I think the answer is mostly that it's hard to route most traffic over SOCKS, most applications don't obey the system-wide proxy settings, you might be leaking DNS queries, things like that.
Still not as thorough as a full-fledged "real" VPN, but for most ad-hoc purposes, something like sshuttle [0] works well and doesn't require application-specific configuration.
I am very excited about sshuttle (and in fact, rsync.net has sponsored work on it).
The most compelling aspect of sshuttle, in my opinion, is that any host running sshd can be an endpoint - no software is required. As long as the sshd in question has python available, you can use it as an endpoint.
if you are willing to let a vpn client abuse your system, you might also want to set a network interface that routes all traffic to the ssh tunnel. might be trivial to add as a module if not available already.
In most configurations, it’s trivial to use the os native VPN client, with some minor caveats. This creates a tunnel device and does what 99% of end-users working remotely need.
the OS vpn still have the same problems. For example, you can run an application that asks the OS to not use the vpn. That is why most vpn clients will break your ability to set proxies (try to enable cisco enterprise vpn client on OSX and then open charles proxy and see how sad you will be)
my point is: on all setups you have traffic that might go around the vpn tunnel, that is an application defect not that ssh tunels are worse.
Edit: If so, why?