Re: conntrack and RSTs received during CLOSE_WAIT

[Robert L Mathews <lists@tigertech.com>]

Jozsef Kadlecsik wrote:

> The TCP session seems to be totally broken. After the client sends
> 
> client > server [FIN,ACK] Seq=421 Ack=1449 Len=0
> 
> it should send the RST packet with Seq=422 and not Seq=421. The RST 
> segment won't be accepted by the server.

Okay. The client is definitely sending exactly that (I'm pretty sure 
it's a SonicWall firewall). That explains why the connection stays in 
the CLOSE_WAIT state according to netstat.

So the problem can be described as:

Some buggy clients send an out-of-sequence RST. When that happens, 
conntrack forgets about the connection ten seconds later, even though 
the TCP stack doesn't.

If nf_conntrack_tcp_loose is set to 0, this gives clients a trivial way 
to bypass connlimit, because the client then has open connections that 
aren't counted.

If nf_conntrack_tcp_loose is set to 1, subsequent packets sent more than 
ten seconds later will result in conntrack seeing a new ESTABLISHED 
connection. Unfortunately, if the subsequent packets were merely TCP 
retransmits (which is likely), the "new connection" will not really 
exist. Connlimit counts a nonexistent connection as being open for five 
days until it times out.

Both of these outcomes are obviously undesirable. Any suggestions how to 
avoid this, or to minimize the impact?


> And I don't get the server either: after sending Ack=422 it can't send 
> Ack=421.
> 
> Is it a real TCP session recording or a mistyped one?

You're right; that was a typo on my part, for which I apologize. I had 
to retype it from Wireshark, and I copied the wrong line. The ten 
retransmitted packets at the end do indeed send Ack=422, just as you say 
they should.

(However, the client problem is not a typo. The client definitely did 
send Seq=421 in the RST, which explains why netstat shows the connection 
remaining in CLOSE_WAIT and why the server continues to retransmit packets.)

-- 
Robert L Mathews, Tiger Technologies     http://www.tigertech.net/