[OpenAFS-devel] Multiple clients behind NAT

Fri, 07 Jul 2006 11:10:07 -0700

I have a setup where I have a OpenAFS client behind a NAT box (linux running iptables), and the NAT box itself is also an AFS client (it's more than *just* a NAT box).  As far as I can tell, this is a problem because both clients use the port 7001 for their outgoing requests, and so when reply packets come back to that port, the NAT is unable to determine which packets to keep and which to forward on. (or more generally, which packets to send to which client)

Back in 2001, there was a message regarding this issue:
...in particular, this section:
Rx presently requires that anything that wants to be a server pick a port number up front.  I'll be submitting patches later this week that allow a server to be started on the "random" port assigned when rx_Init(0) is called, which will allow user-mode RXAFS clients that use randomly-selected ports.
Was this patch ever integrated?  Since all outgoing communication appears to be from port 7001, I don't think so.

I'm not a huge nat/iptables expert, so perhaps I'm missing something.  I'm guessing there's a way to tell iptables to specifically watch for port 7001 from the each client, and remap those to another unique port when forwarding to the public interface so it can tell the replies to client's messages apart.  Would that work?  (I believe that's the suggested workaround in the quoted message)

Is that necessary to manually configure though, or should there be some smartness to do that automatically already (e.g. what would happen if two NAT'd machines try to send from the same source port out to the same host using TCP?  Does the NAT box just drop one of their connections, or does it remap one of their ports on the public interface?  Would it be smart enough to do that with UDP?)

thanks,
  -ethan

PS On another topic, it would be nice to have more complete documentation for afsd options, e.g. the afsd.options file -- the admin guide (http://openafs.org/pages/doc/AdminGuide/auagd015.htm#HDRWQ391) does a pretty good with the cache options, but completely neglects discussion of many other parameters, such as -fakestat{-all}, stat, daemons, volumes, etc.   Some of these are mentioned on other sites' pages, but there should be some central documentation that lists all of the parameters.

Reply via email to