asked on

NFS issues with open ports

We ran into something strange. We have a Solaris 10 NFS 4 that has serveral Redhat Linux NFS 3 & 4 clients. On the NFS 3 clients, we have permissions issues and of the NFS 4 clients we have connections issues. Users on the NFS 3 clients can't modify anything even if it seems they own it. NFS 4 clients can't connect unless we open every port on the firewall. Seems to be opening random ports and no one want to leave every port open. Any ideas?

arnold

What is the status of port 2049?
http://blogs.sun.com/macrbg/entry/solaris_nfsv4_client_mount_from

How what authenticates users are you using local user credentials, NIS, NIS+, LDAP? This deals with the NFSv3 client issues.

flaco01

ASKER

2049? Open by nfsd - udp and tcp.

We aren't using NIS or NIS+ anywhere here at this time. We have LDAP implemented but none of these systems are included. I could probably talk them into it, but I'm bound to face alot of resistance unless this is the only option. They'll only go for it if there is no solution for the v4-v4 random ports issue since having all the port open on the firewall is a major security violation that they can't allow. So the odvious questions are: Is LDAP, NIS, NIS+ the only options for the permissions issue with Solaris NFS v4 servers to Linux NFS v3 clients? And, of course, is there a way to control the opening of random port in Solaris NFS v4 servers to Linux NFS v4 clients? Maybe specify which ports to use so we can lock down the firewall?

BTW, seems like that blog is for Linux NFS server and Solaris NFS client, which is the opposite of what have and I don't think that's works in my setup. And instead of the random port issue, it covers how to allow connections from non-reserve ports. That's good info, but it still leave me with a wide open firewall which I can't have.

arnold

Even random ports fall within a range, you might setup the firewall rules to cover the IPs of the clients along with a port range. I.e. group the clients and then allow the group access to the NFSv4 server over a range of ports.

Also what the status of port 2050?
http://www.tools.ietf.org/wg/nfsv4/draft-ietf-nfsv4-nfsdirect/draft-ietf-nfsv4-nfsdirect-06-from-05.diff.txt

You could pin the NFS to a port using the -p option for the daemons:

http://tldp.org/HOWTO/NFS-HOWTO/security.html

flaco01

ASKER

"pin the NFS to a port" sounds like what I was looking for. I'm not going to affect performance by doing that, am I? Just in case it isn't or causes a problem, configuring the firewall to cover the range seems like another good option. But is the range a default value that uses the same set every time? I can probably figure out the start of the range from rpcinfo output, but that does state the end of the range, does it? Do you know of some place I can find a document that list those ranges? BTW, Port 2050 is not open, see rpcinfo output below:

program vers proto port service
100000 4 tcp 111 rpcbind
100000 3 tcp 111 rpcbind
100000 2 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100000 3 udp 111 rpcbind
100000 2 udp 111 rpcbind
100229 1 tcp 32781 metad
100229 2 tcp 32781 metad
100230 1 tcp 32782 metamhd
100001 2 udp 32776 rstatd
100001 3 udp 32776 rstatd
100001 4 udp 32776 rstatd
100145 1 tcp 32783 scadmd
100533 1 tcp 32784 scrcmd
100242 1 tcp 32785 metamedd
100281 1 tcp 32786 metacld
100422 1 tcp 32787
100005 1 udp 32810 mountd
100005 2 udp 32810 mountd
100005 3 udp 32810 mountd
100005 1 tcp 32869 mountd
100005 2 tcp 32869 mountd
100005 3 tcp 32869 mountd
100248 2 udp 32811 pmfd
100248 2 tcp 32870 pmfd
100142 2 udp 32815 fed
100142 2 tcp 32872 fed
100141 1 udp 32823 rgmd_receptionist
100141 1 tcp 32880 rgmd_receptionist
100024 1 udp 54162 status
100024 1 tcp 55119 status
100133 1 udp 54162
100133 1 tcp 55119
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
805306372 1 udp 55290
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl
100141 1 udp 32823 rgmd_receptionist
100141 1 tcp 32880 rgmd_receptionist
100024 1 udp 54162 status
100024 1 tcp 55119 status
100133 1 udp 54162
100133 1 tcp 55119
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
805306372 1 udp 55290
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100227 2 udp 2049 nfs_acl
100227 3 udp 2049 nfs_acl
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100227 2 tcp 2049 nfs_acl
100227 3 tcp 2049 nfs_acl

arnold

This information is coming from which side;the server or the client?

The only way a server knows to what port to connect on a client is if they have an existing connection through which the server can access and determine the information. I do not see how binding a resource to a specific port versus allowing the resource to randomly select the port would lead to a degradation of performance. Try this. Setup one server with NFS related client applicaiton with the -p to bind them to a specific port.
port ranges 32700-32900 UDP/TCP and 54000-56000 UDP/TCP limited with the NFS server as the source/destination depending on the answer to the first question in this post.
111,2049,4045 seems to cover the gambit of random ports.

flaco01

ASKER

The rpcinfo output was from the server.

flaco01

ASKER

FYI: I need to corect something. I wrote it backward and didn't realize it. The random ports issue was happening when running Solaris 10 with NFS Server 4 and Redhat Enterprise with NFS Client 3.. The permissions issue was with Solaris 10 with NFS Server 4 and Redhat Enterprise with NFS Client 4.

We tested both of the solution you provided for the ports issues and they both work (big thank you from everyone here). The next, and last, thing I need to address before closing this question is the permissions issue we've seen when a NFS 4 client on a Linux mount a share from a NFS 4 server on a Solaris 10 system. Everything I've found online address a Linux NFS server and a Solaris Client. I don't know if the solutions apply in a reverse scenario.

The link posted earlier speaks of adding the insecure option on a Linux NFS4 server because the Solaris NFS 3 Client is using non-reserve ports. It's that what's causing this or is there something more complex going on? Any ideas?

ASKER CERTIFIED SOLUTION

arnold

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial