[OpenAFS] client behind NAT firewall

Alex euergetikos.k@gmail.com
Tue, 05 Aug 2014 16:12:41 +0200

On 08/05/14 15:08, Brandon Allbery wrote:
> On Tue, 2014-08-05 at 09:30 +0200, Alex wrote:
>> Now, I didn't find in the admin guide or wiki[1] some useful
>> information
>> about client's firewall, but I could find some information on the
>> Internet saying that client doesn't work without opening 7001 for
>> incoming UDP [2]. This should be open for callbacks (if I understood
>> correctly). I also tested the client behind NAT with some public cells
>> and it worked well. So, does a client work behind a firewall NAT even
>> without opening inbound ports? If not, is there any solution for this?
> You will get basic client functionality even without opening the port.
> What you won't get is notifications from the server that something the
> server knows to be cached on the client has been modified elsewhere and
> the client should flush its cached information (this is the "callback").
> In most cases, clients already discard this cached information after
> some amount of time; additionally, if you are mostly using read-only
> volumes then the cached information would only be invalidated by a new
> volume release. In addition, even if you open the port, most NAT
> implementations don't retain UDP NAT mappings for long enough to be
> useful for callback breaks (generally their expected use case for UDP is
> DNS). So you might be able to get by with just running "fs checkvolumes"
> periodically in a cron job to make up for missing callback breaks on
> volume releases. For the most reliable operation, however, you should
> check that the NAT gateway can remember UDP NAT mappings *specifically
> on client port 7001* for at least 2 hours and open 7001/udp in the
> firewall so the client can receive callback breaks.
Thank you all for answering, I guess we should test it more carefully to
check how it will work. Parallel access is a must for us.The main
concern is the possibility that one client overwrites modifications of
another one who is editing the file in the same time.