On Thu, 2018-10-04 at 22:21 +0000, André Paulsberg-Csibi (IBM Consultant) wrote: > Hi , Hi, > As I cannot be sure of the reason you see this in your logs , but I > will assume that this happened because your session was IDLE for > longer then the TCP TIMEOUT for ESTABLISHED sessions That's not probable. The case I pasted below is IRC and the chance that conntrack's TCP timeout expires without a single message passing on an IRC link is pretty low. Additionally, I even see this much more frequently with SSL web traffic. As you know web traffic is generally very short-lived TCP connections. # cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established 7440 is much longer than typical HTTPS should be alive for. Let me ask... Is my original theory valid? Will conntrack throw away the idea of an ESTABLISHED session as soon as the last FIN passes the connection and if the host were to subsequently receive any straggling packets (i.e. held up in a router or something), would they get logged as I am seeing it or does conntrack suppress logging those for some period of time after the TCP session is closed with dual FIN and/or RST packets? Cheers, b.
Attachment:
signature.asc
Description: This is a digitally signed message part
