[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [FW1] Running NFS over CPF1
Hi all, Were having problems getting NFS on 2 sun machines to talk through our CPF1 4.1 install. The firewall has been up and working for some time now, but this is the first time that we have tried to get NFS running through it. The following is a little long, but I think it describes our work to date accurately. Any help that you might lend would be appreciated. Svrhost is behind the firewall-1 and is using static address translation. Clthost is outside of the firewall-1. This is what we did: Share /data_disk/data from svrhost to clthost. - On svrhost, create edit /etc/dfs/dfstab and add this line to share /data_disk/data to clthost: share -F nfs -o rw=clthost -d "DATA DISK" /data_disk/data - Share it with 'shareall'. - Since nothing was shared at last boot, svrhost is not running nfsd. Start nfsd with '/etc/rc3.d/S15nfs.server start'. - Add a rule to the firewall (fwhost) allowing nfs from clthost to svrhost. - On fwhost, run fwpolicy. - Add a rule just above the final three rules that drop things allowing NFS from clthost to svrhost: Source Destination Service Action Install On Track ------ ----------- ------- ------ ---------- ----- clthost svrhost NFS Allow Gateways Long - Install it with 'Policy->Install'. - Mount it on clthost. - mkdir /data_disk/data - mount svrhost:/data_disk/data /data_disk/data - It hangs with: mount svrhost:/data_disk/data /data_disk/data nfs mount: svrhost: : RPC: Timed out nfs mount: retrying: /data_disk/data nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out nfs mount: svrhost: : RPC: Timed out - The firewall log shows: Action Service Source Destination S_Port ------ ------- ------ ----------- ------ Accept sunrpc svrhost (Valid Address) clthost 43249 Accept 48582 clthost svrhost (Valid Address) Drop 43249 svrhost (Valid Address) clthost 48582 - Snoop on svrhost shows: clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null svrhost -> clthost MOUNT3 R Null clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null svrhost -> clthost MOUNT3 R Null clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null svrhost -> clthost MOUNT3 R Null - Snoop on clthost shows: clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null clthost -> svrhost PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP svrhost -> clthost PORTMAP R GETPORT port=48582 clthost -> svrhost MOUNT3 C Null - ANALYSIS after doing alot of research: - Clthost first contacts svrhost's portmapper to find the port of mountd (rpc program 100005). This call succeeds and clthost receives a reply back from svrhost saying mountd is running at port 48582. The firewall works ok here. - Clthost then sends a Null rpc command to mountd on svrhost (I guess to tell if it's there or something). Clthost is using it's same source port it used for the portmap call. This succeeds. The firewall works ok here. - Svrhost's mountd responds to clthost's Null command, we see the packet leaving svrhost. But we see it never reaches clthost and clthost just keeps resending the Null command. The firewall log confirms that the firewall is dropping this packet. The firewall doesn't act as expected here. - Under fwpolicy->Policy->Properties->Security Policy, Allow UDP Replies is enabled. This setting allows replies to outgoing udp packets to be accepted back, with a timeout of 40 seconds. This setting is what should allow svrhost's reply to clthost's mountd Null command to pass. For some reason it is not working this way. Another strange thing is that the S_Port field for clthost's Null command to svrhost is blank. Does this mean the firewall is not remembering the source port for some reason and thus can't match svrhost's response to clthost's original query under the "Allow UDP Responses" rule???? - Under fwpolicy->Policy->Properties->Services, Enable RPC Control is enabled. This is necessary to allow rpc services to function properly through the firewall. This seems to be working since the firewall allows clthost to get the port for mountd and to send it's initial Null to mountd. - I tried these things to try to see if it would work (I'm skimping on details because the principles are as described above). - I changed the NFS firewall rule to allow communication in both directions: Source Destination Service Action Install On Track ------ ----------- ------- ------ ---------- ----- clthost svrhost NFS Allow Gateways Long svrhost clthost NFS Allow Gateways Long The results were exactly the same as before this change. - I shared /disk1 on clthost to svrhost, and with the above rule in place, I tried mounting /disk1 on svrhost from clthost. It failed in the same general way, only reversed. - Clthost's reply to svrhost's Null rpc command to mountd was blocked. - The firewall log showed svrhost and regular svrhost (the internal address), and not "svrhost (Valid Address)" as when mounting from svrhost to clthost. Could our static address translation be causing this UDP reply problem somehow?????? Svrhost is behind the firewall-1 and is using static address translation. Clthost is outside of the firewall-1. Ok, I know thats kinda long. Anyone got any ideas whats going on here? Thanks, Larry Taborek ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|