

The Best VPN Is The One You Use - justinsb
http://blog.justinsb.com/blog/2013/10/21/the-best-vpn-is-the-one-you-use/

======
616c
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.

~~~
justinsb
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".

~~~
agwa
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.

[1] [http://sites.inka.de/sites/bigred/devel/tcp-
tcp.html](http://sites.inka.de/sites/bigred/devel/tcp-tcp.html)

------
free652
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.

~~~
justinsb
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!

------
charlesism
"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.

~~~
justinsb
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.

But it's definitely an interesting idea... :-)

~~~
charlesism
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).

------
imperialdrive
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!

------
cowmix
You mention sshuttle .. and aside from ipv6, what does your script offer over
what sshuttle does?

sshuttle crashes OSX (grey screen of death) about once a day, does your script
avoid that?

~~~
justinsb
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!

~~~
gonzo
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.

See:

[http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bs...](http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bsd/net/if_utun.c)

Also: [https://github.com/bbits/openvpn-
utun](https://github.com/bbits/openvpn-utun)

~~~
justinsb
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!

~~~
gonzo
Its just OS X now. Apple dropped the "Mac" part.

------
voltagex_
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.

~~~
ckuehl
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).

~~~
voltagex_
Sorry, I saw tun and tap and confused it for a configuration I've used in the
past.

I'll test the 3G connection within the next few hours, however I suspect the
providers have moved to block some kinds of tethering.

------
wobbleblob
Maybe you should have removed your IP from the source code before placing it
on github

~~~
justinsb
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.

Have you found a real IP I've missed?

~~~
wobbleblob
Nope, I didn't recognize it. Please ignore my post :)

------
gkanai
OpenSSH is blocked by the Great Firewall in China. Thus useless for that key
use case.

~~~
ttflee
Tips: Do not choose the cheapest one. The PPTP service I subscribed works most
of the time.

~~~
idupree
In case you don't know: Don't rely on the integrity or security of PPTP.
[https://en.wikipedia.org/wiki/PPTP#Security](https://en.wikipedia.org/wiki/PPTP#Security)

~~~
ttflee
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.

~~~
idupree
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.

You're right that PPTP is fine for your purpose.

------
nilved
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.

~~~
justinsb
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.

~~~
nilved
Sorry, perhaps linkbait was a better term. I can't comment on the software
itself, but the title is unrelated to the content.

~~~
StavrosK
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.

