[OpenAFS] Placing an AFS server behind a NAT

[Lester Barrows]

Hi Jeff,

Thanks for the information, I did eventually find out that it was in fact the 
router that was causing trouble. Connections from 7000-7009 were not being 
allowed from all originating UDP ports, only 7000-7009, which seemed to cause 
it problems. Sorry to spam the list with what turned out to be a non-issue :-)

Regards,

Lester Barrows
Asani Solutions, LLC
Code IC Systems Group
NASA Ames Research Center

On Friday 11 June 2004 12:19, Jeffrey Hutzelman wrote:
> On Thursday, June 10, 2004 15:45:09 -0700 Lester Barrows
>
> <barrows@email.arc.nasa.gov> wrote:
> > Thanks for the reply. Perhaps my setup is a bit unusual, as the NAT
> > subnet has  two other AFS servers already connected to it, both of which
> > are multihomed  on an externally visible network. One of these other
> > servers runs the VLDB  service, and while both IP addresses are being
> > advertised, accessing the  "public" IP address for the new server doesn't
> > seem to work. Even on the new  server, it's not possible to execute e.g.
> > a "vos listvol <external IP  address>" command. Using the internal
> > "private" IP does work, but volumes on  this server are not visible
> > externally. The static NAT on the router appears  to be fine. Perhaps
> > this exact configuration is not possible?
>
> OK; for the moment, let's set aside any issues related to accessing the new
> server from inside the NAT, regardless of which address you're using.  We
> want to concentrate on what happens when you try to access that server
> using its public address from the public network.
>
> - Does it respond to 'rxdebug <server> 7000 -version' ?
> - Does it respond to something like vos listvol?
> If not, what error do you get?
>
> If you get a timeout/"communications error", then the next step is to run a
> network analyzer like tcpdump or ethereal on the inside network, and see if
> the packets are making it through the NAT, and what it's doing to them.
> Then look at whether the responses are making it back...
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA