FW: Ack/Fin packets dropped.
Fri, 24 Aug 2001 10:01:52 +0100
> The log you sent to the list - I think - is insufficient to find out
> what's going on.
> I can only repeat myself: a full tcpdump on the traffic could
> help best.
> Two tcpdumps would even be better: one with and one without netfilter
> sitting between the two endpoints.
I did get the tcpdump log as well, and I'll see if I can dig it out. However
I only got one with the filter running. But, unless you want to do somthing
clever with the HEX dump of the packet, it didn't say much more than the
netfilter log (i.e you would see the packets arrive on eth0/1 and the LOG
rule at the top of my forward chain would confirm this - then you would see
the packet leave on eth1/0 in the tcpdump log, or you wouldn't and there was
a corresponding DROP message in my netfilter log.) I haven't tried the same
thing without netfilter (and doing so would take time to setup as I wouldn't
wish to use my real firewall for this!)
Looking at it again, what is happening (at least in my case) is that one
side of the connection is being closed, but the other side isn't (until the
application opens a new connection, at which time it sends the FIN - which
can be more than a couple of minutes), and so in the meantime the connection
is timing out.
I've just had a brief look at the TCP RFC (793) and the state diagram they
show. It looks like the system is going into either FIN-WAIT-2 or the
CLOSE-WAIT states, but it is stopping here for some time. Netfilter only
allows a couple of minutes for these to timeout. However, *if* I understand
it, connections are allowed to be in these states for a while - where one
side will close, but can continue to receive untill the other side closes. I
confess that I am fairly new to this area, but this would seem to suggest
that the timeout values for these states should be increased. However
whether this is disirable from a security point of view I don't know - but
from the number of mails I have seen reporting similar problems it doesn't