In some email I received from Web server manager, sie wrote: [...] > For example, the log entries for yesterday show 0.1% of HTTP connections to > the web server logged blocked RST packets and 0.6% blocked ACK packets (some > but only a minority ACK with FIN or ACK with PUSH). Is that typical and > reasonable for web traffic through IP Filter, or should we be worrying about > it? [...] > (3) [This is the "big" problem] > > The web server uses the "mirror" FTP mirroring script from > http://sunsite.org.uk/packages/mirror/ to copy some of the web content from > a local FTP server. As noted above, NAT is not involved - IP Filter is just > protecting the individual servers - and the FTP connections would be from > the web server's canonical address to the FTP server. > > Our IP Filter configuration allows all outbound traffic, with saved state > for SYN packets, which we expect to allow back in the corresponding response > packest. We therefore expected changing mirror's configuration to use passive > FTP (previously used active) to "just work". [...] > 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
