john,
the most likely problem is that your rule of > block return-rst in log quick proto tcp all is the cause of the problem. it looks so innocent until a misordered packet comes along. and then bam! -- the connection gets reset. to fix this "problem", first refer to this link http://marc.theaimsgroup.com/?l=ipfilter&m=97234715121908&w=2 and my subsequent entry in phil's FAQ: http://home.earthlink.net/~jaymzh666/ipf/IPFprob.html#9 jim Darren Reed wrote: >In some email I received from Web server manager, sie wrote: > >>Looking at the ethernet traffic showed that in the problem cases, halfway >>through the transfer of an FTP directory listing from the FTP server to >>mirror on the web server, IP Filter was sending a RST on the data connection >>(passive FTP, so connection initiated by mirror on the web server system). >>mirror saw the resulting closed connection as end of directory listing, and >>concluded that files it had seen previously mirrored (which would have been >>in the remainder of the directory listing) had been deleted. I'd guess the >>actual file transfers may also have been affected, though if so it went >>unreported (like the temporary disappearance of groups of files from the web >>sites due to the directory listing problem...). >> >[...] > >For both of these cases, are you able to collect tcpdump output for a >session where you have packets from (2) that get blocked but really are >part of a connection that just was and (3) an connection where you see >the RST appear mid way through. > >For both cases, please use tcpdump as follows: > >tcpdump -s 1500 -i foo0 -w problem2.tcpdump host blah and host blah > >The "host blah ..." bit is the filter to only include the relevant >packets. The important requirement is that you send me the file >problem2.tcpdump rather than just the text output of tcpdump. > >Darren >
