NFS/Firewall problem

Jeremy Stoltz jstoltz at nw-media.com
Mon Aug 26 14:00:01 CDT 2002


I found this a few minutes after sending the message which answers my
question:

When a host wants to send UDP packets that are larger than the network's
maximum transfer unit, or MTU, it must fragment them. Linux fragments
large UDP packets into MTU-sized IP fragments and sends them to the
receiving host in reverse order; that is, the fragment that contains the
bytes with the highest offset are sent first. Because Linux sends IP
fragments in reverse order, its NFS client may not interoperate with
some firewalls. Certain modern firewalls examine the first fragment in a
packet to determine whether to pass the rest of the fragments. If the
fragments arrive in reverse order, the firewall discards the whole
packet. A possible workaround is to use only NFS over TCP when crossing
such firewalls, or to use small rsize and wsize (1024) to prevent
fragmentation of UDP requests. If you find some client requests work
normally while others cause the client to stop responding, try reducing
your rsize and wsize to 1024 to see if there are fragmentation problems
preventing large requests from succeeding. 

Since the host is sending the packets in reverse order the firewall is
blocking the request. Oh well, guess I'll talk to the firewall vender
about this. 

Thanks,
Jeremy

-----Original Message-----
From: linux-poweredge-admin at dell.com
[mailto:linux-poweredge-admin at dell.com] On Behalf Of Jeremy Stoltz
Sent: Monday, August 26, 2002 11:28 AM
To: Dell-Linux
Subject: NFS/Firewall problem


I'm having some problems getting NFS to work through a netscreen 5200
firewall. I'm using Redhat 7.3 for both the client and server. I can
mount however I can't copy or create any files over a few bytes. 

Here is the messages that I am seeing in our debug:

ethernet1/1:10.1.3.226/2049->10.12.12.10/800,17
  find matched sess
  core pak
  flow_ip_send: 10.1.3.226->10.12.12.10 => ethernet1/2
  mac 0003479601ea in session
  Send to ethernet1/2 (202)
03228.0: 9(i):0003479601ea->0010db19b589/0800


  rcv non-first-frag UDP pak
  frag session (id 39632) found.
  npak queued
  packet dropped, first session packet can not be frag

03231.0: 9(i):0003479601ea->0010db19b589/0800
              10.12.12.10->10.1.3.226/17, tlen=1500
              vhl=45, id=39632, frag=6000, ttl=64
              ports 800->2049, len=4260

Kind if cryptic I know. things to note are the session id ( 39632 for
this flow ), and the message: "packet dropped, first session packet can
not be frag"

I guess what I do not understand is why the application seems to NOT be
sending the first packet first, as opposed to sending a packet that is a
fragment. Upon seeing this packet as the first for this session, we are
seeing it as an illegal setup message and does not follow our stateful
setup rules for UDP sessions setup.

Any ideas how I can work around this?

Thanks,
Jeremy


_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq or search the list
archives at http://lists.us.dell.com/htdig/





More information about the Linux-PowerEdge mailing list