Not sure if this is the only thing causing a problem for you, but it
appears your experiencing a problem I discovered a couple weeks ago.

First of all, there is a bug in NetBSD that causes it to not obey the TCP
MSS properly, which results in packets from a NetBSD machine (specifically
ftp.netbsd.org and www.netbsd.org) getting fragmented even when you are
making an effort to prevent that (i.e. TCP MSS clamping, or using a lower
mtu on your clients).  It's been fixed in -current, but ftp.netbsd.org
and www.netbsd.org are still broken (see kern/14799).

Fragmentation by itself isn't a big problem (just undesireable).  However,
NetBSD's IPNAT appears to have a bug that prevents fragmented FTP data
from being natted properly.  This is probably due to the fact that
ipfilter is horribly out of date in NetBSD (-current uses a 1 year old
ipfilter, 1.5.x has an ipfilter from about 16 months ago).

I worked around the problem by removing the "proxy ftp" entry from my
ipnat.conf.  It's used only for "active mode ftp" which requires special
handling because the ftp server establishes an inbound data connection to
the client.  Instead of trying to get active ftp to work (which most
people consider to be broken anyway), I allways use "passive ftp".  In
assive ftp the client initiates the data connection to the server, so
ipnat doesn't have to do anything special.  Almost all FTP servers support
passive FTP and many clients (including NetBSD) now default to passive
ftp, and almost all support it (MS command line ftp is an exception I
believe).

Anyway, once you remove the special handling for ftp packets (and use only
passive ftp), ipnat should forward the fragments again properly.  Or
atleast that was my experience with IP Filter 3.4.16 (-current).  I seem
to recall even more problems with fragments under older version of
ipfilter, but I'm not sure if that still affects NetBSD-1.5

Hope this helps,
	Rick

On Thu, 6 Dec 2001, Manuel Bouyer wrote:

> Date: Thu, 6 Dec 2001 17:01:02 +0100
> From: Manuel Bouyer <bouyer@antioche.lip6.fr>
> To: Richard Rauch <rauch@rice.edu>
> Cc: Frederick Bruckman <fredb@immanent.net>, netbsd-help@netbsd.org
> Subject: Re: Network proxies; NAT
>
> On Thu, Dec 06, 2001 at 06:41:58AM -0600, Richard Rauch wrote:
> > >From watching tcpdump on both machines (hermes running ftp, and prometheus
> > running ipnat/ipf), it appears that the ftp server is trying to send some
> > kind of further message, but it never makes it to the client.
> >
> > E.g.:
> >
> > 06:14:11.832050 ftp.netbsd.org.ftp >
> >  adsl-65-66-216-178.dsl.hstntx.swbell.net.65302: . ack 38 win 33580
> >  <nop,nop,timestamp 2012901 29433> [tos 0x10]
> > 06:14:15.207638 ftp.netbsd.org.ftp >
> >  adsl-65-66-216-178.dsl.hstntx.swbell.net.65302: . 117:1077(960) ack 38
> >  win  33580 <nop,nop,timestamp 2012907 29433> (frag 35209:992@0+) [tos
> >  0x10]
> > 06:14:15.210749 ftp.netbsd.org > adsl-65-66-216-178.dsl.hstntx.swbell.net:
> >  (frag 35209:488@992) [tos 0x10]
> >
> >
> > ...is it significant that the incoming message is (as I understand it)
> > being put on port 65302?  ipnat is only mapping 40000:60000 to hermes.
> > Those 65302 messages don't seem to make it to the ftp client.
>
> It's not a problem with the port number. however it could be a problen with
> fragments. Are you sure you don't block fragments in IPF ?
>
> --
> Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
> --
>