It does. It was updated a couple of months ago to use the new pfctl framework of -E/-X to enable/disable the firewall and uses the existing hooks in the firewall to automatically insert/remove rules as necessary.
I used this for a while in summer while I travelled to China, it worked shortly before the powerful GFW blocks it deadly, along with openvpn-over-443-port etc that I tried, which also failed soon after it's used for a short while.
it does, 443 still leaks pattens(e.g. packet length and when/how they're sent/received,etc), that GFW can detec and tell if it's a typical 443 or openvpn-over-443. also 80 has no security at all and I don't know what it can be used for this purpose.
That might work if you have root on the system you are connecting to, but in a lot of cases you might not. In a corporate scenario sshuttle has been life saver because it makes it simple to make networks behind a jump server look and feel like they are just a router hop away. This makes using stuff like VMWare easier since it usually requires direct access to the hosts on various different ports and makes it difficult to set up port forwarding.
5 minutes is an exaggeration, but I've done it in an hour. It's not really OpenVPN's fault, though - most of that time was dealing with Windows firewall, home router port forwarding (through those god-awful, buggy http interfaces they put on routers), and iptables.
Just use Shadowsocks, unless you're on iOS, in which case use PPTP. These both work reliably for me, and with the latest versions of OSX.
If you need something more resistant to DPI, check out stunnel or obfsproxy as carriers for OpenVPN. Switch ports regularly as well. You needn't change server config to do this: just use iptables to forward stuff so your server's stunnel daemon is listening on hundreds of ports.
One of the primary use cases, as described on the main page linked, is for systems where you aren't an admin of the remote system, and thus can't use iptables as you describe.
I love sshuttle. You can point it at any ssh server (that has python installed on it) and you don't need any special privileges on the remote end.
One problem is that it does not support DNS tunneling if FreeBSD is your client.[1]
Item: we (rsync.net) would be willing to pay for development that gets sshuttle to work properly and bulletproof on FreeBSD. In fact, we would be willing to pay for sshuttle development in general. Email us.[2]
Also, what is up with this new fork ... which speaks from the original authors point of view and, in fact, has his own personal notes cut and pasted into the README. In fact, the contact information is the original author - Avery Pennarun apenwarr@gmail.com - what's going on here ?
[1] No, the note about IPFIREWALL_FORWARD does not fix this problem.
Right, sure - but given that the readme has the authors personal backstory and his name and email, it surprises me that the forks author did not fix that up.
sshuttle is really cool, except both macs I've run it on would have weird system crashes while running it.
I ended up creating a proper VPN via a microtik router and have enjoyed the superior performance compared to sshuttle, though it was several orders of magnitude more effort to get going! sshuttle was almost too easy to get up and running :)
A python script should not be able to make your Mac crash (depending on what you mean by "weird system crash"). If it actually causes a hard crash, that likely either points to a weird hardware/software problem on your system, or it's a bug that Apple would like to know about if they don't already.
24 comments
[ 2.9 ms ] story [ 57.6 ms ] threadEDIT: Appears this fork does support Yosemite, it's even installable via Homebrew.
I've used it extensively on Yosemite.
An OpenVPN server can go from zero to done in under 5 minutes (for HN readers, less) with a Docker container: https://github.com/kylemanna/github
If you need something more resistant to DPI, check out stunnel or obfsproxy as carriers for OpenVPN. Switch ports regularly as well. You needn't change server config to do this: just use iptables to forward stuff so your server's stunnel daemon is listening on hundreds of ports.
... Only recently had issues during the parade using with the Linode IP range. DigitalOcean no problems.
One problem is that it does not support DNS tunneling if FreeBSD is your client.[1]
Item: we (rsync.net) would be willing to pay for development that gets sshuttle to work properly and bulletproof on FreeBSD. In fact, we would be willing to pay for sshuttle development in general. Email us.[2]
Also, what is up with this new fork ... which speaks from the original authors point of view and, in fact, has his own personal notes cut and pasted into the README. In fact, the contact information is the original author - Avery Pennarun apenwarr@gmail.com - what's going on here ?
[1] No, the note about IPFIREWALL_FORWARD does not fix this problem.
[2] info@rsync.net
I ended up creating a proper VPN via a microtik router and have enjoyed the superior performance compared to sshuttle, though it was several orders of magnitude more effort to get going! sshuttle was almost too easy to get up and running :)
1: http://www.dest-unreach.org/socat/doc/socat-tun.html
2: https://en.wikipedia.org/wiki/N2n
http://blog.jpatrick.io/tube-socks/