Re: [9fans] NAT'ing a drawterm connection

Re: [9fans] NAT'ing a drawterm connection

[Skip Tavakkolian]

>> Type away.
>
> like we're all typing for the NSA.

I see your point, but, customers of a service wouldn't be sympathetic
to that answer.  My hope is that Russ just gave us a hint that he has
already done it.

Re: [9fans] NAT'ing a drawterm connection

[boyd, rounin]

> I see your point, but, customers of a service wouldn't be sympathetic
> to that answer.

oh i agree, but, for the moment, i have nothing much to protect.

Re: [9fans] NAT'ing a drawterm connection

[Jim Choate]

On Mon, 25 Aug 2003, Skip Tavakkolian wrote:

> >> Type away.
> >
> > like we're all typing for the NSA.
>
> I see your point, but, customers of a service wouldn't be sympathetic
> to that answer.  My hope is that Russ just gave us a hint that he has
> already done it.
>

No self respecting Cypherpunks would stand for it either.

 -- --
      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] NAT'ing a drawterm connection

[Jim Choate]

On Tue, 26 Aug 2003, boyd, rounin wrote:

> > I see your point, but, customers of a service wouldn't be sympathetic
> > to that answer.
>
> oh i agree, but, for the moment, i have nothing much to protect.
>

Then you miss the point of full-time encryption. This forces mallet to
decrypt all data. If you only use encryption to protest 'important' stuff
then you shouldn't bother encrypting it. People should be using encryption
as a matter of course. One of the primary goals of H18 is to build in
encryption to all levels of P9.

One of the first things I'd like is to see DES replaced as the default
protocol. Dedicated FPGA cracker is <$50k US.

The more fundamental problem is that it's the same sort of
misunderstanding it entails regarding inter-personal relations. It's the
same as saying "Unless you have something to hide you shouldn't mind a
search". Individuals aren't property (at least not in American democracy).
This sort of view is more fascist (in the sense of private property and
public management).

As O.H. Wilson (I think he's the right bioligist) who was asked his
opinion of socialism. He said something akin to "Nice theory, wrong
species."


 -- --
      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] NAT'ing a drawterm connection

[andrey mirtchovski]

On 28 Aug 2003, Rob Ristroph wrote:

> Suppose in your "import" command that "plan9" isn't a machine running
> Plan 9 but another computer that can see the plan9 computer.  Can you
> forward some set of ports to make it work, or are you just out of luck
> ?

import expects exportfs to be running on the other side. it should be fine
by just redirecting the exportfs port. if that's what you want to achieve.

> client version: RFB 003.003
> [550] 192.168.1.1!4719 /net/tcp/28: auth
> vncs: vncchal: auth server protocol botch

in my case that usually means i've gotten the authdoms in /lib/ndb/local on
the auth server wrong. can you cpu from the same machine to itself? try that
with 'auth/debug' and see what's wrong.

> Nothing seems to be printed in /sys/log/auth.  If I run a vnc server
> on linux, I have to set a password; have I not done the equivalent on
> Plan 9 ?  How do I do it ?

you do not, vncs is smart enough to use the password already set for the
user on the auth server. do you have a password set?

another thing, suggested some time ago by Geoff Collyer -- cd /adm/keys on
the console of the auth server and type 'ls' -- if you see valid user names
for the system you're ok, of not, the nvram on the system doesn't contain
the proper password to decode the password..

but: my auth server was set a few months ago, so i may be out of sync...

andrey

Re: [9fans] NAT'ing a drawterm connection

[YAMANASHI Takeshi]

"On Fri Aug 29 13:30:03 JST 2003, rgr@sdf.lonestar.org wrote:"
> Nothing seems to be printed in /sys/log/auth.  If I run a vnc server
> on linux, I have to set a password; have I not done the equivalent on
> Plan 9 ?  How do I do it ?

Have you set Inferno/POP password on plan 9?  Vnc server on plan9
uses Inferno/POP password to authenticate vnc connections.

`passwd(1)' should set the password for you.

	% nashi@p9t passwd
	Plan 9 Password: xxxxxxx
	change Plan 9 Password? (y/n) n
	change Inferno/POP password? (y/n) y
--

Re: [9fans] NAT'ing a drawterm connection

[Rob Ristroph]

>>>>> "andrey" == andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> writes:
andrey>
andrey> On Sun, 24 Aug 2003, andrey mirtchovski wrote:
>> ps: i've had the setup pasted in the original mail work for a year already
>> with any significant issues. there's also a NAT rule for the other way
>> around, but more often I leave people logged in to mount the auth server's
>> /net, which is outside the 192 network.
>>
andrey>
andrey> err, i meant 'without'. it just works.
andrey>
andrey> import plan9 /net /net works better :)

Using your lines it works a bit better; you can get as far as the grey
rio screen but bringing up the pull down menu to make a new rc window
crashes something.  It was someone else on the other end, so I don't
know the exact error message.

Suppose in your "import" command that "plan9" isn't a machine running
Plan 9 but another computer that can see the plan9 computer.  Can you
forward some set of ports to make it work, or are you just out of luck
?

In the meantime, I decided to try to achieve the same ends at drawterm
using vnc.  Disregarding port forwarding, when the Plan 9 and Linux
machines are directly on the same subnet with no router between them,
I can vnc from Plan 9 to Linux but on Linux I cannot connect a
vncviewer to the Plan 9 server.

On Plan 9 I start the server with the command "vncs -v".

On Linux, xvncviewer prints this and exits (never asked for a
password, as it did when I connected from Plan 9 to Linux):

VNC server supports protocol version 3.3 (viewer 3.3)
xvncviewer: VNC server closed connection

On Plan 9, I see this:

192.168.1.18# vncs -v
192.168.1.18# geometry is 1024x768
server started on display :3
announced in /net/tcp/27
call in /net/tcp/28
[550] 192.168.1.1!4719 /net/tcp/28: handshake
server version: RFB 003.003
client version: RFB 003.003
[550] 192.168.1.1!4719 /net/tcp/28: auth
vncs: vncchal: auth server protocol botch

Nothing seems to be printed in /sys/log/auth.  If I run a vnc server
on linux, I have to set a password; have I not done the equivalent on
Plan 9 ?  How do I do it ?

Thanks in advance,

--Rob

Re: [9fans] NAT'ing a drawterm connection

[Russ Cox]

Bruce Ellis wrote:

>NO.  There is no devssl in drawterm.  Not hard but not done.
>And and a firewall doesn't stop the sniff.  Type away.
>
>
>>No, the connection is SSL encrypted using the key established by the auth.
>>
>>Russ
>>

Umm, oops.  I could have sworn this happened when I updated drawterm
for the new draw model, years ago.  I'm really amazed.  If someone wants to
make the change, importing devssl should be trivial.

As for the drawterm changes, if someone wants to be the official maintainer
of drawterm, that'd be great.  Send me mail and we can arrange write
permission
on sources.

If others want to do the 9P2000 changes, it's really quite straightforward.
I haven't bothered because I have grander changes in mind, so the protocol
change by itself doesn't seem worth it to me.

Russ

Re: [9fans] NAT'ing a drawterm connection

[boyd, rounin]

> Type away.

like we're all typing for the NSA.

Re: [9fans] NAT'ing a drawterm connection

[Bruce Ellis]

NO.  There is no devssl in drawterm.  Not hard but not done.
And and a firewall doesn't stop the sniff.  Type away.

> No, the connection is SSL encrypted using the key established by the auth.
>
> Russ

Re: [9fans] NAT'ing a drawterm connection

[matt]

I use a Linksys hardware firewall

To get drawterm-freebsd through to my NAT'd plan9 machine I had to open

tcp:17013 to connect
and
tcp:567 to authenticate

m

Re: [9fans] NAT'ing a drawterm connection

[Russ Cox]

Bruce Ellis wrote:

>maybe you guys drawterming over open networks should consider
>the security of running a cleartext 9p connection over such a connection.
>that's what you are doing.  a simple sniff can copy your key strokes ...
>the auth is secure but the connection is cleartext.  type away.
>
>

No, the connection is SSL encrypted using the key established by the auth.

Russ

Re: [9fans] NAT'ing a drawterm connection

[Bruce Ellis]

maybe you guys drawterming over open networks should consider
the security of running a cleartext 9p connection over such a connection.
that's what you are doing.  a simple sniff can copy your key strokes ...
the auth is secure but the connection is cleartext.  type away.

Re: [9fans] NAT'ing a drawterm connection

[andrey mirtchovski]

On Sun, 24 Aug 2003, andrey mirtchovski wrote:

> ps: i've had the setup pasted in the original mail work for a year already
> with any significant issues. there's also a NAT rule for the other way
> around, but more often I leave people logged in to mount the auth server's
> /net, which is outside the 192 network.
>

err, i meant 'without'. it just works.

import plan9 /net /net works better :)

Re: [9fans] NAT'ing a drawterm connection

[andrey mirtchovski]

On 25 Aug 2003, Rob Ristroph wrote:

> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:567
> /sbin/iptables -A FORWARD -m state --state RELATED -j ACCEPT

that's overcomplicating it, but so is the way of linux... :)

> Are those 17xxx connections extablished from drawterm to the cpu/auth
> server, or from the Plan 9 computer to drawterm ?

from drawterm.

andrey

ps: i've had the setup pasted in the original mail work for a year already
with any significant issues. there's also a NAT rule for the other way
around, but more often I leave people logged in to mount the auth server's
/net, which is outside the 192 network.

i only need to add new ports if they're required (when, for example, you
decide that drawterm is too slow and you want to run over a vnc connection).

Re: [9fans] NAT'ing a drawterm connection

[Rob Ristroph]

>>>>> "andrey" == andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> writes:
andrey>
andrey> your bug is that you need to change the --dport appropriately for each
andrey> different port:
andrey>
andrey>  1018  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 564 -j DNAT --to-destination 192.168.1.3
andrey>  1019  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17008 -j DNAT --to-destination 192.168.1.3
andrey>  1020  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17010 -j DNAT --to-destination 192.168.1.3
andrey>  1021  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17013 -j DNAT --to-destination 192.168.1.3
andrey>
andrey> i believe only 564 i 17008 are important, but i can't connect right now to
andrey> give you netstat...
andrey>
andrey> andrey
andrey>
andrey> On 24 Aug 2003, Rob Ristroph wrote:
andrey>
>> # Port forwarding to try to make drawterm to Plan 9 machine work
>> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:567
>> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17007
>> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17008
>>

That's definitely a bug.

However, I suspect the 17xxx lines should not be there at all.
Instead:

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:567
/sbin/iptables -A FORWARD -m state --state RELATED -j ACCEPT

But this may require a special connection tracking module in the linux
netfilters package that would know that the 17xxx connection was
"related" to the forwarded 567 connection and route it accordingly.

I have no idea if those are the right options on the second line
there, I just cut-and-pasted it from a post about getting one of the
online games to work through a NAT.

Are those 17xxx connections extablished from drawterm to the cpu/auth
server, or from the Plan 9 computer to drawterm ?

Perhaps I can find out by running snoopy . . .

--Rob

Re: [9fans] NAT'ing a drawterm connection

[andrey mirtchovski]

your bug is that you need to change the --dport appropriately for each
different port:

 1018  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 564 -j DNAT --to-destination 192.168.1.3
 1019  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17008 -j DNAT --to-destination 192.168.1.3
 1020  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17010 -j DNAT --to-destination 192.168.1.3
 1021  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 17013 -j DNAT --to-destination 192.168.1.3

i believe only 564 i 17008 are important, but i can't connect right now to
give you netstat...

andrey

On 24 Aug 2003, Rob Ristroph wrote:

> # Port forwarding to try to make drawterm to Plan 9 machine work
> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:567
> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17007
> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17008
>

[9fans] NAT'ing a drawterm connection

[Rob Ristroph]

I have a cpu/auth server on a private network, which is connected to
the internet via a Linux computer running iptables and masquerading or
NAT'ing as they call it now.

 From that linux box I can drawterm into my Plan 9 cpu/auth server.

I would like to forward the appropriate ports so that someone on the
internet at large can drawterm to my plan 9 machine.

Here was my first attempt:

# Port forwarding to try to make drawterm to Plan 9 machine work
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:567
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17007
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 567 -i eth0 -j DNAT --to 192.168.1.18:17008

However it doesn't work.

Has anyone set this up before ?

If the connections on 170xx are initiated from the Plan 9 side, I
don't need those last two lines, right ?  For simplicity let's presume
the client drawterm has a real IP address.

--Rob