Poor man's VPN via ssh socks proxy | Hacker News Reader

Poor man's VPN via ssh socks proxy

redpill-linpro.com

117 pointskvisle51 comments

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.

[1] https://code.google.com/p/badvpn/wiki/tun2socks

[2] https://github.com/ambrop72/badvpn

Jesus, if I'd known about this in high school I would have been in a lot of trouble.

I see it supports Windows, but the last commits towards that support were a while ago (?)

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 .

sshuttle will blow your mind then.

https://github.com/apenwarr/sshuttle

+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?

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.

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?

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?

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.

Right repo might be https://github.com/sshuttle/sshuttle/

I usually just use sshuttle, which does the ssh-vpn-proxying in one go.

$ sudo apt-get install sshuttle

$ sudo sshuttle --dns --no-latency-control -l 0.0.0.0 -vr username@hostname 0/0

After this you'll have a NATed IP address and all your TCP and DNS requests will appear to come from hostname.

That looks interesting, do you happen to know if it has any advantages (or differences) between itself and shadowsocks?

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.

Ah I see, thanks, great explanation.

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

One hypothesis for your firefox experience:

http://askubuntu.com/questions/344863/ssh-new-connection-beg...

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.

Here is a reddit comment giving examples of the hosts, ssh config, and iptables commands to set up a sample poor man's VPN this way: https://www.reddit.com/r/linux/comments/13nuda/poor_mans_vpn...

This actually worked very well, giving me full transparent access to everything I needed for working at home as if I was at the office.

I was recently fired for setting one of these up.

please elaborate ...

Breaching corporate proxy / filtering rules can often be a Big Deal.

Sorry to hear that.

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.

You can have a proper TUN interface over SSH too;

https://libsecure.so/t/things-you-might-not-know-vpn-over-ss...

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

Interestingly enough, tsocks (+ssh -D) works with firefox but not chromium.

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.

Looks like it does hook select: https://github.com/pc/tsocks/blob/master/tsocks.c#L343. However, it doesn't hook epoll, which is The Right Way to do operations on any number of sockets nowadays.

Ah yeah, thanks, that makes a bit more sense.

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.

No love for redsocks? http://darkk.net.ru/redsocks/ I like it and use it :)

Using tsocks+ssh is silly when ProxyCommand exists.

The -D option is a superfluous feature, IMHO. I always remember who proposed it and that alone discourages me from ever using it.

Why does the author have to use a "web gui"? Or maybe he doesn't have to, he just _wants_ to?

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 always remember who proposed it and that alone discourages me from ever using it.

And, uhm, who was it? Is it supposed to be common knowledge?

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?

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.

If you're on OS X, proxychains-ng is a nice alternative to tsocks.

I use it times to times, very simple to setup, quite reliable also.

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?

Performance (TCP in TCP). Routing (or bridging) traffic over it. Protocols that are not TCP or UDP.

tsocks is also handy for running applications over Tor that don't support it.

tsocks is gold. Used to use something similar a while back, glad to find it again.

Excuse my total ignorance but I don't live in the command line, so what is this sorcery you speak of useful for us mere mortals?

I really want to learn not to feel left behind.

Reply on news.ycombinator.com