[OpenAFS-devel] Multiple clients behind NAT

[Ethan Tira-Thompson]

> OpenAFS has certainly had its struggles with clients behind NATs.
> With the 1.4.2 OpenAFS file server I believe that all of these
> troubles are behind us.  The performance of clients behind NATs
> has been successively improved with each of the 1.4.x releases.
Is there a way to tell what version a server is running?
Or anyone just happen to know what version CMU is running on  
{andrew,cs}.cmu.edu? ;)

> One of the features of most NAT solutions is that the NAT will
> map external port numbers to internal address/port values.  If your
> NAT configuration is failing to do this, then you will have trouble
> with many applications.
Well, it wouldn't be NAT if it's not mapping addresses between the  
private and public interfaces ;)
I've done some reading and satisfied myself that it is indeed common  
for NAT to do port mapping as well as address mapping, so multiple  
clients using the same port is fine (the first gets to use the "real"  
port, and the others get remapped to a different source port on the  
public interface so the NAT tell them apart).

However, the trouble I didn't originally foresee is that the AFS  
client running on the NAT box is running on the public network, and  
gets direct access without consulting the NAT.  (or does it?)  So if  
a machine on the private network tries to use the same port, I'm not  
sure if the NAT server can know that another process on the machine  
is already using that port, particularly with UDP (with TCP, it could  
figure out that it can't bind to the port, but with UDP being  
stateless, it might not know there's another process also using the  
port...?)

So if anyone has some experience with this particular configuration  
I'd love to hear about it, or tips on how to configure iptables to  
use dynamic port mapping (where it always remaps the ports instead of  
trying to reuse the source port number), or alternatively remap  
traffic from 7001 on the specific private client to a different port.  
(i'll have to play with that more on Monday)

thanks,
   -ethan