H-UX NFS Server Force Specific Ports

[Ken Martin_3]

When running NFS Server on an HP-UX machine thru a firewall is there a way to force the UP-UX machine to assign 'specific' ports via portmapper for lockd, statd, mountd and pcnfsd, etc?

With portmapper assigning different port numbers to these services creates problems when the HP is behind a firewall. If the NFS services are stopped and restarted or the system reboots it may assign different port numbers. The client P.C. talks to portmapper OK but may get blocked from the ports portmapper assigns to the services by the firewall. For example the P.C. client won't see the file systems the HP is exporting.

The HP server in this case is running HP-UX 10.20.

Thanks.

[Dave Olker]

Hi Ken,

Nope, can't do this on 10.20. We recently introduced patches to allow the fixing of rpc.lockd, rpc.mountd and rpc.statd on specific ports but these patches only apply to 11.11 and 11.23. No chance of anything like this ever rolling back to 10.20.

Portmapper and nfsd always use the same ports. Pcnfsd was not taken into consideration during our fixed ports investigation so that one didn't get a fixed port assignment. If other customers (at 11.11 and higher) inform me there is a need for fixing pcnfsd at a specific port then I can take that feedback to the development team and we can evaluate it.

If memory serves, this isn't the first time you've had a problem with this 10.20 system.... Might be time for an update to a supported OS release.

Regards,

Dave

[Dave Olker]

One other point of clarification Ken - portmapper doesn't "assign" port numbers to any daemons, it merely keeps track of the port numbers that these daemons get assigned by the kernel and then register with portmapper.

For example, when rpc.mountd starts it asks the kernel for a port in the anonymous range (between 48K and 64K on most HP-UX platforms). The port it gets could be 49887, or it could be 54225, etc. What ever port it's assigned, it then contacts portmapper/rpcbind (depending on which OS you're running) and says "my program number is 100005, my version number is 1 (or 2 or 3), my port number is 49887, my protocol is TCP (or UDP)" and portmapper keeps track of this information. That way when some remote system says "I need to talk to the mountd program, version 1, TCP" the portmapper knows which port number to respond back with.

A subtle distinction, but an important one.

Dave

[Ken Martin_3]

Dave,

As scary as this might sound. If it is kernel driven could there be a way to adjust a kernel setting to fix a port to a service?

Just asking as a fix.

At this late point I can't see them upgrading to HP-UX 11 as the legacy apps that are running only work under 10.20 and the app vendor is bye-bye.

Thanks.

[Ken Martin_3]

Dave,

Regarding a previous 10.20 system you are correct. 'Good memory'

One is a workstation class and one is a server class machine.

Unfortunately these machines have a limited future as the legacy apps they are running are going to be replaced in the future.

Ken

[Dave Olker]

Hi Ken,

We evaluated several options when we decided upon the current solution for 11.11/11.23, which is to allow customers to put the desired port numbers in the /etc/rc.config.d/nfsconf file, read that file at daemon start time and bind the daemons to the requested ports.

Even if there were different ways to fix this at 10.20, there is no way we'd ever entertain making such a change. For one thing, that OS has been out of support for years. For another, I think most of the labs have torn down their 10.20 build environments years ago, so even if they wanted to patch the 10.20 code they wouldn't have an environment available to build the binaries.

Prior to these fixed-port changes on 11.11 and 11.23, I would tell customers to use ndd to limit the size of their anonymous port range and then configure the firewall to allow the entire range of ports. Even thought this wasn't a great solution, it sure beat opening all ports between 48K and 64K. I would tell them to restrict the anonymous port range to 1000 ports to start (i.e. 48K to 49K). If everything worked fine, then they could keep cutting down the size of the anonymous port pool as long as the applications on their system had the ports they needed to do their job.

Some customers eventually configured anonymous port ranges with as few as 50 to 100 ports. That made it much easier to configure their firewalls. Other customers, with different application loads, determined they needed 1000 or more anonymous ports for their applications to behave normally.

Unfortunately, I don't even know if this solution is available at 10.20. I don't think we introduced ndd until 11.X so I don't know if there is an equivalent mechanism on 10.20 to restrict the size of the reserved port range. Also, I know we've changed the behavior of these daemons over time from one of binding to reserved ports to one of binding to anonymous ports. Again, it's too long ago for me to remember off the top of my head (especially on a Saturday morning sitting in my kitchen).

In any case, I'm just providing this bit of historical insight in case it helps others trying to configure NFS servers behind firewalls. Of course, anyone serious about doing this would upgrade to either 11.11 or preferably 11.23 and use the fixed-port option.

Regards,

Dave

[Ken Martin_3]

Dave,

Thanks for the historical information!

Last night I tried running rpc.mountd with and without the '-p' option which according to the 'man' page for 10.20 is supposed to determine if it uses reserved or unreserved ports.

Of course stopping and restarting NFS server in between.

It didn't seem to make a difference when P.C.'s made NFS connections to the HP. It still used ports in the 700-900 range or there abouts for UDP and TCP. Lockd around 1000-1040.

Ken

[Dave Olker · Accepted solution]

Hi Ken,

Regarding the -p option for rpc.mountd, the man page might be ambiguous or even wrong about what this option does.

The -p option does not allow rpc.mountd to register on ports in the non-reserved range. What -p does is allows rpc.mountd to *accept requests* that arrive on non-reserved ports. In other words, without the -p option, mountd will only listen to MOUNT/UNMOUNT etc. requests that arrive on ports in the range 1-1024. The thinking is that you must be a root user to use a port in this range, so mountd is using the port range as a type of security check.

Launching rpc.mountd with the -p option tells mountd to disable this check and accept requests regardless of which port number they arrive on. Again, nothing to do with which ports rpc.mountd uses or registers with portmapper.

Regards,

Dave

[Ken Martin_3]

Required clearer understand of how NFS server daemons operate so a plan could be made to operate it behind a fire wall.

With HP-UX 10.20 no real flexability.

With HP-UX 11 some control.

With current HP-UX 11 better control.

Still, problems exist when used behind a fire wall.