Re: ACK,RST getting dropped in the firewall.

[Chris Brenton <cbrenton@chrisbrenton.org>]

On Thu, 2004-06-24 at 09:54, Antony Stone wrote:
>
> > > No harm done though, because the first one has done the job.
> >
> > Actually not quite true as both sides will enter a fin-wait state (RFC
> > 793 page 20) till the second FIN/ACK-ACK exchange takes place.
> 
> Depends what you mean by "done the job".   I meant the phrase in the sense of 
> "no more data is going to pass across the connection".

I *think* this may be the point of confusion. A FIN/ACK only means that
the _sender_ is done transmitting data, To quote from 793:

"The user who CLOSEs may continue to RECEIVE until he is told that the
other side has CLOSED also.  Thus, a program could initiate several
SENDs followed by a CLOSE, and then continue to RECEIVE until signaled
that a RECEIVE failed because the other side has CLOSED."

So just because one side of the connection issues a FIN/ACK, it does not
mean the session is over. The other side of the session may have a lot
more data to transmit so the session can stay active for some additional
period of time. Here in lies out problem. Netfilter is reacting to the
first FIN/ACK and killing off the session before the other end finishes
communicating and issues it's own FIN/ACK. 

The problem *appears to be* (based on my limited testing) in how the
timer is implemented. In an ESTABLISHED state there is a 5 day timer
that gets reset when ever a new packet crosses the firewall. The FIN/ACK
timer seems to be an absolute timer that kicks off at the first FIN/ACK
and continues to count down regardless of whether the session is still
active or not. If it acted more like the ESTABLISHED timer, this problem
would go away.

I can understand wanting a low timer to conserve resources. At the same
time however its killing legitimate RFC compliant sessions. :(

HTH,
Chris