Kerberized NFS (GSS-API) problem with multiple-IP Address and single hostname

[Frank Cusack]

On 1/4/11 8:54 AM -0500 Derek Atkins wrote:
> Hi,
>
> sandeep patil <san_patil at hotmail.com> writes:
>
>> To be specific;
>> I have kerberized NFS server running on 3 separate machine (exporting
>> the same share) where ever machine has a different IP address but the
>> same hostname (In other words the hostname is associated with 3
>> IP-address- for general load balancing using DNS). Now when I acquire
>> kerberos credentials from a client machine and mount the NFS share
>> against the hostname ,it fails. The reason it seems to fail is because
>> when the gss-api handshake takes place between the NFS client and NFS
>> server , the kerberos/gss-api library always tends to resolve the
>> hostname to ipaddress and in this case ends up getting different IP
>> address.  So looks like when we mount NFS, the first part of the gss-api
>> handshake takes place with one machine and in the next iteration it goes
>> to a different machine ( where there is no gss-api context) and hence it
>> fails.
>
> I don't think the problem is that name.example.com results in multiple
> IP Addresses.  I think the problem is that the reverse-resolution of the
> IP Addresses result in 3 different names!  I suspect it's trying to use
> the reverse-resolution to find the name to use for kerberos.

No, as Sandeep explained, when an NFS request goes to an IP that wasn't
the IP the host mounted from, that new machine doesn't have a GSSAPI
context.  NFS doesn't use the raw Kerberos session key, it establishes
a context, which is server-specific state.

Even if it could just use the raw session key, you wouldn't want that
because you wouldn't be able to detect replay.

If the reverse's didn't match it wouldn't work but the symptoms would
be different.

You did make me think of another solution.  Force the use of TCP.  That
won't be 100% reliable (depends on client implementation) but it might
be good enough.