Sshuttle - tunnel all your traffic through ssh • Hacker News Board

Re: Sshuttle - tunnel all your traffic through ssh

#51

Post by apenwarr » Tue, Apr 05, 2011, 1:19 AM UTC

mike-cardwell wrote: post #31

jrockway wrote: post #20

Earlier quoted context omitted.

The setup cost is higher, true, but the performance is better. TCP-over-TCP does not work well.

I've heared the claim that TCP over TCP doesn't work well countless times. I've been using OpenVPN in tcp mode for at least 5 years on a daily basis and never noticed a problem. I've even done SIP over a TCP OpenVPN configuration without a noticeable problem. It makes sense to me that it should perform badly, and it probably does for uses cases with a lot of traffic, but for an average user on a laptop, a TCP based V…

What happens is you essentially get "infinite bufferbloat." When there's no packet loss, you end up absolutely filling the transmit buffers at the entry points to the tunnels. The result, as other people have mentioned, is extremely poor interactive performance when you're simultaneously transferring large files.

TCP-over-TCP not "broken" in the sense that the sessions will randomly drop or your kernel will crash or anything. It's just that doing it correctly is much better.

Mind you, given the prevalence of bufferbloat (mostly caused by misdesigned routers/DSL/cablemodems) nowadays, interactive performance already largely sucks when you're transferring large files. So you might not even notice a difference.

Bufferbloat makes me sad :(

Re: Sshuttle - tunnel all your traffic through ssh

#52

Post by chopsueyar » Tue, Apr 05, 2011, 1:28 AM UTC

wyuenho wrote: post #42

chopsueyar wrote: post #19

How would one go about setting this up with a firmware rewritable consumer-grade router? Can I have a ww-drt install act as a client with Sshuttle and install a public key to require no login?

You can have Python running on the DD-WRT box of course, which will probably drastically slow down your router. You can also generate a public key for the router and append it to a remote host's .ssh/authorized_keys file, but for reason number 1 above, it's probably not a good idea. Now if you have a PC box running Vyatta or pfSense, then you might be able to pull this off with minimum impact.

Any inexpensive and small form-factor recommendations for hardware for pfSense?

Re: Sshuttle - tunnel all your traffic through ssh

#53

Post by mariana » Tue, Apr 05, 2011, 1:38 AM UTC

tlrobinson wrote: post #35

NOT all your traffic. This only does TCP. Any DNS, UDP, and other non-TCP IP traffic won't go through the tunnel! I tried sshuttle awhile ago and abandoned it because of this. The only thing worse than no security is a false sense of security.

Would it be too hard to add non TCP traffic tunneling? This already supports DNS traffic through the tunnel but I wonder it is feasible to tunnel all kinds of traffic (UDP and ICMP mostly) through it?

Re: Sshuttle - tunnel all your traffic through ssh

#54

Post by psn » Tue, Apr 05, 2011, 2:49 AM UTC

https://github.com/apenwarr/sshuttle/commit/33efa5ac62eaf9cf... is the point where I get confused.

In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP packets into the tunnel. At the far end of the tunnel, packets are sent onwards based on the far end's routing table. Things like DNS "just work" because everything happens at a layer below TCP and UDP. In this system, he's making it work for each non-tcp using layer 4 protocol separately, leading to weirdness like rewriting /etc/hosts.

For tcp, he's nating all traffic locally to a local server, which then multiplexes all incoming traffic into the ssh connection. The remote side then unmultiplexes the data. I don't fully understand how this avoids tcp over tcp. Maybe I'm dumb. [edit: yeah, I'm dumb. the tcp connection is terminated at the local server, the contents are pumped over the ssh connection, and the remote side opens a new tcp connection]

I wrote this mostly because I read the readme and went "but how does it work?".

Re: Sshuttle - tunnel all your traffic through ssh

#55

Post by apenwarr » Tue, Apr 05, 2011, 2:58 AM UTC

psn wrote: post #54

https://github.com/apenwarr/sshuttle/commit/33efa5ac62eaf9cf... is the point where I get confused. In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP packets into the tunnel. At the far end of the tunnel, packets are sent onwards based on the far end's routing table. Things like DNS "just work" because everything happens at a layer below TCP and UDP. In this system, he's making it work for each n…

sshuttle does not (currently) attempt to do anything other than TCP and DNS. UDP ought to be possible (other than that UDP-over-TCP could have similar problems to TCP-over-TCP, ie. that packets are never lost and this could confuse a hypothetical UDP-based congestion control algorithm). ICMP is probably not possible unless we run the server side as root.

The "--auto-hosts" option you linked to is not the same as the "--dns" option. auto-hosts doesn't capture DNS at all; instead it just adds to your local /etc/hosts. I use this feature much more than --dns, actually, because unlike --dns, it works great if you have multiple tunnels to different offices open at once. (You get all the hostnames from all the offices.)

sshuttle was originally designed to VPN into an office and forward a couple of subnets over. In that case, you often don't want to use the remote DNS server, you just want to know the remote hostnames, because most of your DNS lookups have nothing to do with the remote server. Hence --auto-nets and --auto-hosts.

Nowadays it seems like sshuttle is mostly being used to counter things like Firesheep, which means you want to forward all your traffic to a remote server. In that case --dns - which forwards all your port 53 traffic over the VPN - is preferable.

We could actually do all the other UDP ports the same way we do --dns. We just don't, because I haven't needed it and nobody else has submitted a patch.

Re: Sshuttle - tunnel all your traffic through ssh

#56

Post by hollerith » Tue, Apr 05, 2011, 5:06 AM UTC

brianjesse wrote: post #37

hollerith wrote: post #21

Earlier quoted context omitted.

I remember SLIRP -- and The Internet Adapter.

I used SlipKnot for that -- it converted a shell-dialup at University of Oregon into a SLIP connection that I could use with Netscape 1.0

SLIP being a "competitor" to PPP.

Re: Sshuttle - tunnel all your traffic through ssh

#57

Post by sandGorgon » Tue, Apr 05, 2011, 5:49 AM UTC

Can I receive postbacks using this ?

Explanation - as usual, my company works on a shared LAN which goes through a single internet connection. To test some applications, we have to be able to receive postbacks (on our developer machines) through 3'rd party services. The best way we found was to have an OpenVPN server running somewhere. Each developer connects to the VPN server and receives a private IP-address. All postbacks go to the VPN server and are then routed through nginx to the correct developer machine (on the private IP address).

VPN is a pain to setup and configure - can something like this be used instead ? The question really is - how does nginx forward requests to the correct developer machine.

Re: Sshuttle - tunnel all your traffic through ssh

#58

Post by nupark2 » Tue, Apr 05, 2011, 5:49 AM UTC

bryanlarsen wrote: post #7

+1 for a reference to slirp, which let you turn a dial-in connection to a Unix terminal into a real internet connection back in the days when your University would give you a terminal connection but not a PPP connection.

I still use slirp to get free tethering on my iPhone.

Re: Sshuttle - tunnel all your traffic through ssh

#59

Post by tomjen3 » Tue, Apr 05, 2011, 6:07 AM UTC

ch0wn wrote: post #29

I set up an OpenVPN server for this purpose. This solution is so much easier and elegant, it's not even funny.

I tried to setup an openVPN server, but after chasing a rabbit hole of instructions down the craziest URLs with obsolete or missing information I finally gave up.

How did you get it to work?

Re: Sshuttle - tunnel all your traffic through ssh

#60

Post by wtallis » Tue, Apr 05, 2011, 6:35 AM UTC

apenwarr wrote: post #51

mike-cardwell wrote: post #31

Earlier quoted context omitted.

I've heared the claim that TCP over TCP doesn't work well countless times. I've been using OpenVPN in tcp mode for at least 5 years on a daily basis and never noticed a problem. I've even done SIP over a TCP OpenVPN configuration without a noticeable problem. It makes sense to me that it should perform badly, and it probably does for uses cases with a lot of traffic, but for an average user on a laptop, a TCP based V…

What happens is you essentially get "infinite bufferbloat." When there's no packet loss, you end up absolutely filling the transmit buffers at the entry points to the tunnels. The result, as other people have mentioned, is extremely poor interactive performance when you're simultaneously transferring large files. TCP-over-TCP not "broken" in the sense that the sessions will randomly drop or your kernel will crash or…

Wouldn't TCP Vegas over TCP work relatively well, since Vegas detects congestion using latency instead of dropped packets?