[9fans] NAT'ing a drawterm connection

[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

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
>

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]

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

[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

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

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

[Jim Choate]

On Mon, 25 Aug 2003, 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.

Yes, that is absolutely true. And we are well aware of it (sniffers are a
regular tool for us, snoopy needs work!) However, before we can stick a
tunnel around it we need to understand what and how things are working.

I'd say a bug needs to be entered against Drawterm for not using the inherent
crypto of Plan 9. How long has this app been around, how many people will
use it? Poor decision not to include this when it was first crafted.

It's definitely on our 'To Do' list. Our long term plan is to have an
encrypted tunnel between each node, with each 'hub' node having a unique
key pair between it and each member node.


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

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

[andrey mirtchovski]

On Mon, 25 Aug 2003, Jim Choate wrote:

> It's definitely on our 'To Do' list. Our long term plan is to have an
> encrypted tunnel between each node, with each 'hub' node having a unique
> key pair between it and each member node.
>

why not just update drawterm to 9p2000? :)

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] Re: NAT'ing a drawterm connection

[Jim Choate]

On Mon, 25 Aug 2003, andrey mirtchovski wrote:

> On Mon, 25 Aug 2003, Jim Choate wrote:
>
> > It's definitely on our 'To Do' list. Our long term plan is to have an
> > encrypted tunnel between each node, with each 'hub' node having a unique
> > key pair between it and each member node.
> >
>
> why not just update drawterm to 9p2000? :)

Why isn't it already there?

It'd be easier to ask Bell Labs to update their distro to include it out
of the box.

To ask individuals to update in a piecemeal way is not very professionsl.
Stop asking the end user to do the developer and distributors job.


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

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

[Jim Choate]

On Mon, 25 Aug 2003, Russ Cox wrote:

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

Thanks for clearing that up. :)


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

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] Re: NAT'ing a drawterm connection

[andrey mirtchovski]

On Mon, 25 Aug 2003, Jim Choate wrote:

> Why isn't it already there?
>
> It'd be easier to ask Bell Labs to update their distro to include it out
> of the box.
>
> To ask individuals to update in a piecemeal way is not very professionsl.
> Stop asking the end user to do the developer and distributors job.
>

as previously stated on this list, drawterm is unsupported by bell labs:

http://groups.google.com/groups?selm=3f8734f2e156e644c60414e47b867c85%40plan9.bell-labs.com&oe=utf-8&output=gplain

several people, including me, have made fixes to drawterm which didn't
appear on the distribution, so i gather nobody really cares about it there.
therefore you're on your own making drawterm behave as you want it to.

andrey

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

[Scott Schwartz]

| several people, including me, have made fixes to drawterm which didn't
| appear on the distribution, so i gather nobody really cares about it there.

If someone is willing to act as maintainer, so there is at least one
stable version, that should be ok even it it isn't in the official dist.

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

[andrey mirtchovski]

On Mon, 25 Aug 2003, Scott Schwartz wrote:

> | several people, including me, have made fixes to drawterm which didn't
> | appear on the distribution, so i gather nobody really cares about it there.
>
> If someone is willing to act as maintainer, so there is at least one
> stable version, that should be ok even it it isn't in the official dist.

i have the versions compiled with my modifications at:

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/

there aren't any significant modifications -- just compiled the latest
available source for linux/bsd with the proper TCP options...
the windows version is old, but empirically verified to work :)

these may be updated at any time, since there are a few things i want to do
with drawterm -- fix a memory leak that i'm rarely able to reproduce, and
experiment with compressing the connection, to see if it won't speed
graphics slightly...

updating to 9p2000 is on the table, but knowing myself that won't happen
anytime soon, so no need to mention it (oops :)

andrey

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

[matt]

>
>
>>a simple sniff can copy your key strokes ...
>>the auth is secure but the connection is cleartext.  type away.
>>

Jim wrote :

>Yes, that is absolutely true. And we are well aware of it (sniffers are a
>regular tool for us, snoopy needs work!)
>

Russ wrote :

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



This leaves me puzzled. Jim says it is cleartext and that H18 used
snoopy to verify their claims.

Does that mean that there is a faulty version of drawterm going around
or is someone talking out of their 10 gallon hat?

m

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

[Jim Choate]

Go pick a fight with somebody else.


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


On Mon, 25 Aug 2003, matt wrote:

> >
> >
> >>a simple sniff can copy your key strokes ...
> >>the auth is secure but the connection is cleartext.  type away.
> >>
>
> Jim wrote :
>
> >Yes, that is absolutely true. And we are well aware of it (sniffers are a
> >regular tool for us, snoopy needs work!)
> >
>
> Russ wrote :
>
>  > No, the connection is SSL encrypted using the key established by the
> auth.
>
>
>
> This leaves me puzzled. Jim says it is cleartext and that H18 used
> snoopy to verify their claims.
>
> Does that mean that there is a faulty version of drawterm going around
> or is someone talking out of their 10 gallon hat?
>
> m
>

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

[Jim Choate]

On Mon, 25 Aug 2003, Scott Schwartz wrote:

> | several people, including me, have made fixes to drawterm which didn't
> | appear on the distribution, so i gather nobody really cares about it there.
>
> If someone is willing to act as maintainer, so there is at least one
> stable version, that should be ok even it it isn't in the official dist.

The Open Forge or SSZ nodes of H18 will mirror it if that is helpfull.

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

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

[boyd, rounin]

> Type away.

like we're all typing for the NSA.

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

[matt]

Jim Choate wrote:

>Go pick a fight with somebody else.
>
>
>
I don't want a fight, I want to know the answer

I just did a wee test myself using tcpdump and I can see plain text in
my drawterm packets

but is is a confusing result

running strings over the captured packets isnt enough to yield what you
typed

but I did see this :

srv: /srv/juice already ex

which is an error message I get from trying to re-srv my u9fs on login
through my profile

so my uneducated conclusion is that it is obfuscated rather than plain

Russ, your stetson is in the post

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

[Bruce Ellis]

rather than 'strings' try an awk script that grabs the fid from the Ropen
that matched the Topen of "cons" and then dumps the payload of Rreads
of that fid.

> I just did a wee test myself using tcpdump and I can see plain text in
> my drawterm packets
>
> but is is a confusing result
>
> running strings over the captured packets isnt enough to yield what you
> typed

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] Re: NAT'ing a drawterm connection

[matt]

Bruce Ellis wrote:

>rather than 'strings' try an awk script that grabs the fid from the Ropen
>that matched the Topen of "cons" and then dumps the payload of Rreads
>of that fid.
>

Thanks for the tip. I think I've seen enough to know it's not encrypted.

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

[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] Re: NAT'ing a drawterm connection

[Skip Tavakkolian]

> | several people, including me, have made fixes to drawterm which didn't
> | appear on the distribution, so i gather nobody really cares about it there.
>
> If someone is willing to act as maintainer, so there is at least one
> stable version, that should be ok even it it isn't in the official dist.

Ideally, the person who maintains it should be the visionary behind the original
work.

I'd be glad to host the modified versions.