IPTables rejecting packets that should be let through???

[Aleksandar Milivojevic]

David Hoffman wrote:

> I left ethereal running overnight and caught several
> packets that were tripping this log event. Out of the 7 events that I
> caught, 6 of them showed [TCP ZeroWindow] and [INCORRECT CHECKSUM] in
> the packet info. There are other places where I would see the
> ZeroWindow message that did not trip the log, but there were no other
> places where I would see the INCORRECT CHECKSUM. The seventh entry
> that showed up in the log did not have an info line that matched
> either the ZeroWindow or Checksum message, but it was the last packet
> received from the host and the info simply stated:
> 4257 > smtp [RST] Seq=93 Ack=1545503494 Win=0 Len=0

My guess is that kernel is going to drop malformed packets (incorrect 
checksums for example) as soon as it detects them.  This might or might 
not be at the root of your problem.

> I think I understand what you mean about seeing an RST AFTER Postfix
> closes the connection. Maybe I should look at what Postfix sends when
> it closes the connection. If Postfix sends the RST, then should the
> other end send anything back at all? Maybe an ACK? Does Netfilter
> simply look for the first RST (from either side) and then consider it
> a closed connection?

The question here is, is Postfix closing the connection, or simply 
sending error code to the remote end, and than expecting remote end to 
close the connection.  One way to check this would be to do an netstat 
-an and grep for port number from log as soon as log entry is generated 
in logs.  This would show if kernel and postfix still consider 
connection being in ESTABLISHED state (not to be confused with 
Netfilter's ESTABLISHED state, two different and independent things).

Of course, tcpdump/ethereal logs would show this too.  If you are seeing 
this only from one host, and if that host is not generating a lot of 
traffic, try doing "tcpdump -i eth1 -s 0 -w hostname.dump host hostname" 
and let it run overnight.  Replace string "hostname" with remote host's 
name or IP address.  "-s 0" will catch and save entire packets, so you 
can completely reconstruct what is going on on the SMTP level too.  You 
can load hostname25.dump file into ethereal GUI later on to analyze it, 
or print it onto screen with tcpdump using "-r" option.  You can run 
this tcpdump on both your mail server and your NAT firewall external and 
internal interfaces (three tcpdumps) and see if there is any difference 
in packets captured (tcpdump listens on the wire, so if you see packet 
on NAT firewall's external interface, but not on internal interface, or 
vice versa, it means something ate it on that machine).

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7