[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
andrey mirtchovski
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
Rob Ristroph
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>
>> /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
andrey mirtchovski
> /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).
andrey mirtchovski
> 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 :)
Bruce Ellis
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.
Jim Choate
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.
-- --
rav...@ssz.com jch...@open-forge.com
www.ssz.com www.open-forge.com
andrey mirtchovski
> 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? :)
Russ Cox
>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
Jim Choate
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.
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. :)
matt
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
andrey mirtchovski
> 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:
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
Scott Schwartz
| 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.
andrey mirtchovski
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
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
Jim Choate
Go pick a fight with somebody else.
Jim Choate
The Open Forge or SSZ nodes of H18 will mirror it if that is helpfull.
Bruce Ellis
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
boyd, rounin
like we're all typing for the NSA.
Skip Tavakkolian
>
> 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.
boyd, rounin
> to that answer.
oh i agree, but, for the moment, i have nothing much to protect.
Skip Tavakkolian
> | 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.
Jim Choate
No self respecting Cypherpunks would stand for it either.
Jim Choate
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."
matt
>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
Bruce Ellis
that matched the Topen of "cons" and then dumps the payload of Rreads
of that fid.
Russ Cox
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
matt
>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.
Rob Ristroph
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.
>>
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
YAMANASHI Takeshi
> 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
--
andrey mirtchovski
> 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