Managing NFS and NIS, 2nd Edition - Mike Eisler [151]
The NFS client first contacts the NFS server's portmapper or rpcbind daemon to find the port of the mount daemon. While the portmapper and rpcbind daemons listen on a well-known port, mountd typically does not. Since: Firewalls typically filter based on ports.
Firewalls typically block all incoming UDP traffic except for some DNS traffic to specific DNS servers.
Portmapper requests and responses often use UDP.
mountd alone can frustrate your aim.
The NFS client then contacts the mountd daemon to get the root filehandle for the mounted filesystem.
The NFS client then contacts the portmapper or rpcbind daemon to find the port that the NFS server typically listens on. The NFS server is all but certainly listening on port 2049, so changing the firewall filters to allow requests to 2049 is not hard to do. But again we have the issue of the portmapper requests themselves going over UDP.
After the NFS client mounts the filesystem, if it does any file or record locking, the lock requests will require a consultation with the portmapper or rpcbind daemon to find the lock manager's port. Some lock managers listen on a fixed port, so this would seem to be a surmountable issue. However, the lock manager makes callbacks to the client's lock manager, and the source port of the callbacks is not fixed.
Then there is the status monitor, which is also not on a fixed port. The status monitor is needed every time a client makes first contact with a lock manager, and also for recovery.
To deal with this, you can pass the following options to the mount command, the automounter map entry, or the vfstab:
mount commmand:
mount -o proto=tcp,public nfs.eisler.com:/export/home/mre /mre
automounter auto_home entry:
mre -proto=tcp,public nfs.eisler.com:/export/home/&
vfstab entry:
nfs.eisler.com:/export/home/mre - /mre nfs - no proto=tcp,public
The proto=tcp option forces the mount to use the TCP/IP protocol. Firewalls prefer to deal with TCP because it establishes state that the firewall can use to know if a TCP segment from the outside is a response from an external server, or a call from an external client. The former is not usually deemed risky, whereas the latter usually is.
The public option does the following:
Bypasses the portmapper entirely and always contacts the NFS server on port 2049 (or a different port if the port= option is specified to the mount command). It sends a NULL ping to the NFS Version 3 server first, and if that fails, tries the NFS Version 2 server next.
Makes the NFS client contact the NFS server directory to get the initial filehandle. How is this possible? The NFS client sends a LOOKUP request using a null filehandle (the public filehandle) and a pathname to the server (in the preceding example, the pathname would be /export/home). Null filehandles are extremely unlikely to map to a real file or directory, so this tells the server that understands public filehandles that this is really a mount request. The name is interpreted as a multicomponent place-name, with each component separated by slashes (/). A filehandle is returned from LOOKUP.
Marks the NFS mounts with the llock option. This is an undocumented mount option that says to handle all locking requests for file on the NFS filesystem locally. This is somewhat dangerous in that if there is real contention for the filesystem from multiple NFS clients, file corruption can result. But as long as you know what you are doing (and you can share the filesystem to a single host, or share it read-only to be sure), this is safe to do.
If your firewall uses Network Address Translation, which translates private IP addresses behind the firewall to public IP addresses in front of the firewall, you shouldn't have problems. However, if you are using any of the security schemes discussed in the section Section 12.5, be advised that they are designed for Intranets, and require collateral network services