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.
The OpenAFS 1.2.x file servers will happily communicate with clients behind NATs although the file servers often get multiple clients confused because it is unable to track the clients by both IP address and port number. 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. Jeffrey Altman Ethan Tira-Thompson wrote: > 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: > http://www.openafs.org/pipermail/openafs-info/2001-January/000195.html > ...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.
smime.p7s
Description: S/MIME Cryptographic Signature
