RE: [FW1] Running NFS over CPF1

[Lars.Troen@FW1-NOSPAMmerkantildata.no]

Larry,
After upgrading to SP2 we've encountered these problems similar to what
you're experiencing too. With 4.1SP1 it worked well, but after applying SP2
NFS would not work and time out. We have not found a proper solution to this
yet other than downgrading to SP1 or opening for high-ports between the
hosts (but that pretty much leave the hosts involved pretty much open on
other services as well).

Lars

> -----Original Message-----
> From: Larry Taborek [mailto:let@tecnet1.jcte.jcs.mil]
> Sent: Friday, November 03, 2000 5:25 PM
> To: fw-1-mailinglist@lists.us.checkpoint.com
> Subject: [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
> ==============================================================
> ==================
> 


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================