[OpenAFS] client behind NAT firewall

[Simon Wilkinson]

> On 5 Aug 2014, at 14:08, Brandon Allbery <ballbery@sinenomine.net> wrote:
>=20
>> 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?
>=20
> 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").

This isn't actually the case, because of the complexities of imposing connec=
tions on top of UDP. Because UDP is a connectionless protocol, a firewall th=
at blocked all inbound UDP packets would prevent any two way UDP conversatio=
ns from occurring. Instead what firewalls and NATs do is open a hole/mapping=
 for inbound packets that matches the path taken by the outbound ones.

Because the cache manager listens for incoming callback breaks on the same p=
ort as it uses to send packets to the fileserver, this means that a firewall=
 hole for callbacks is created as a side effect of the original connection. T=
his is how AFS continues to work in the face of the Mac OS X firewall, for e=
xample

The complication is that firewalls/NATs only preserve these mappings for a f=
inite length of time. We attempt to keep them open through regular fileserve=
r pings, but sometimes that isn't enough. When a mapping expires, the client=
 is unable to receive callbacks until it next contacts the fileserver.

Cheers,

Simon=