How does it work?
bronson
When I start sshuttle (for simplicity let's assume 0.0.0.0/0) it
configures iptables to send all tcp traffic its way. It does this by
listening on port 12300, then installing a redirect in PREROUTING and
OUTPUT to send the specified traffic to that port. Makes sense.
There are two things I'd still like to know...
1) How sshuttle discover the real destination port? It seems like the
original port would be lost when the connection arrives on 12300.
Does iptables preserve it and pass it somehow?
2) here's the redirect:
REDIRECT tcp -- anywhere anywhere TTL match
TTL != 42 redir ports 12300
What is TTL match TTL != 42 all about?
Thanks! I'm really enjoying playing with sshuttle. I've only been
messing with it for an hour but, so far it's been one of the most
satisfying VPNs I've tried (and I've tried them all...)
- Scott
Avery Pennarun
> 1) How sshuttle discover the real destination port? It seems like the
> original port would be lost when the connection arrives on 12300.
> Does iptables preserve it and pass it somehow?
git grep original_dst
> 2) here's the redirect:
>
> REDIRECT tcp -- anywhere anywhere TTL match
> TTL != 42 redir ports 12300
>
> What is TTL match TTL != 42 all about?
sshuttle generates its outgoing connections with a TTL of 42 so that
they don't get re-intercepted by the firewall, causing an endless
loop.
> Thanks! I'm really enjoying playing with sshuttle. I've only been
> messing with it for an hour but, so far it's been one of the most
> satisfying VPNs I've tried (and I've tried them all...)
Yes, sshuttle does make an extremely satisfying "plop" sound when it works.
Have fun,
Avery
roger
On Nov 1, 3:24 am, Avery Pennarun <apenw...@gmail.com> wrote:
> > 2) here's the redirect:
>
> > REDIRECT tcp -- anywhere anywhere TTL match
> > TTL != 42 redir ports 12300
>
> > What is TTL match TTL != 42 all about?
>
> sshuttle generates its outgoing connections with a TTL of 42 so that
> they don't get re-intercepted by the firewall, causing an endless
> loop.
only
'ssnet.connect_dst()' is setting TTL, while that function is only
called
on the server side.
On openwrt it lacks support for ipt_TTL module now.
Thanks,
Roger
Avery Pennarun
Well, it only needs to be used in one place for it to be useful :)
sshuttle doesn't have much code.
The actual case where this matters is when you're doing sshuttle to
localhost, the client is the same as the server. So then the server
tries to generate outgoing connections, and it gets caught by the
client's firewall entry, and Bad Things Happen (tm).
So if your system doesn't let you set TTL, or your firewall can't
catch TTL, then it doesn't matter *that much* unless you're doing
something weird, which occasionally I do, especially while testing new
versions of sshuttle.
> On openwrt it lacks support for ipt_TTL module now.
Does it support python? If not, then that doesn't really matter at
all. What are you trying to get done?
Have fun,
Avery
Avery Pennarun
> On Thu, Dec 2, 2010 at 9:18 AM, Avery Pennarun <apen...@gmail.com> wrote:
>> Does openwrt support python? If not, then that doesn't really matter at
>> all. What are you trying to get done?
>
> on my home router. It'll work once I do some hack on TTL code in
> shuttle :)
Hmm, your router must have a lot more RAM than mine :)
I guess we could have sshuttle fall back to adding non-TTL iptables
rules if it gets an error. Or add a --no-ttl-hack option.
> btw, I also want the dns query go through sshuttle. I tried to add UDP
> support to it, but found that I cannot get the original destination as
> TCP. So currently I'm doing is add a DNS server to it.
Hmm, I haven't played with iptables redirects with UDP, but I'd be
very surprised if there's no way to get the original destination. UDP
is pretty different from TCP though (ie. there's no second socket
since you never call accept()) so I'm sure something will be a little
different.
Probably you shouldn't just give up and implement an entire DNS server
right away :) Though I would be curious to find out how it works if
you do it.
One thing that sshuttle's --auto-hosts mode does really nicely is it
works if you have multiple tunnels open. Forwarding DNS wouldn't do
that; in fact, it would even eat your *local* network's hostnames. I
hate this about all VPNs, so I would like to see it solved somehow if
possible.
Have fun,
Avery