[OpenAFS] NAT issues.

[ted creedon]

For what its worth, an identical problem was solved by placing the afs
server on a DMZ running its own firewall, installing 2 nic cards, one
internal and one external, and writing firewall rules to match. Only afs
traffic is allowed from the internal net to the afs server which also is the
KRB5 server.

Setting appropriate firewall logging rules helps as well as nmap and snort
to verify the firewall integrity.

The clients can be behind remote firewalls. All clients grab tokens from the
external net interface....

tedc

-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
On Behalf Of Jeffrey Altman
Sent: Wednesday, April 26, 2006 3:00 PM
To: Jeffrey Hartwigsen
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] NAT issues.

Jeffrey Hartwigsen wrote:

> After resetting the UDP timeouts on both of our NAT boxes to 11 minutes,
> things are much improved. We are still experiencing some problems with
> timeouts though. (Windows claims "The network path cannot be found" when
> trying to access filespace)

And what about when trying to reach \\afs\all\ ?

If you get the same error, then this with the Windows CIFS client
deciding that the "AFS" SMB server is unreachable.  The Windows CIFS
client gets very confused when the AFS SMB server is unable to send
responses promptly.  The CIFS client keeps track of the average response
time and when the response must wait for the AFS file server, then the
CIFS client begins to time out and break the connection to the AFS SMB
server.  It then begins a series of retries to read the same data.

> What does this line in the Filelog mean?
> 
> Wed Apr 26 16:12:12 2006 SAFS_FetchStatus,  Fid = 536870918.10604.5870,
> Host 192.188.163.112:12096, Id 6
> Wed Apr 26 16:12:12 2006 SAFS_FetchStatus,  Fid = 536870918.10602.5869,
> Host 192.188.163.112:12096, Id 6
> Wed Apr 26 16:12:12 2006 SAFS_FetchStatus,  Fid = 536870918.10600.5868,
> Host 192.188.163.112:12096, Id 6
> 
> I had 939 entries like this seemingly from the same client (port number)
> within 2 seconds. I'm also still getting some ProbeUuid failures. I can
> send the context of those along to if it would be helpful.

It means that the file server has received a Fetch Status call from the
client at 192.188.163.112:12096

Now the question is whether or not on the file server you can

  rxdebug 192.188.163.112 12096 -ver

and get a response.  If not, then the NAT is blocking the file server
from sending to the client.  939 requests in two seconds is very high.
I would need to see what else is going on at the same time.

Jeffrey Altman