NFS and iptables.

NFS and iptables.

[Krunk]

I've bound my NFS ports (moountd, statd, lockd, quotad) and freed up the
ports they are bound to, but the client still hangs when I try to mount
the remote share. 

rpcinfo -p
 program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  32765  status
    100024    1   tcp  32765  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  32772  nlockmgr
    100021    3   udp  32772  nlockmgr
    100021    4   udp  32772  nlockmgr
    100021    1   tcp  32769  nlockmgr
    100021    3   tcp  32769  nlockmgr
    100021    4   tcp  32769  nlockmgr
    100005    1   udp  32767  mountd
    100005    1   tcp  32767  mountd
    100005    2   udp  32767  mountd
    100005    2   tcp  32767  mountd
    100005    3   udp  32767  mountd
    100005    3   tcp  32767  mountd

command that opens ports:
 NFS="2049 32764 32765 32766 32767 32768 32772 sunrpc"
# opening tcp for NFS
for i in $NFS
do
   echo -n "$i"
   $IPT -A OUTPUT  -o $EXTIF -p tcp -s $EXTIP  \
    --dport $i --syn -m state --state NEW -j ACCEPT
   $IPT -A FORWARD -i $INTIF1 -p tcp -s $INTNET1 \
    --dport $i --syn -m state --state NEW -j ACCEPT
   $IPT -A FORWARD -i $INTIF2 -p tcp -s $INTNET2 \
    --dport $i --syn -m state --state NEW -j ACCEPT
done
echo ""
#opening udp for NFS
for i in $NFS
do
    echo -n "$i"
    $IPT -A OUTPUT  -o $EXTIF -p udp -s $EXTIP  \
        --dport $i -m state --state NEW -j ACCEPT
    $IPT -A FORWARD -i $INTIF1 -p udp -s $INTNET1 \
        --dport $i -m state --state NEW -j ACCEPT
    $IPT -A FORWARD -i $INTIF2 -p udp -s $INTNET2 \
        --dport $i -m state --state NEW -j ACCEPT
done
echo ""


This same loop is used for every service I've opened up (cups, ssh, etc)
and works fine. So I'm sure the loop itself works (e.g. it's in the
right spot sequentially, and the rest of the script works fine).

output of log file when client is trying to connect:

Apr 24 16:53:35 tuxmac DROPl:IN=eth1 OUT= MAC=<mac here> SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=41035 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 24 16:53:37 tuxmac DROPl:IN=ppp0 OUT= MAC= SRC=129.81.224.6 DST=<my isp assigned ip> LEN=89 TOS=0x00 PREC=0x00 TTL=46 ID=17196 DF PROTO=TCP SPT=143 DPT=49366 WINDOW=32900 RES=0x00 ACK PSH FIN URGP=0
Apr 24 16:53:38 tuxmac DROPl:IN=eth1 OUT= MAC=<eth1 mack here> SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=41036 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 24 16:53:44 tuxmac DROPl:IN=eth1 OUT= MAC=<eth1 mac here> SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=41037 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN URGP=0

The source and destination ip's are right.

Re: NFS and iptables.

[Cedric Blancher]

Le dim 25/04/2004 à 00:00, Krunk a écrit :
> I've bound my NFS ports (moountd, statd, lockd, quotad) and freed up the
> ports they are bound to, but the client still hangs when I try to mount
> the remote share.
[...]
> command that opens ports:
>  NFS="2049 32764 32765 32766 32767 32768 32772 sunrpc"
[...]
> Apr 24 16:53:35 tuxmac DROPl:IN=eth1 OUT= MAC=<mac here>
> SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00
> TTL=64 ID=41035 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN
> URGP=0

As far as I can see, your client is trying to connect to portmapper in
order to get NFS service port back. But there's nothing in your script
excerpt that opens TCP/111.

PS : maybe you should consider use the RPC helper available in
patch'o'matic extra section.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: NFS and iptables.

[John A. Sullivan III]

On Sat, 2004-04-24 at 19:12, Cedric Blancher wrote:
<snip>
> PS : maybe you should consider use the RPC helper available in
> patch'o'matic extra section.
I have always and recently found the RPC helper patch to be highly
unstable as much as I would really love to use it - John
-- 
Open Source Development Corporation
Financially Sustainable open source development
http://www.opensourcedevelopmentcorp.com

Re: NFS and iptables.

[Cedric Blancher]

Le dim 25/04/2004 à 01:40, John A. Sullivan III a écrit :
> I have always and recently found the RPC helper patch to be highly
> unstable as much as I would really love to use it - John

Good to know.
I didn't have to firewall RPC at the time, but who knows ?

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: NFS and iptables.

[Krunk]

sunrpc is port 111 as defined in /etc/services.

I'll try to explicitly set port 111.

No same result, same type of logs being show. Thanks for the suggestion
though.

On Sat, 2004-04-24 at 18:12, Cedric Blancher wrote:
> Le dim 25/04/2004 à 00:00, Krunk a écrit :
> > I've bound my NFS ports (moountd, statd, lockd, quotad) and freed up the
> > ports they are bound to, but the client still hangs when I try to mount
> > the remote share.
> [...]
> > command that opens ports:
> >  NFS="2049 32764 32765 32766 32767 32768 32772 sunrpc"
> [...]
> > Apr 24 16:53:35 tuxmac DROPl:IN=eth1 OUT= MAC=<mac here>
> > SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00
> > TTL=64 ID=41035 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN
> > URGP=0
> 
> As far as I can see, your client is trying to connect to portmapper in
> order to get NFS service port back. But there's nothing in your script
> excerpt that opens TCP/111.
> 
> PS : maybe you should consider use the RPC helper available in
> patch'o'matic extra section.

Re: NFS and iptables.

[Alistair Tonner]

On April 24, 2004 08:32 pm, Krunk wrote:
> sunrpc is port 111 as defined in /etc/services.
>
> I'll try to explicitly set port 111.
>
> No same result, same type of logs being show. Thanks for the suggestion
> though.
>
> On Sat, 2004-04-24 at 18:12, Cedric Blancher wrote:
> > Le dim 25/04/2004 à 00:00, Krunk a écrit :
> > > I've bound my NFS ports (moountd, statd, lockd, quotad) and freed up
> > > the ports they are bound to, but the client still hangs when I try to
> > > mount the remote share.
> >
> > [...]
> >
> > > command that opens ports:
> > >  NFS="2049 32764 32765 32766 32767 32768 32772 sunrpc"
> >
> > [...]
> >
> > > Apr 24 16:53:35 tuxmac DROPl:IN=eth1 OUT= MAC=<mac here>
> > > SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00
> > > TTL=64 ID=41035 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN
> > > URGP=0
> >
> > As far as I can see, your client is trying to connect to portmapper in
> > order to get NFS service port back. But there's nothing in your script
> > excerpt that opens TCP/111.
> >
> > PS : maybe you should consider use the RPC helper available in
> > patch'o'matic extra section.


	Silly question ... you are opening ports for state NEW ... I don't see an 
explicit rule for ESTABLISHED RELATED any where ... but I'm assuming that 
rule exists somewhere ...... else.

	Alistair Tonner 
	
	(sometimes the simplest answers.....)

Re: NFS and iptables.[FIXED]

[Krunk]

Fixed.

On Sat, 2004-04-24 at 19:32, Krunk wrote:
> sunrpc is port 111 as defined in /etc/services.
> 
> I'll try to explicitly set port 111.
> 
> No same result, same type of logs being show. Thanks for the suggestion
> though.
> 
> On Sat, 2004-04-24 at 18:12, Cedric Blancher wrote:
> > Le dim 25/04/2004 à 00:00, Krunk a écrit :
> > > I've bound my NFS ports (moountd, statd, lockd, quotad) and freed up the
> > > ports they are bound to, but the client still hangs when I try to mount
> > > the remote share.
> > [...]
> > > command that opens ports:
> > >  NFS="2049 32764 32765 32766 32767 32768 32772 sunrpc"
> > [...]
> > > Apr 24 16:53:35 tuxmac DROPl:IN=eth1 OUT= MAC=<mac here>
> > > SRC=192.168.xxx.xxx DST=192.168.xxx.xxx LEN=60 TOS=0x00 PREC=0x00
> > > TTL=64 ID=41035 DF PROTO=TCP SPT=896 DPT=111 WINDOW=5840 RES=0x00 SYN
> > > URGP=0
> > 
> > As far as I can see, your client is trying to connect to portmapper in
> > order to get NFS service port back. But there's nothing in your script
> > excerpt that opens TCP/111.
> > 
> > PS : maybe you should consider use the RPC helper available in
> > patch'o'matic extra section.
> 

nfs and iptables

[Ara.T.Howard]

after finally solving our client reboot lockd recovery issues (as per the nfs
faq and note about muti-homed clients needing statd hostname set : note to
self - rtfm) we are pushing this change out to all our nodes.  as it turns out
the firewall rules we had in place previously actually do allow lockd
recovery.  i am worried about other scenarios however; does the server need to
be able to initiate connections to the client, eg. does true bi-directional
coms need to be enabled?  our lock recovery seems to work without this but what else
might not?

in summary: we allow *any* incoming connection to our server(s) from clients
on the backdoor (nfs on backdoor only); do we need anything special on any of
the clients or is all communication initiated from the client?

kind regards.

-a
-- 
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs and iptables

[Trond Myklebust]

m=E5 den 07.02.2005 Klokka 22:44 (-0700) skreiv Ara.T.Howard:

> in summary: we allow *any* incoming connection to our server(s) from clie=
nts
> on the backdoor (nfs on backdoor only); do we need anything special on an=
y of
> the clients or is all communication initiated from the client?
>=20

As I told you before. Lock recovery assumes that rpc.statd on the server
can contact the clients after a server reboot. If you don't allow that,
then it is quite possible for the client not to notice that the server
has rebooted until after the grace period has expired.

IOW: lock recovery may indeed "work" without this, but you are leaving
yourself open to races that may crash your application and/or cause data
corruption.

Cheers,
  Trond
--=20
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: nfs and iptables

[Ara.T.Howard]

On Tue, 8 Feb 2005, Trond Myklebust wrote:

> As I told you before. Lock recovery assumes that rpc.statd on the server can
> contact the clients after a server reboot. If you don't allow that, then it
> is quite possible for the client not to notice that the server has rebooted
> until after the grace period has expired.

sorry - i was thinking you were talking about *client* reboots (our problem)
before.  of course this makes sense.

> IOW: lock recovery may indeed "work" without this, but you are leaving
> yourself open to races that may crash your application and/or cause data
> corruption.

as i thought - i just needed to be able to explain this to our sysads
thoroughly to justify holes in the firewall.

cheers.

-a
-- 
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs