Hacker News new | ask | show | jobs
by eeZi 3846 days ago
sshuttle will blow your mind then.

https://github.com/apenwarr/sshuttle

4 comments

Yes, I do think sshuttle is the right model for simple "poor mans" (or whatever) tunnels. I love how it works.

The problem is, it still does not work properly on FreeBSD - at least for name resolution. The ssh tunnel works fine, but your DNS goes outside of the tunnel.

So once again, let me state publicly - rsync.net will pay cash money for someone to fix sshuttle for FreeBSD. Just email info@rsync.net.

Good on you for offering cash in return for a fix. You may want to consider publicly disclosing amounts / conditions somewhere - https://github.com/sshuttle/sshuttle/issues maybe?
If you add `--dns` to the command line it will proxy DNS queries as well.
Yeah but the point is that this particular feature is broken on FreeBSD.
Is there a GitHub Issue and/or FreeBSD Problem Report for this? Could you provide links for them?
+1 to sshuttle. I use it with iodine[1] to bypass captive portals.

[1] http://code.kryo.se/iodine/iodine_manpage.html

Tunnelling IPv4 through DNS requests is brilliant. iodine is going in my toolbox, thanks. Just to be clear: you need to have an iodine server running somewhere, looking like a DNS server but acting as the equivalent of a vpn server, right?
I love sshuttle - I'd love to see a dead mans switch work with it and/or integration with desktop indicators.

Also, they say these things are "poor mans" but does this mean that it is inefficient than a real VPN? If so, would it be very inefficient?

sshuttle's performance is actually pretty good for what it does. You can even run it with PyPy. It's not going to be a bottleneck with a recent CPU and <1Gbit.

The way it does it is that is actually proxies the TCP connections instead of encapsulating them.

  Client <-A-> sshuttle client <-B-> sshuttle server <-C-> Server
By doing this, it sidesteps the issues you have with TCP in TCP encapsulation, especially with poor connections (the outer and the inner sessions would do their own flow control and interact badly). But this also means that it can only tunnel TCP connections. There's a fork at https://github.com/sshuttle/sshuttle which supposedly extends support to UDP, but I haven't tested it and it's only UDP, so ICMP and lots of other protocols are still unsupported. It also NATs all connections, relies on black magicâ„¢ for tunneling instead of using a tun/tap IF, uploads code to the server and requires shell access.

Those are a few reasons why it's really only a workaround or a remote access tool, not a replacement for a real, UDP-based VPN. Still invaluable for those use cases.