An alternative approach is to use my own tun2socks program [1][2], instead of tsocks. This utilizes an integrated lwIP stack to transparently expose the proxy to the entire OS. It's a little tricky to set up the network interface and routing, but then works with pretty much everything.
Note, tun2socks is used internally in the Android versions of Psiphon3, ShadowSocks and Tor's Guardian/Orbot.
Windows is supported and works, there should be no reason to add new code.
The only thing lacking is a recent Windows build. However, it should be easy to build via https://github.com/Alexpux/MINGW-packages .
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?
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?
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.
AFAIK shadowsocks is just a SOCKS proxy server with some features, correct? You then need to tell each application to actually use the server; some applications may not have such a configuration option.
sshuttle on the other hand changes your routing so that all TCP requests go through a SSH tunnel. No further configuration is needed on the application side. It does fall short of a full-blown VPN though in that it doesn't do UDP.
Surprised to see it here, as I assumed that everyone on HN would know already how to use ssh proxy.
Nevertheless, in my experience Firefox works astonishingly bad with it. From time to time (probably, as some connections expire or whatever: I'm pretty sure it depends on network configuration at your location) Firefox just stops responding to user actions. It doesn't really freeze: buttons are clickable and you can open a new tab, but clicking on a link or entering a new url does nothing. No errors, simply nothing. I never filled a bug report, as I cannot actually work out what happens or how to reproduce it, but that thing happens to me only when Firefox is working through SOCKS 5 via ssh and it's frustrating as hell.
That's odd. As another anecdote, I use this nearly everyday to access internal services on work's network (I work remotely). I use Chrome normally and have Firefox set up to use my "SOCKS over SSH" proxy and can't recall the last time I had any issues with it.
I've had weird experiences with long-lived ssh tunnels and have often resorted to initializing the ssh tunnel from a python script and using a heartbeat to manage the state of the tunnel to terminate and reinitiate the tunnel process if it hangs for more than 10 seconds. That only works if the applications working over the tunnel can tolerate dropped TCP connections, eg HTTP + some connection retry logic which opens a TCP socket per request vs rsyslog (without RELP) which trusts TCP's ack mechanism.
I use Firefox with FoxyProxy extension for years (both on Windows and Linux) with more than 20 different SOCKS 5 via ssh proxies simultaneously (with configured IP rules for each), had no problems whatsoever.
I had a poor man's ssh VPN before we got a real VPN at work.
The basic idea was for each host and port, H:P, that I needed to access at work from home I'd put an entry in /etc/hosts with a 10.10.10.x IP address.
I'd pick some local port, L, and set up ssh to forward 127.0.0.1:L to remote H:P.
Finally, I'd set up via iptables (Linux) or ipfw (OS X) a rule to turn connections to 10.10.10.x:P into connections to 127.0.0.1:L.
ipfw disappeared from OS X with Yosemite (and I vaguely recall that something changed in OS X networking earlier, maybe around Mountain Lion, that broke the way I was using it) and since we have a real VPN now I haven't tried to figure out how to fix my poor man's VPN.
FWIW, there are machines and networks here where I'd fire staff on the spot for setting up unauthorized remote access to. There are a few machines I've been responsible for where I'd be calling the police instead of HR.
It's easy for most of us to do this. That doesn't mean it's a good idea. If you're doing this on someone else's machines or network, be 100% sure you've got permission (if it's a work machine - even if that means just setting your work desktop machine up to VPN into your own home network - get that permission in writing...)
Back in late '90s a friend lived in a student dorm which had a then-fast 512 kbps Internet connection. It was heavily firewalled - UDP only to ISP's nameservers, TCP only to ISP's web proxies. ICMP was passed anywhere, though, so he wrote a small program which encapsulated a TCP stream in ICMP "host unreachable" reply packets, IIRC. The other end of the tunnel ran on a machine at the place where he was interning as a junior programmer. Debugging the program was slightly painful because he couldn't obviously be at both ends of the tunnel simultaneously, but he got it to work in a couple of weeks. It wasn't very tolerant of packet loss - IIRC it didn't have any mechanism to resynchronize the connection if there was any, but instead there was some method of reinitializing the connection. Anyway, running SOCKS on top of all this made the ISP-crippled connection usable in a normal manner.
Ahh, dorms are often the first place people start experimenting with this kind of stuff :)
I remember doing something similar at a friends dorm. They had a filter to only allow HTTP/HTTPS traffic via their proxy, so I used some HTTP tunnel tool to push a VPN connection through it.
It was pretty weak but it worked for basic usage. I remember having a real hard time figuring out what was causing VPN connections to drop intermittently. That's how I learned about HTTP keep-alives.
While people often enjoy learning about these hacky techniques, its worth noting that the situation OP described goes against some good security principles. There's a reason why company networks are _officially_ only accessible via a VPN - it makes it possible for network/itsec people to properly monitor who accesses the infrastructure and how. This is very important if you want to keep your company data safe and secure.
I know the author just wanted to show some easy ways to setup HTTP proxies, but I'd hate it if people thought its okay to do this in every IT environment. Talking about security is easy. But when it comes to actually following some sane standards like this...a lot of people seem to just ignore them for the sake of convenience. IMHO this seems to be status quo these days.
It's also very slow, since tunneling TCP over TCP has pretty bad performance. You either want to use UDP (OpenVPN), or terminate and proxy the TCP connection (SSH port forwarding).
That's interesting. IIRC tsocks doesn't emulate the select-style system call interface that chromium likely uses for its networking.
I'm a bit surprised to find that it works with Firefox; I generally prefer to configure proxies where possible as tsocks is a horrible (albeit very useful) hack.
May not be relevant to OP's use case but OpenVPN setup is not that bad, and could be very easy if you are willing to use pre-made setup script available online (e.g., https://github.com/Nyr/openvpn-install).
In other words, you don't have to be a poor man for VPN if you have the freedom (say with a throw-away cloud VPS).
Having said that, I need to point out again that OP's use case is completely different.
I use ssh -D to cheap VPSes, and dynamically use the proxy based on Firefox's FoxyProxy to route different URL requests through different networks.
Handy for anything from region locked websites (extremely common in streaming video) to local censorship (increasingly common in Western countries, especially around torrents).
Having to set up individual port mappings for arbitrary URLs (whose actual hosts may change on an arbitrary basis) is not a viable alternative, IMO.
Maybe I misunderstood you though. Is there an easier alternative approach that makes ssh -D superfluous?
We have quite a few different storage solutions, and among those most have really bad command line interfaces. At least one of them is web only, and trying to wrap it with WWW::Mechanize or something similar would be difficult due to all the fun stuff they do with javascript. Other solutions even want you to have flash support.
Most of us (Ingvar included) prefer CLI any day. I'm so looking forward to the day where all these SAN's are retired, and we're running Ceph for all.
I have a tor hidden service set up with ssh access and, I sometimes connect this way. Although it's fairly slow and laggy it enables access to web interfaces.
since I know how to use ssh I really don't understand anymore why VPN even exists. I mean, what can you with VPN that you can't do less complicated with ssh?
Note, tun2socks is used internally in the Android versions of Psiphon3, ShadowSocks and Tor's Guardian/Orbot.
[1] https://code.google.com/p/badvpn/wiki/tun2socks
[2] https://github.com/ambrop72/badvpn