HI , Just so that you we agree here , if you are not sure what these packets are it is better to troubleshoot to better understand the underlying reason . IF not my suggested will always be based on assumptions and may very well be "bad advice" for this scenario . I will list the reason I find likely based on you new criteria as listed : When you get PSH ACK packet from a SERVICE like IRC , that is typically caused by 4 different scenarios ( there are others ) 1. Your client recently abruptly closed ( RST ) the session , and the SERVICE had not received the RST prior to sending your client new session data 2. Your client closed the session with 4 way FIN , but the service side for some reason did not acknowledge the closing prior to sending additional session data . 3. Some other unit on the path sent ( RST ) for the traffic , causing a similar result as #1 4. The traffic is not related to your active session , and might also be from an unknown 3. party There are two ways that may help to investigate and find out if this or other "things" cause this issue ( command could need re-write ): conntrack -E | grep 4.24.10.6 and/or tcpdump -s0 -vvnni eth0.2 host 4.24.10.6 Results of this investigation might help suggest both the cause and a good way to fix it . Best regards André Paulsberg-Csibi Senior Network Engineer IBM Services AS Sensitivity: Internal -----Opprinnelig melding----- Fra: Brian J. Murrell <brian@xxxxxxxxxxxxxxx> Sendt: fredag 5. oktober 2018 13.57 Til: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx>; netfilter@xxxxxxxxxxxxxxx Emne: Re: SV: "straggler" packets being logged 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.
