From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksander Subject: Re: state new with SYN not set Date: Mon, 13 Feb 2006 16:17:51 +0200 Message-ID: <43F0950F.4060304@krediidiinfo.ee> References: <43F050AA.3050602@krediidiinfo.ee> <80d7e4090602130454l41a7eb03pef73e7f49ef21916@mail.gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <80d7e4090602130454l41a7eb03pef73e7f49ef21916@mail.gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii"; format="flowed" To: netfilter@lists.netfilter.org Stephen J. Smoogen wrote: >Many times this is because of late packets getting to your server. It >might be because the server has finished the session (it saw a FIN or >RST on its side) and so has closed down the session.. or it might be >that the client didn't get the servers RST/FIN and is sending a second >ACK/PSH/FIN to make sure the session is closed. > >There are probably other reasons for this, but this has been my >biggest number. There are some probe tools that just send ACK-PSH-FIN >packets to see what they get back from firewalls. > > > >-- >Stephen J Smoogen. >CSIRT/Linux System Administrator > Thanks for the explanation! I got another one: Feb 13 15:39:10 myyr kernel: BAD PACKET syn+ack: IN=eth0 OUT=eth1 SRC=192.168.111.34 DST=1.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=4081 WINDOW=5840 RES=0x00 ACK SYN URGP=0 From my web server to a client, matched from: ${IPTABLES} -t filter -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP I guess this can be ignored as well, it's just that it's originating from my web server on the LAN. I can't imagine any packets being caught by the firewall but then being lost on the way to the webserver. It's a decent 100Mbit link with only one switch on the way. There's not much network load either. Alex