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
================================================================================
