Hi Florian , Thank you for the answer , it was helpful even if it was not the cause of this issue : Apr 15 20:25:31 FW-IN-DROP-TCP IN=eth0 OUT= SRC=178.57.222.100 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=3897 PROTO=TCP SPT=25081 DPT=47278 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 15 20:31:24 FW-IN-DROP-TCP IN=eth0 OUT= SRC=178.57.222.100 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=50634 PROTO=TCP SPT=25081 DPT=51929 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 18 22:46:34 FW-IN-DROP-TCP IN=eth0 OUT= SRC=212.224.121.150 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=45792 PROTO=TCP SPT=25565 DPT=45463 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 18 22:56:44 FW-IN-DROP-TCP IN=eth0 OUT= SRC=212.224.121.150 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=41802 PROTO=TCP SPT=25577 DPT=49359 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 18 23:27:56 FW-IN-DROP-TCP IN=eth0 OUT= SRC=212.224.121.150 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=44249 PROTO=TCP SPT=25577 DPT=42601 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 19 02:21:32 FW-IN-DROP-TCP IN=eth0 OUT= SRC=212.224.121.150 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=36855 PROTO=TCP SPT=25577 DPT=50413 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 19 22:46:57 FW-IN-DROP-TCP IN=eth0 OUT= SRC=79.133.37.3 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=55848 PROTO=TCP SPT=25565 DPT=43052 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 19 22:59:45 FW-IN-DROP-TCP IN=eth0 OUT= SRC=79.133.37.3 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=26180 PROTO=TCP SPT=25565 DPT=40630 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 19 23:17:54 FW-IN-DROP-TCP IN=eth0 OUT= SRC=79.133.37.3 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=114 PROTO=TCP SPT=25565 DPT=44993 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 19 23:19:10 FW-IN-DROP-TCP IN=eth0 OUT= SRC=79.133.37.3 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=18161 PROTO=TCP SPT=25565 DPT=48617 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 25 13:26:42 FW-IN-DROP-TCP IN=eth0 OUT= SRC=166.176.57.49 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=27527 PROTO=TCP SPT=3074 DPT=43321 WINDOW=16384 RES=0x00 ACK URGP=0 Apr 26 11:06:45 FW-IN-DROP-TCP IN=eth0 OUT= SRC=122.117.167.243 DST=AA.BB.CC.DD LEN=552 TOS=0x00 PREC=0x00 TTL=53 ID=61084 PROTO=TCP SPT=4025 DPT=50674 WINDOW=36897 RES=0x00 ACK URGP=0 May 01 09:40:52 FW-IN-DROP-TCP IN=eth0 OUT= SRC=220.132.126.157 DST=AA.BB.CC.DD LEN=552 TOS=0x00 PREC=0x00 TTL=52 ID=32904 PROTO=TCP SPT=23085 DPT=10580 WINDOW=61079 RES=0x00 ACK URGP=0 May 07 10:36:19 FW-IN-DROP-TCP IN=eth0 OUT= SRC=220.132.175.144 DST=AA.BB.CC.DD LEN=552 TOS=0x00 PREC=0x00 TTL=52 ID=28464 PROTO=TCP SPT=52914 DPT=35349 WINDOW=6463 RES=0x00 ACK URGP=0 May 08 05:08:22 FW-IN-DROP-TCP IN=eth0 OUT= SRC=208.66.239.10 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=28274 PROTO=TCP SPT=1935 DPT=32433 WINDOW=16384 RES=0x00 ACK URGP=0 May 08 05:13:06 FW-IN-DROP-TCP IN=eth0 OUT= SRC=208.66.239.10 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=45061 PROTO=TCP SPT=1935 DPT=32433 WINDOW=16384 RES=0x00 ACK URGP=0 May 09 06:16:07 FW-IN-DROP-TCP IN=eth0 OUT= SRC=185.144.88.99 DST=AA.BB.CC.DD LEN=44 TOS=0x00 PREC=0x00 TTL=55 ID=52446 DF PROTO=TCP SPT=1935 DPT=32433 WINDOW=1400 RES=0x00 ACK URGP=0 OPT (02040200) May 09 06:21:27 FW-IN-DROP-TCP IN=eth0 OUT= SRC=185.144.88.99 DST=AA.BB.CC.DD LEN=44 TOS=0x00 PREC=0x00 TTL=55 ID=52446 DF PROTO=TCP SPT=1935 DPT=32433 WINDOW=1400 RES=0x00 ACK URGP=0 OPT (02040200) srv001:~ # more /proc/sys/net/netfilter/nf_conntrack_tcp_loose 0 As shown in the last 2 entries , I got 2 new entries in the log even after setting "nf_conntrack_tcp_loose = 0" So if you or any other have any insight as to why this behavior is happening please give suggestions ... However as I said it was still helpful as at least now the FW will only allow "active sessions listed in conntrack" Best regards André Paulsberg-Csibi Senior Network Engineer IBM Services AS Sensitivity: Internal -----Opprinnelig melding----- Fra: Florian Westphal <fw@xxxxxxxxx> Sendt: onsdag 9. mai 2018 07.00 Til: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx> Kopi: 'netfilter@xxxxxxxxxxxxxxx' <netfilter@xxxxxxxxxxxxxxx> Emne: Re: iptables / conntrack - state engine question André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx> wrote: > I have LOG&DROP option rule for both states INVALID and NEW using the "ctstate" function , rule 19/20 and 22/23 . > However as the log shows over time (at bottom) I sometimes have packets LOG&DROP for the "ctstate NEW" that I suspect should not be matched there . > > I am assuming it is either a bug or a "feature" , so my question is > simply if this is "normal" or if this is something that may happen by > "fault" , and what is the "cause" of it and can it be "fixed" in the > state engine itself ( not with rules checking for SYN bit and such ) ( > as far as I understand the basis of a FireWall state engine , a TCP > packet should never have NEW STATE unless the SYN bit is set ) Depends on net.netfilter.nf_conntrack_tcp_loose setting. If 1, it will also pick up connections mid-stream. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
