Trouble getting sshuttle working from a mac to a linux box
Jason Axelson
an Arch Linux server.
I have a remote tunnel to the Arch Linux server since it is behind a
NAT that is listening on port 2222 of my localhost (it's actually a
bit more complicated than that). So 'ssh localhost -p 2222' will log
me onto the server successfully without asking for my password because
I'm using public-keys and I'm using an ssh control master.
I'm running this command on the client:
./sshuttle -vv -r jason@localhost:2222 192.168.0.0/24
It seems to work okay (it says it connected to the server), but I
can't access other machines on the network (specifically
192.168.0.98). SSH says "connection established" but then it hangs
after talking about the identity files.
debug1: Connection established.
...
debug1: identity file /Users/jason/.ssh/id_rsa type 1
debug1: identity file /Users/jason/.ssh/id_dsa type -1
My appfirewall log on my client shows when I try to make this ssh
connection:
Jul 24 13:54:05 iMac Firewall[52]: 12300 Forward to 127.0.0.1:12300
TCP 10.0.1.2:51155 192.168.0.98:22 out via en1
So it seems to me like the local proxy server is set up and receives
connections okay, but is not successfully forwarding the connection
across the ssh tunnel.
Here is the short log (just -v) from sshuttle
[iMac:master sshuttle] % ./sshuttle -v -r jason@localhost:2222
192.168.0.0/24
Starting sshuttle proxy.
Listening on ('0.0.0.0', 12300).
Password:
firewall manager ready.
c : connecting to server...
s: available routes:
s: 192.168.0.0/24
c : connected.
firewall manager: starting transproxy.
>> ipfw -q add 12300 accept ip from any to any established
>> ipfw -q add 12300 fwd 127.0.0.1,12300 log tcp from any to 192.168.0.0/24 not ipttl 42
>> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
^Cfirewall manager: undoing changes.
>> ipfw -q del 12300
c :
c : Keyboard interrupt: exiting.
Also I am a little confused about the instructions. First you state:
> git clone git://github.com/apenwarr/sshuttle on your client and server machines.
And then later you state:
> You don't need to install sshuttle on the remote server; the remote server just needs to have python available. sshuttle will automatically upload and run its source code to the remote python interpreter.
Which seem to conflict with each other. Do we need sshuttle on the
server or don't we?
Thanks,
Jason
Avery Pennarun
> I'm having some trouble with using sshuttle with a Mac 10.5 client and
> an Arch Linux server.
Note that sshuttle has actually never been tested for sure by anyone
on MacOS, as far as I know. People have tested the firewall rules I
created, and they definitely fail on 10.6 and pass on 10.5. But I'm
not sure anyone has tested sshuttle itself. So there may be something
preventing it from working at all. Maybe we can track it down though.
Or maybe that's not it.
> ./sshuttle -vv -r jason@localhost:2222 192.168.0.0/24
Looks fine.
> debug1: Connection established.
> ...
> debug1: identity file /Users/jason/.ssh/id_rsa type 1
> debug1: identity file /Users/jason/.ssh/id_dsa type -1
That's a little odd. If you 'telnet remotehost 22' does it show the
ssh signature line? Can you connect to any other ports on any
computer beyond the tunnel?
> My appfirewall log on my client shows when I try to make this ssh
> connection:
>
> Jul 24 13:54:05 iMac Firewall[52]: 12300 Forward to 127.0.0.1:12300
> TCP 10.0.1.2:51155 192.168.0.98:22 out via en1
Sounds good, I think... though again, I don't know for sure with MacOS.
> Here is the short log (just -v) from sshuttle
>
> [iMac:master sshuttle] % ./sshuttle -v -r jason@localhost:2222
> 192.168.0.0/24
> Starting sshuttle proxy.
> Listening on ('0.0.0.0', 12300).
> Password:
> firewall manager ready.
> c : connecting to server...
> s: available routes:
> s: 192.168.0.0/24
> c : connected.
The s: lines come from the sshuttle server, so it's definitely communicating.
> firewall manager: starting transproxy.
>>> ipfw -q add 12300 accept ip from any to any established
>>> ipfw -q add 12300 fwd 127.0.0.1,12300 log tcp from any to 192.168.0.0/24 not ipttl 42
>>> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
> ^Cfirewall manager: undoing changes.
>>> ipfw -q del 12300
> c :
> c : Keyboard interrupt: exiting.
You should really see at least one line that says something like this:
c : Accept: '192.168.2.7':37114 -> '10.65.1.127':22.
If you don't, then sshuttle is apparently not receiving any incoming
connections from the firewall at all. Which is kind of bad news. Or
did you just capture the log from a session where you didn't try to
open any connections?
> Also I am a little confused about the instructions. First you state:
>
>> git clone git://github.com/apenwarr/sshuttle on your client and server machines.
>
> And then later you state:
>
>> You don't need to install sshuttle on the remote server; the remote server just needs to have python available. sshuttle will automatically upload and run its source code to the remote python interpreter.
>
> Which seem to conflict with each other. Do we need sshuttle on the
> server or don't we?
That's old information; you no longer need to install sshuttle on the
server by hand. I've fixed the README and pushed up a new version.
Thanks for pointing it out.
Have fun,
Avery
Jason Axelson
On Sat, Jul 24, 2010 at 6:31 PM, Avery Pennarun <apen...@gmail.com> wrote:
> Note that sshuttle has actually never been tested for sure by anyone
> on MacOS, as far as I know. People have tested the firewall rules I
> created, and they definitely fail on 10.6 and pass on 10.5. But I'm
> not sure anyone has tested sshuttle itself. So there may be something
> preventing it from working at all. Maybe we can track it down though.
> Or maybe that's not it.
Ah, I didn't realize that no-one's actually used sshuttle on 10.5 yet.
Guess I'll try to be the first :P I think that sshuttle will
currently not work by default on 10.5. I just tested it on my local
linux box (with the same remote linux box) and it works wonderfully.
>> ./sshuttle -vv -r jason@localhost:2222 192.168.0.0/24
>
> Looks fine.
>
>> debug1: Connection established.
>> ...
>> debug1: identity file /Users/jason/.ssh/id_rsa type 1
>> debug1: identity file /Users/jason/.ssh/id_dsa type -1
>
> That's a little odd. If you 'telnet remotehost 22' does it show the
> ssh signature line? Can you connect to any other ports on any
> computer beyond the tunnel?
Telnet just hangs as well and I can't connect to any other ports. I
think this is a Mac firewall issue.
>> My appfirewall log on my client shows when I try to make this ssh
>> connection:
>>
>> Jul 24 13:54:05 iMac Firewall[52]: 12300 Forward to 127.0.0.1:12300
>> TCP 10.0.1.2:51155 192.168.0.98:22 out via en1
>
> Sounds good, I think... though again, I don't know for sure with MacOS.
I forgot the first line of the log showing that python is listening:
Jul 24 19:13:02 iMac Firewall[52]: Python is listening from
0.0.0.0:12300 uid = 501 proto=6
Jul 24 19:13:41 iMac Firewall[52]: 12300 Forward to 127.0.0.1:12300
TCP 10.0.1.2:54168 192.168.0.93:22 out via en1
I guess we're undecided if that second line is the correct behavior.
What would a similar line on Linux look like?
I did capture a log where I tried some connections. But sshuttle never
produced any output after the initial setup so I suspect that your
hunch is correct.
Here's the full output where I tried some connections:
[iMac:master sshuttle] % ./sshuttle -vv -r jason@localhost:2223
192.168.0.0/24 2>&1 | tee output
(jason@iMac:~/sshuttle/)
Starting sshuttle proxy.
Binding: 12300
Listening on ('0.0.0.0', 12300).
firewall manager ready.
c : connecting to server...
c : executing: ['ssh', '-p', '2223', '-M', 'jason@localhost', '--',
'python -c \'import sys; skip_imports=1; verbosity=2; exec
compile(sys.stdin.read(764), "assembler.py", "exec")\'']
ControlSocket /tmp/ssh-jason@localhost:2223 already exists, disabling
multiplexing
c : > channel=0 cmd=PING len=7 (fullness=0)
server: assembling 'helpers.py' (280 bytes)
server: assembling 'ssnet.py' (3869 bytes)
server: assembling 'hostwatch.py' (2187 bytes)
server: assembling 'server.py' (1747 bytes)
s: available routes:
s: 192.168.0.0/24
s: > channel=0 cmd=PING len=7 (fullness=0)
c : connected.
c : Waiting: 2[2,1,0]...
c : mux wrote: 15/15
c : Waiting: 2[2,0,0]...
s: > channel=0 cmd=ROUTES len=15 (fullness=7)
s: Waiting: 1[1,1,0] (fullness=22/0)...
s: mux wrote: 15/15
s: mux wrote: 23/23
s: Waiting: 1[1,0,0] (fullness=22/0)...
c : < channel=0 cmd=PING len=7
c : > channel=0 cmd=PONG len=7 (fullness=7)
c : < channel=0 cmd=ROUTES len=15
firewall manager: starting transproxy.
>> ipfw -q add 12300 accept ip from any to any established
>> ipfw -q add 12300 fwd 127.0.0.1,12300 log tcp from any to 192.168.0.0/24 not ipttl 42
s: < channel=0 cmd=PING len=7
s: > channel=0 cmd=PONG len=7 (fullness=22)
s: mux wrote: 15/15
s: Waiting: 1[1,0,0] (fullness=29/0)...
>> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
c : mux wrote: 15/15
c : < channel=0 cmd=PONG len=7
c : received PING response
c : Waiting: 2[2,0,0]...
s: < channel=0 cmd=PONG len=7
s: received PING response
s: Waiting: 1[1,0,0] (fullness=0/0)...
>> Also I am a little confused about the instructions. First you state:
>>> ... snip ...
> That's old information; you no longer need to install sshuttle on the
> server by hand. I've fixed the README and pushed up a new version.
> Thanks for pointing it out.
Glad it helped.
One thing that I think would be helpful (but not so much for me right
now) would be the ability to pass arbitrary flags to ssh. Is that on
the roadmap at all?
Thanks,
Jason
Avery Pennarun
> On Sat, Jul 24, 2010 at 6:31 PM, Avery Pennarun <apen...@gmail.com> wrote:
>> Note that sshuttle has actually never been tested for sure by anyone
>> on MacOS, as far as I know. People have tested the firewall rules I
>> created, and they definitely fail on 10.6 and pass on 10.5. But I'm
>> not sure anyone has tested sshuttle itself. So there may be something
>> preventing it from working at all. Maybe we can track it down though.
>> Or maybe that's not it.
>
> Ah, I didn't realize that no-one's actually used sshuttle on 10.5 yet.
> Guess I'll try to be the first :P I think that sshuttle will
> currently not work by default on 10.5. I just tested it on my local
> linux box (with the same remote linux box) and it works wonderfully.
Well, I don't know if people have tried it or not; unfortunately
people rarely send email when something *does* work.
>> That's a little odd. If you 'telnet remotehost 22' does it show the
>> ssh signature line? Can you connect to any other ports on any
>> computer beyond the tunnel?
>
> Telnet just hangs as well and I can't connect to any other ports. I
> think this is a Mac firewall issue.
Okay. Can you go to this page:
And let me know what happens if you try the steps there?
> I forgot the first line of the log showing that python is listening:
>
> Jul 24 19:13:02 iMac Firewall[52]: Python is listening from
> 0.0.0.0:12300 uid = 501 proto=6
> Jul 24 19:13:41 iMac Firewall[52]: 12300 Forward to 127.0.0.1:12300
> TCP 10.0.1.2:54168 192.168.0.93:22 out via en1
>
> I guess we're undecided if that second line is the correct behavior.
> What would a similar line on Linux look like?
It's just totally different. It's not even the same log file.
> One thing that I think would be helpful (but not so much for me right
> now) would be the ability to pass arbitrary flags to ssh. Is that on
> the roadmap at all?
I haven't really planned it; you can't really do it with scp or rsync
either, AFAIK. What options were you thinking of? Did you consider
making a ~/.ssh/config file?
Have fun,
Avery
Jason Axelson
>>> That's a little odd. If you 'telnet remotehost 22' does it show the
>>> ssh signature line? Can you connect to any other ports on any
>>> computer beyond the tunnel?
>>
>> Telnet just hangs as well and I can't connect to any other ports. I
>> think this is a Mac firewall issue.
>
> Okay. Can you go to this page:
>
> http://serverfault.com/questions/138622/transparent-proxying-leaves-sockets-with-syn-rcvd-in-macos-x-10-6-snow-leopard-a
>
> And let me know what happens if you try the steps there?
I'm able to successfully communicate to the netcat server in both
cases. And I don't see any SYN_RCVD connections.
I did some experimenting of my own and it looks like "ipfw add 1000
fwd 10.0.1.9,22 log tcp from any to any" will forward ssh connections
to 127.0.0.1 rather than my 10.0.1.9 server. Is that expected?
Here's the output of uname -a
Darwin iMac.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>> One thing that I think would be helpful (but not so much for me right
>> now) would be the ability to pass arbitrary flags to ssh. Is that on
>> the roadmap at all?
>
> I haven't really planned it; you can't really do it with scp or rsync
> either, AFAIK. What options were you thinking of? Did you consider
> making a ~/.ssh/config file?
They actually both have ways of passing args to ssh.
scp has [-o ssh_option]
and rsync has:
export RSYNC_CONNECT_PROG='ssh proxyhost nc %H 873'
I think scp's way is pretty easy to implement just accept -o input and
pass it directly to ssh (via -o)
Thanks,
Jason
Avery Pennarun
> On Sat, Jul 24, 2010 at 7:34 PM, Avery Pennarun <apen...@gmail.com> wrote:
>> http://serverfault.com/questions/138622/transparent-proxying-leaves-sockets-with-syn-rcvd-in-macos-x-10-6-snow-leopard-a
>>
>> And let me know what happens if you try the steps there?
>
> I'm able to successfully communicate to the netcat server in both
> cases. And I don't see any SYN_RCVD connections.
Hmm. Good, though that doesn't really explain why sshuttle isn't
working then :(
> I did some experimenting of my own and it looks like "ipfw add 1000
> fwd 10.0.1.9,22 log tcp from any to any" will forward ssh connections
> to 127.0.0.1 rather than my 10.0.1.9 server. Is that expected?
I don't know what you're asking here; neither the stackoverflow.com
page nor sshuttle uses that command.
The purpose of the ipfw command is to reroute from wherever the
connection was originally directed (10.0.1.9?) to the sshuttle proxy
server on localhost (ie. 127.0.0.1) port 12300. Then sshuttle grabs
it and sends it elsewhere.
After sshuttle starts, can you try the following (then retry your
tunneled connection) to see if it helps?
[1]
ipfw -q del 12300
ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
And if that doesn't work, try this:
[2]
ipfw -q del 12300
ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any
If either of those *does* work, then try this:
[3]
ipfw -q del 12300
ipfw -q add 12300 accept ip from any to any established
ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
> They actually both have ways of passing args to ssh.
>
> scp has [-o ssh_option]
>
> and rsync has:
> export RSYNC_CONNECT_PROG='ssh proxyhost nc %H 873'
>
> I think scp's way is pretty easy to implement just accept -o input and
> pass it directly to ssh (via -o)
I guess I prefer the latter one, since it's more general (you could
use something other than ssh). If you want to submit a patch to add
this feature, please feel free.
Have fun,
Avery
Jason Axelson
> After sshuttle starts, can you try the following (then retry your
> tunneled connection) to see if it helps?
>
> [1]
> ipfw -q del 12300
> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
>
> And if that doesn't work, try this:
>
> [2]
> ipfw -q del 12300
> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any
>
> If either of those *does* work, then try this:
>
> [3]
> ipfw -q del 12300
> ipfw -q add 12300 accept ip from any to any established
> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
This causes an error in sshuttle.
c : Waiting: 3[3,0,0]...
Read from remote host 10.0.1.9: Connection reset by peer
firewall manager: undoing changes.
fatal: non-sshuttle ipfw rule #12300 already exists!
c : fatal: cleanup: ['sudo', './sshuttle', '-v', '-v', '--firewall',
'12300'] returned 99
c : SW:10.0.1.2:60115: deleting
zsh: exit 99 ./sshuttle -vv -r server 192.168.0.0/24 2>&1 |
zsh: done tee output
This happens as soon as I add the new rule (it doesn't matter which one)
Here is the full output log
$ ./sshuttle -vv -r server 192.168.0.0/24 2>&1 | tee output
Starting sshuttle proxy.
Binding: 12300
Listening on ('0.0.0.0', 12300).
firewall manager ready.
c : connecting to server...
c : executing: ['ssh', '-M', 'server', '--', 'python -c \'import sys;
skip_imports=1; verbosity=2; exec compile(sys.stdin.read(764),
"assembler.py", "exec")\'']
c : > channel=0 cmd=PING len=7 (fullness=0)
server: assembling 'helpers.py' (280 bytes)
server: assembling 'ssnet.py' (3869 bytes)
server: assembling 'hostwatch.py' (2187 bytes)
server: assembling 'server.py' (1747 bytes)
s: available routes:
s: 10.0.1.0/24
s: > channel=0 cmd=PING len=7 (fullness=0)
s: > channel=0 cmd=ROUTES len=12 (fullness=7)
s: Waiting: 1[1,1,0] (fullness=19/0)...
c : connected.
c : Waiting: 2[2,1,0]...
c : mux wrote: 15/15
c : Waiting: 2[2,0,0]...
s: mux wrote: 15/15
s: mux wrote: 20/20
s: Waiting: 1[1,0,0] (fullness=19/0)...
c : < channel=0 cmd=PING len=7
c : > channel=0 cmd=PONG len=7 (fullness=7)
c : < channel=0 cmd=ROUTES len=12
firewall manager: starting transproxy.
s: < channel=0 cmd=PING len=7
s: > channel=0 cmd=PONG len=7 (fullness=19)
>> ipfw -q add 12300 accept ip from any to any established
s: mux wrote: 15/15
s: Waiting: 1[1,0,0] (fullness=26/0)...
>> ipfw -q add 12300 fwd 127.0.0.1,12300 log tcp from any to 192.168.0.0/24 not ipttl 42
>> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
c : mux wrote: 15/15
c : < channel=0 cmd=PONG len=7
c : received PING response
c : Waiting: 2[2,0,0]...
s: < channel=0 cmd=PONG len=7
s: received PING response
s: Waiting: 1[1,0,0] (fullness=0/0)...
c : Accept: '10.0.1.2':60115 -> '66.102.7.83':443.
c : > channel=1 cmd=CONNECT len=15 (fullness=0)
c : new channel: 1
c : mux wrote: 23/23
c : Waiting: 3[3,0,0]...
c : > channel=1 cmd=DATA len=128 (fullness=15)
c : mux wrote: 136/136
c : Waiting: 3[3,0,0]...
Read from remote host 10.0.1.9: Connection reset by peer
firewall manager: undoing changes.
fatal: non-sshuttle ipfw rule #12300 already exists!
c : fatal: cleanup: ['sudo', './sshuttle', '-v', '-v', '--firewall',
'12300'] returned 99
c : SW:10.0.1.2:60115: deleting
zsh: exit 99 ./sshuttle -vv -r server 192.168.0.0/24 2>&1 |
zsh: done tee output
Avery Pennarun
Sorry for the slow reply - I've been travelling around on vacation. See below.
On Wed, Aug 25, 2010 at 9:11 PM, Jason Axelson <boston...@gmail.com> wrote:
> On Sat, Jul 24, 2010 at 9:19 PM, Avery Pennarun <apen...@gmail.com> wrote:
>> After sshuttle starts, can you try the following (then retry your
>> tunneled connection) to see if it helps?
>>
>> [1]
>> ipfw -q del 12300
>> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
>>
>> And if that doesn't work, try this:
>>
>> [2]
>> ipfw -q del 12300
>> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any
>>
>> If either of those *does* work, then try this:
>>
>> [3]
>> ipfw -q del 12300
>> ipfw -q add 12300 accept ip from any to any established
>> ipfw add 12300 fwd 127.0.0.1,12300 log tcp from any to any not ipttl 42
>> ipfw -q add 12300 skipto 12301 log tcp from any to 127.0.0.0/8
>
> This causes an error in sshuttle.
>
> c : Waiting: 3[3,0,0]...
> Read from remote host 10.0.1.9: Connection reset by peer
Oops, I guess the above commands are disconnecting the sshuttle client
from the server, because the client-server connection ends up
forwarded through sshuttle. Not that useful.
Can you try the above three tests again, but instead of "from any to
any", use "from any to 6.7.8.9", where 6.7.8.9 is the IP address of a
machine you're going to try connecting to via sshuttle? (ie. it's a
machine on the server's end of the connection, but *not* the same
machine as the server).
Thanks,
Avery
Jason Axelson
Well I just upgraded to snow leopard so pretty much all of these rules
are failing and I see the same results as you in the serverfault post
(I see both at syn_rcvd and a syn_sent in netstat).
Here's the new output of uname -a for me:
Darwin iMac.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23
18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i386
Thanks,
Jason
Avery Pennarun
> Well I just upgraded to snow leopard so pretty much all of these rules
Oh well, game over then :(
If anyone has any advice on how to convince Apple to fix a bug in Snow
Leopard - or better still, a workaround that will make it magically
start working - I'd love to hear it!
Have fun,
Avery
Christopher
> > Well I just upgraded to snow leopard so pretty much all of these rules
> > are failing [...]
>
> Oh well, game over then :(
>
> If anyone has any advice on how to convince Apple to fix a bug in Snow
> Leopard - or better still, a workaround that will make it magically
> start working - I'd love to hear it!
http://serverfault.com/questions/138622/transparent-proxying-leaves-sockets-with-syn-rcvd-in-macos-x-10-6-snow-leopard-a
and appear to be seeing the same result, an unmatched syn_rcvd and
syn_sent. I don’t know if you’ve ever filed a bug report to Apple
before, but https://bugreport.apple.com/ is the place to start.
Alternatively, drop me an email at work (my username at apple.com) and
we’ll chat.
—Christopher
Avery Pennarun
> I’ve stepped through the commands on
> http://serverfault.com/questions/138622/transparent-proxying-leaves-sockets-with-syn-rcvd-in-macos-x-10-6-snow-leopard-a
> and appear to be seeing the same result, an unmatched syn_rcvd and
> syn_sent. I don’t know if you’ve ever filed a bug report to Apple
> before, but https://bugreport.apple.com/ is the place to start.
> Alternatively, drop me an email at work (my username at apple.com) and
> we’ll chat.
I did file a bug using that web site at the time; or maybe it was a
different apple.com site, which in turn told me thanks for my bug
report, but this bug filing system is actually not useful, please go
file at another one. So I filed it again, and that time I got a nice
automated message saying I had filed the bug successfully. But no
response after that.
I can understand if Apple doesn't see this as a really high priority,
of course, since virtually nobody tries to do transproxying in MacOS.
Except me and other sshuttle users, that is :)
If you can help somehow, that would be great!
Have fun,
Avery
dkf
deviation from the behavior at the serverfault question.
If I run:
[window 1]
$ while true; do nc -l 12300; done
[window 2]
# sysctl -w net.inet.ip.forwarding=1
# sysctl -w net.inet.ip.fw.enable=1
# sysctl -w net.inet.ip.scopedroute=0 # this is new
# ipfw add 1000 fwd 127.0.0.1,12300 log tcp from any to any
# telnet google.com 80
Trying 74.125.19.147...
Connected to google.com.
Escape character is '^]'.
google test
^]
telnet> close
Connection closed.
then I get:
[window 1]
$ while true; do nc -l 12300; done
google test
When I run with sshuttle with this setting, proxying 10.0.0.0/8,
connecting to 10.99.110.131:8080, I get:
tcp4 0 0 10.99.110.131.8080 192.168.1.108.49427
SYN_RCVD
tcp4 0 18 192.168.1.108.49427 10.99.110.131.8080
ESTABLISHED
It doesn't work, but it seems different enough that it's worth
throwing out on this list and seeing if it makes sense to someone.
On Sep 14, 1:31 am, Avery Pennarun <apenw...@gmail.com> wrote:
> On Tue, Sep 14, 2010 at 12:44 AM, Christopher <cbo...@gmail.com> wrote:
> > I’ve stepped through the commands on
> > syn_sent. I don’t know if you’ve ever filed a bug report to Apple
Avery Pennarun
> I'm on snow leopard (10.6.4) and I think I might have an interesting
> deviation from the behavior at the serverfault question.
> # sysctl -w net.inet.ip.scopedroute=0 # this is new
That is indeed extremely interesting. What motivated you to try this option?
Thanks,
Avery
dkf
http://discussions.apple.com/thread.jspa?messageID=11558355�
There are a few threads on discussions.apple.com about transparent
proxying with 10.6.
On Sep 29, 9:26 pm, Avery Pennarun <apenw...@gmail.com> wrote: