Re: [9fans] Plan 9 system behind firewall

Re: [9fans] Plan 9 system behind firewall

[erik quanstrom]

> I have two sets of Plan 9 system within different IP domain, one of which
> is sitting behind the firewall made by a brordband router and using fossil+venti+
> auth/cpu server and terminals(Plan 9-1).
> Another is using Ken's fs, standalone auth server, cpu server, and terminals
> (Plan 9-2).
[...]
> Lastly, I tried to login to the Plan 9-1 system behind the firewall from the above
> Plan 9-2 system, and now I have problem.   When I booted the Plan 9 kernel from
> floppy drive (the kernel was read from the Plan 9-2 standalone auth server),
> I had to wait 5 minutes until some response from the Plan 9-1
> auth server behind the firewall.  It asked password, and I typed it, then,
> I can reach the CPU server, not the Plan 9 system.  I suppose this is same as
> cpu command, and then, I have no display for rio.   ---fact 4

are Plan9-1 and Plan9-2 in different authentication domains?  if they
are not, this could explain fact 4.  you would have two auth servers serving
the same authentication domain.   this would explain how cpu could work
when a direct login does not if you also have trouble contacting the remote
authentication server but not the local one.  this would allow plan 9 to know
about the local auth server when drawterm may not.

the long timeouts are sound like dns lookup problems to me.  i generally
double-check my ndb entries in cases like this, especially the auth, ip, and
ipnet entries associated with the auth server.

	- erik

[9fans] Plan 9 system behind firewall

[kokamoto]

I have two sets of Plan 9 system within different IP domain, one of which
is sitting behind the firewall made by a brordband router and using fossil+venti+
auth/cpu server and terminals(Plan 9-1).
Another is using Ken's fs, standalone auth server, cpu server, and terminals
(Plan 9-2).

When I use drawtrerm for Wn XP (belong th the same domain as Plan9-2),
it does work fine by such the command as drawterm -a 'IP of auth server'
-c 'IP of cpu server(=auth server)'.  It's fine, no excess time are neccessary,
just done within 30 seconds.   ---fact 1

Then, I tried drawterm for linux (newest stable Debian actually) as the same
command also from the outside of the Plan 9-1 domain.   In this case,
I have to wait 3 to 4 minutes until loging in the cpu server behind the firewall.   ---fact 2

Then, I tried to use the Plan 9-1 system from another Plan 9-2 system I have.
First, I made 9fs from a terminal of Plan 9-2 to the cpu server of the Plan 9-2,
and got good success.
This was done also withing 30 seconds.
I have a line of
auth='machine name of the broadband router' authdom='auth domain of that
Plan 9 system behind the router'
in /lib/ndb/local file on the Plan 9-2 system.   ---fact 3

Lastly, I tried to login to the Plan 9-1 system behind the firewall from the above
Plan 9-2 system, and now I have problem.   When I booted the Plan 9 kernel from
floppy drive (the kernel was read from the Plan 9-2 standalone auth server),
I had to wait 5 minutes until some response from the Plan 9-1
auth server behind the firewall.  It asked password, and I typed it, then,
I can reach the CPU server, not the Plan 9 system.  I suppose this is same as
cpu command, and then, I have no display for rio.   ---fact 4

questions:

Why I can 9fs but not login?
Why such a long time were necceessary for Linux and Plan9
to get factotum responce?
What is different between drawterm and ordinal login mechanism?

Thanks in advance,

Kenji  --now in big confusion

Re: [9fans] Plan 9 system behind firewall

[Richard Miller]

A long delay when connecting to a server behind a firewall may be an
attempt to connect to the secstore port.

Terminals booting with a remote fileserver, and some configurations of
drawterm, will look for a secstore server, by default at address
tcp!$auth!5356.  If the auth machine isn't running auth/secstored,
normally the client will immediately receive a tcp RST to show that
the port is closed.  But if a firewall is blocking the port by
silently dropping packets, you'll get a long timeout instead.

Can you configure the firewall to open tcp port 5356?  If not, you can
specify a different secstore address with argument '-s address' for
drawterm, or by replying 'okamoto@address' instead of just 'okamoto'
to the user: prompt when booting.  If you don't have a secstore, just
give an invalid dial string:
  user: okamoto@!
or
  drawterm -c cpuserver -a authserver -s !

Re: [9fans] Plan 9 system behind firewall

[kokamoto]

Thank you very much, Richard.

> A long delay when connecting to a server behind a firewall may be an
> attempt to connect to the secstore port.

I'm not running secstore yet at the target (Plan 9-2) auth server.

> Can you configure the firewall to open tcp port 5356?

Yes, I can.
I'll try this soon.   I'm now in a very tough time schedules, because of
our comming new year, semester, here.

Our situation is as this figure.   Plan 9-1 and Plan 9-2 have local ip addresses,
say 192.168.1.xx for Plan 9-1, 192.168.50.xx for Plan 9-2.  Both firewall
machines have global ip addresses.

                                                          real wall
___________                                         || other building                         ____________
|    Plan 9-1   |==>Linux box's <=============>another firewall<=|   Plan 9-2        |
| (Ken's fs,      |         firewall             Univ  LAN            BB router             | venti+fossil+   |
| auth server, |                                                              MZK-40g??           | cpu server,      |
| cpu server,  |       other Debian                                                                | terminals         |
|terminals)    |            machines                                                                 |Debian, XP etc |
| Windows XP|                                                                                             _____________
-----------

Now attempting to reach from Plan 9-1 domain terminal to Plan 9-2 system.

One correction of my last mail:
I can boot Plan 9 terminal in the Plan 9-1 domain using Plan 9-2 file/auth
server.   It was just too long time than I can wait.    5.5 minutes from
boot the kernel to a factotum responce of Plan 9-2 server, and 5 more minutes
from it to get rio system (after type of password), total=10.5 minutes.
Yes, then, I judged it failed to bootup.   After the success of bootup,
there is no problem, and I can use the Plan 9 teminal as usual way.

I cannot solve this tommorow, Friday maybe.

Kenji

Re: [9fans] Plan 9 system behind firewall

[john]

Kenji,
I have had similar problems booting terminals from remote fileservers
and even when loading drawterm on a computer connected to the
CPU/auth/file server by a single switch.  In the latter case, at
least, my problem seems to have been related to a misconfigured
/lib/ndb/local.  Anticipating a forthcoming network change, I had used
the server's as-yet-unconfigured domain name in /lib/ndb/local in
various dom= and auth= fields.  As some people have speculated, this
seems to cause an attempted DNS lookup somewhere along the line, but
since that name doesn't resolve to the correct machine, you end up
waiting a long time.  Changing "plan9.domain" to just "plan9" in the
auth= and dom= fields for my network and server entries seems to have
cleared up the problem.


John

Re: [9fans] Plan 9 system behind firewall

[kokamoto]

I tryed Richard's suggestion, and got very good success.
Thank you very much, Richard.
Now I can drawterm from other IP domain than Plan 9-2 domain
on Windows or Debian Linux.

The last one, the long time delay of getting rio bootup remaines
unsolved.   However, it takes at doing /usr/okamoto/lib/profile,
especially a line of
mount -c /srv/boot /n/duniteother other,
which is mounting 'other' file system to the main file system from
the file server dunite withing Plan 9-2 system.

I think I know why this happens, probably as John wrote yesterday.
>From outside the firewall, we have to target the fileserver as the
fierewall machine, but after loged in we have to target dunite fileserver
withing the domain...
I'll try it next week.
I don't know I can solve it cleanly or not, though.

Kenji