My issue with this solution and sshuttle was performance is good for web browsing and other basic tasks, but good luck with more complicated higher-bandwidth stuff.
That being said I did not use it more than a few days and maybe people have better anecdotes than me. I personally would stick with a properly configuring OpenVPN, or FreeSWAN if the whole HTTP/SSL tunneling VPN systems aren't your bag.
I agree that IPSEC should be the fastest & best, because it avoids the tun/tap device and works at the packet level. Anything that uses tun/tap and/or a TCP transport is not going to be as good; it needs tricks like sshuttle's very interesting ones. So I would guess that, of OpenVPN, sshuttle and OpenSSH, that OpenSSH/my script would be the worst because it uses tun/tap, TCP and has few if any tricks. But it is also the only one that "works for me", and I am very comfortable running SSH on my machines, and also with SSH security, and I find the key-trust model very simple to work with.
As to more demanding uses, I haven't tried e.g. accessing a video site like the BBC iPlayer, though maybe I should do so "in the name of science".
It's not the TUN/TAP device that gets you; it's tunneling TCP over TCP, which wrecks havoc with TCP's retransmission algorithm[1]. I've personally done measurements and the bandwidth of a TCP connection over a UDP OpenVPN tunnel is just as good as the bandwidth without using a tunnel. In contrast, the bandwidth of a TCP connection over a TCP OpenVPN tunnel is significantly worse.
You may theoretically have worse performance with a TUN/TAP tunnel compared to an IPSEC tunnel because the packets have to travel into and out of userspace whereas IPSEC stays in the kernel, but I've never noticed this in practice. In contrast, the TCP performance degradation is very noticeable in practice.
ssh -D24424 user@xxx.com worked great for me. Personally I use Proxifier for all my proxy needs, I have few of them - like a tor prosy, my vps proxy, my work proxy.
Cheap VPS with a prepaid (gift) card = poor's man VPN.
Good point - thanks for bringing it up. This option gives you a SOCKS tunnel (only), which is great for web-browsing and other apps, but won't just automatically do "all traffic".
It does seem that SSH has a lot of ways to do a "VPN", some of which are better for different things. I think it is very underutilized!
"OpenSSH for Mac: An amazing ‘VPN’ that requires almost no configuration."
How is running a custom script every time you need connect 'almost no configuration'? It's all relative, I suppose, but having to procure/run a Python script just to make a VPN connection is too much hassle for me.
What Justin ought to do is wrap his script into a menubar item, and submit it to the App Store. That would truly require "almost no configuration" because:
a) downloading/installing the script would be easier, even when using a strange Mac in a cafe or lab environment
b) making a VPN connection would be no less convenient than Apple's VPN menubar item.
It's not a bad idea! I'm comparing the configuration to setting up an IPSEC or OpenVPN server&client, not just the client - that involves a lot of configuration. Certainly now that the server setup is almost eliminated (you need sudo + PermitTunnel), the client script is now the "tallest nail".
I do like the fact that a script exposes its inner workings and is easy to modify. It also sounds like TCP over TCP might be sufficiently problematic (in the general use case) that this option may be unsuitable for others.
Oh hey! Yes, configuring OpenVPN is sucky. I tried used Tunnelblik some time ago, but it was pretty flaky and I went back to using L2TP. Re: editing your script, you could always add a 'settings' option that launches your config script in a text editor (hrm, unless that's verboten now because of sandboxing).
SSH on an iOS device is too slow to run something like video playback over. I'm hoping that IPSec will help fix that but there seems to be a lack of any good documentation of setting up IPSec in a roadwarrior config (using racoon).
If you're fortunate enough to be part of a newer Windows domain, you may already be using one of the more practical VPN clients in history; DirectAccess.
As frustrating and expensive as Microsoft tech may be, it sure works wonders sometimes!
IPv6 was my primary motivation. The interesting thing here is that - once the tunnel is set up - we're really not running any extra software other than SSH (on the client or on the server). My script just finds unused tunnels and IPs, calls SSH and sets up networking. So it is as unlikely to crash your machine as OpenSSH is :-)
However, I would guess that a grey screen of death bug is due to a kernel-space issue, i.e. the Tun/Tap drivers. They are not built into OS X, which seems a real shame (as they're used with every user-space VPN: OpenVPN, sshuttle etc).
It is possible that sshuttle is doing something wrong causing the tun/tap drive to crash. I would guess that my script would crash as often as OpenVPN does, as I bet/hope ssh is as solid as OpenVPN. If OpenVPN crashes as often as sshuttle, then the problem is likely the tun/tap driver.
I hope to be trying this on a Mac in the next few days... just need to buy one first!
As of Mac OS X 10.6 (xnu 1456.1.26), Darwin has native user tunnels. utun devices are sockets rather than character devices and are created through a special control socket.
They behave the same as the Free/OpenBSD tunnels, in that they prepend the IP version as a 32-bit word.
Thank you so much for that (genuinely!). This is the reason I love HN: in this discussion we have someone that pointed out the probably-good-enough-for-the-99% SOCKS proxy (let them eat SOCKS!), and you've now pointed me to the "right" tun/tap device for Mac OS X, saving me from hours of fixing something that is obsolete.
Now I really need to get a Mac and get this working there!
We're currently using it in Cloak for Mac. (https://getcloak.com/ -- bbits is our github organization and Cloak's parent company.)
Previously we maintained (and used) the tuntaposx kext, but keeping it up to date was becoming a burden. At WWDC, some of Apple's fine kernel networking engineers shared the proper incantations with us; this patch is the result.
Australian (and many other) mobile providers seem to break most OpenVPN based VPNs - there's no public IPv4 address provided anymore and the OpenVPN server doesn't seem to know how to route traffic back to the client.
Can you elaborate on this at all? I connect to an OpenVPN server while behind NAT all the time and it has worked behind almost every possible network configuration I've tried (no NAT, "home" NAT, carrier-grade NAT, cellular data, etc.).
If you want the best possible reliability, run the server on port 443 with TCP (even though UDP is almost always better for performance since TCP over TCP is icky). You have a much better chance at not being blocked by firewalls, and it actually works on a lot of the less-sophisticated captive portals without first logging in.
(Granted, the article is talking about using OpenSSH and not OpenVPN—but I suspect that should work fine behind NAT as well).
Interesting - as long as SSH works, this will work. That said, I thought OpenVPN worked with the client behind NAT as well, so I guess I don't really understand the problem.
Thanks for the heads up. But the only IP I see in there is 172.31.254.1, which is the address we assign to the host in the VPN private network - part of the 172.16... range.
In case that you want to fend off eavesdropping by NSA, you shouldn't. But I simply just want to watch youtube, browse blogspot/wordpress pages and get around of the Great Fire Wall, so I do not care.
I'm not worried about NSA here: they can track my packets even if I use secure VPN software. I'm worried about the coffee-shop-WiFi variety of attacks.
I feel this is misleading because it's actually just an advertisement for the author's software. But keep in mind that the entire point of using a VPN is plausible deniability. You aren't anonymous because any sufficiently sophisticated adversary can monitor your traffic and the VPN's traffic and correlate the two. Your defense comes from being able to claim that another user was controlling the VPN at that time. So rolling your own VPN isn't a good idea unless it also generates false traffic.
Well, my script is free + open source, so I think "advertisement" has some connotations that aren't quite fair :-) It's not really "my" software - all the real work is done by OpenSSH, which is heavily reviewed, supports NAT traversal, and you probably already have it installed. All credit to OpenSSH, all faults are my own. I would love it if this prompted a discussion of this "VPN" strategy, and my script's functionality found its way into core SSH.
It's definitely not appropriate for doing something illegal or where you want plausible deniability for other reasons. I point that out fairly clearly in the README, though I should have made it clearer in the blog.
I would wager though that many VPNs don't actually offer much more security than this. The good ones (LavaBit, CryptoSeal) did. How do you verify that your VPN provider isn't handing over this information just as readily as this approach does?
Generating false traffic is a good idea, but I don't think you should rely on that if you want to use this for illegal purposes.
Nah, I didn't read it that way. It seems to me it says "hey, OpenSSH can already do tunnels very effectively, but it's not very easy, so here's a quick script I wrote to make it easier".
The author gain to reader gain is really, really low in this case, so I don't think it's content-free linkbait.
No worries! I'm sorry you felt the title was unrelated; I like more "flowery" titles, and we have the "same title" rule on HN.
The point I was trying to make with the title is that OpenSSH does a lot of what a full "VPN" does, yet is a _lot_ easier to configure than anything else I've encountered. Apart from PPTP, which is apparently the "rlogin" of VPNs ;-)
free652 posted an even easier approach here, which sets up a SOCKS proxy with no extra configuration. If SOCKS is good enough, you should use that! If you want full tunneling, hopefully we can make my script easier / unnecessary.
But keep in mind that the entire point of using a VPN is plausible deniability.
Err.. no it's not.
The point of using a VPN is protection against eavesdropping.
Some may use it for plausible deniability, but that isn't even the most frequent use case (I'd imagine the most frequent use is access to corporate networks).
Sorry, the entire point of using a VPN for privacy.
"Privacy" yes - as in avoiding eavesdropping. NOT for plausibly deniability.
To quote the post:
I use VPNs not for illegal purposes, but (1) to get IPv6 wherever I am, (2) to prevent casual snooping on my web traffic (the Firesheep scenario) and (3) to get onto a ‘private’ network.
None of those purposes require plausibly deniability.
> But keep in mind that the entire point of using a VPN is plausible deniability
People usually reach for a VPN when they do not trust the link they are using. e.g. it's coffee shop wireless. A VPN obscures the traffic travelling over the dangerous link and delivers it to the endpoint where it is usually on-routed.
On the whole, VPN's do NOT provide anonymity, they provide privacy. VPN connections always need a fixed endpoint which likely has some sort of billing relationship with you.
If you really want to help with privacy and stuff and also think long term, it would certainly be better to invest in an internet router where you can directly install TOR (as relay). If a lot of people would do this you could solve the slowness and make it even harder to identify users.
Imagine some ISPs start rolling out such routers per default.
VPN is used for telecommuting. Without VPN, the company would have to expose a lot of intranet services to the internet for us to be able to work from home, and to be on call at night would entail staying at the office all night.
The fact that the first (only) use for VPN you can think of is to hide criminal activity says a lot about you, really.
Because it can protect the sensitive (internal corporate network) information while its travelling over untrusted networks, with the destination being none the wiser.
Bridging two networks (or a host and a network) together securely over the internet has far more applications than merely telecommuting and is so effective and easy to apply, why not use it to protect your Facebook session while you're at the coffee shop?
That being said I did not use it more than a few days and maybe people have better anecdotes than me. I personally would stick with a properly configuring OpenVPN, or FreeSWAN if the whole HTTP/SSL tunneling VPN systems aren't your bag.