Problem with nfs through firewall

[R.O.]

Hi all,

I have some vlans and I try to export a directory from a system in a vlan to the systems belonging to the other vlans. I have the ports 2049 (TCP & UDP) and 111 (TCP & UDP) opened in the firewall, but when I try to mount the exported directory I have this:

mount: RPC: Timed out (if the client is a Linux)
nfs mount: get_fh: xxx.xxx.xxx.xxx:: RPC: Timed out (if the client is HPUX; the server is HPUX)

I can nfs mount in other systems from the same vlan.
Does somebody knows where the problem is?

Regards,

R.O.

[K.Vijayaragavan.]

Do
rpcinfo -p

to see what all services reachable to your system from the remote host.

Refer
http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B1031-90043/B1031-90043_top.html&con=/hpux/onlinedocs/B1031-90043/00/00/32-con.html&toc=/hpux/onlinedocs/B1031-90043/00/00/32-toc.html&searchterms=rpcinfo&queryid=20030620-053047

[R.O.]

Hi,

From client to server:

client# rpcinfo -p server

program vers proto port
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 49356 mountd
100005 3 udp 49356 mountd
100005 1 tcp 60859 mountd
100005 3 tcp 60859 mountd
100003 2 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 tcp 2049 nfs
100003 3 udp 2049 nfs
1342177279 4 tcp 51556
1342177279 1 tcp 51556
1342177279 3 tcp 51556
1342177279 2 tcp 51556

From server to client:

server:/#rpcinfo -p client
rpcinfo: can't contact portmapper: RPC: Rpcbind failure - RPC: Failed (unspecified error)

This is what I see...

[Chris Vail]

You'll need to run rpcinfo -p HOSTNAME, where the hostname is your linux client outside the firewall. You will probably have to run it (or its Linux equivalent) on the linux box. When it lists out the ports that it is using, you'll have to modify your firewall to pass all those ports.

NFS is not a very secure facility for this reason. Its a good one, but really the industry needs to develop a Secure NFS.


Chris

[Kevin Wright]

For NFS to work through a firewall, you should have port 111, both tcp and udp, and tcp or udp 2049, depending on which protocol your using.

You may need to stop and restart your nfs server daemons.

[R.O.]

Hello,

I have seen that I need to open in the firewall the port for rpc.mountd. This daemon uses differents ports everytime it is restarted. So the question is ??Is there any way to force mountd to listen in the same port in the nfs server forever?
I tryed with -p option, but it does not work for this case.

Regards

[Shannon Petry]

NFS does not always use the same port numbers, so you need to change the firewall a bit. What you need to do, is allow all traffic from NFS_HOST to NFS_CLIENT. There is no way around this, and it is very insecure.

Your next option is to ensure that NFS is handled in each LAN separately.

Regards,
Shannon

[Kevin Wright]

Not 100% sure on HP, but on solaris, mountd is not required to be open to clients. Mountd responds to request made from the LOCAL nfsd, and determines if the permissions are OK for the client to mount the filesystem. It has no interaction with the client, except through nfsd. If nfsd, 2049 is open all should be OK.

[Chris Vail]

As Shannon (and I) mentioned, NFS really isn't terribly secure. It is, however, very convenient. You really can't push it through a firewall very easily at all. And if you do, it won't be very secure.

But there's more than one way to do this. Consider creating a private, back-to-back LAN from one server to another directly through the appropriate cable. Then mount the NFS volume either read only, or write only--depending on your need. This is a LOT more secure, but not as much as it might be.

An expensive solution (that we use here) is to use EMC's Celerra product. This is a NFS to fiber gateway, with access both inside and outside the firewall. We use the BCV (Business Continuance Volume) process to mirror data outside the firewall. Once that is done, we logically attach the filesystem to a host inside the firewall, where it goes through virus scanning. Finally, we attach it (again logically) to a 4th host (also inside the firewall) where the data files are acted on by the software. If this sounds complicated and expensive, you're right. Its also REALLY secure, as never does a user from outside the company ever see the systems behind the firewall. But it moves data quite efficiently between environments.

EMC is discontinuing the Celerra, so you can pick one of these up cheap (still over $100kUSD, however). At least go to EMC's website and check it out. They're pretty desperate for sales these days, so you may be able to strike a bargain.


Chris

[Suresh Patoria]

Hi,

Try the following step

1.)You able to ping remote server

2.) You able to reach the remote service through the rpcinfo -p

3.) On server and client end the run the command rpcbind -w

[Suresh Patoria]

Hi,

Try the following step

1.)You able to ping remote server

2.) You able to reach the remote service through the rpcinfo -p

3.) On server and client end the run the command rpcbind -w

4.) check the remote hosts entry in the /etc/hosts file

5.) check the nfsd daemon enable in /etc/rc.config.d/nfsconf file