7 ms·

The Best VPN Is The One You Use

49 points by justinsb 13y ago

gkanai 13y ago
OpenSSH is blocked by the Great Firewall in China. Thus useless for that key use case.
- ttflee 13y ago
  Tips: Do not choose the cheapest one. The PPTP service I subscribed works most of the time.
  - idupree 13y ago
    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 13y ago
      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 13y ago
        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.
- rsync 13y ago
  It is ? I traveled through Hong Kong, Shanghai and Shenzhen for weeks in November 2011 and was able to ssh anywhere I needed to ... I was staying in nice, expensive, western chain hotels ... perhaps that made a difference ?
imperialdrive 13y ago
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!
nilved 13y ago
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 13y ago
  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 13y ago
    Sorry, perhaps linkbait was a better term. I can't comment on the software itself, but the title is unrelated to the content.
    - justinsb 13y ago
      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.
free652 13y ago
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 13y ago
  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!
cowmix 13y ago
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 13y ago
  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 13y ago
    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/bsd/net/if_utun.c http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bs... Also: https://github.com/bbits/openvpn-utun https://github.com/bbits/openvpn-utun
    - justinsb 13y ago
      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!
616c 13y ago
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 13y ago
  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 13y ago
    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
voltagex_ 13y ago
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 13y ago
  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_ 13y ago
    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.
- justinsb 13y ago
  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.
- lmm 13y ago
  Huh? You can configure openvpn to run over ipv6. I'd've thought the problem was more likely to be trying to connect via NATed IPv4.
charlesism 13y ago
"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 13y ago
  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 13y ago
    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).
  - charlesism 13y ago
    Check out this example, if you want to make a menubar item in Python: http://stackoverflow.com/a/5072734 http://stackoverflow.com/a/5072734
  - newman314 13y ago
    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).
wobbleblob 13y ago
Maybe you should have removed your IP from the source code before placing it on github
- justinsb 13y ago
  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 13y ago
    Nope, I didn't recognize it. Please ignore my post :)

49 points by justinsb 13y ago

gkanai 13y ago

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

ttflee 13y ago
Tips: Do not choose the cheapest one. The PPTP service I subscribed works most of the time.
- idupree 13y ago
  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 13y ago
    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 13y ago
      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.
rsync 13y ago
It is ? I traveled through Hong Kong, Shanghai and Shenzhen for weeks in November 2011 and was able to ssh anywhere I needed to ... I was staying in nice, expensive, western chain hotels ... perhaps that made a difference ?

imperialdrive 13y ago

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!

nilved 13y ago

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 13y ago
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 13y ago
  Sorry, perhaps linkbait was a better term. I can't comment on the software itself, but the title is unrelated to the content.
  - justinsb 13y ago
    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.

free652 13y ago

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 13y ago
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!

cowmix 13y ago

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 13y ago
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 13y ago
  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/bsd/net/if_utun.c http://www.opensource.apple.com/source/xnu/xnu-2050.18.24/bs... Also: https://github.com/bbits/openvpn-utun https://github.com/bbits/openvpn-utun
  - justinsb 13y ago
    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!

616c 13y ago

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 13y ago
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 13y ago
  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

voltagex_ 13y ago

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 13y ago
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_ 13y ago
  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.
justinsb 13y ago
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.
lmm 13y ago
Huh? You can configure openvpn to run over ipv6. I'd've thought the problem was more likely to be trying to connect via NATed IPv4.

charlesism 13y ago

"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 13y ago
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 13y ago
  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).
- charlesism 13y ago
  Check out this example, if you want to make a menubar item in Python: http://stackoverflow.com/a/5072734 http://stackoverflow.com/a/5072734
- newman314 13y ago
  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).

wobbleblob 13y ago

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

justinsb 13y ago
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 13y ago
  Nope, I didn't recognize it. Please ignore my post :)