Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Antony Stone <Antony@Soft-Solutions.co.uk>
To: netfilter <netfilter@lists.netfilter.org>
Subject: Re: ACK,RST getting dropped in the firewall.
Date: Thu, 24 Jun 2004 14:54:28 +0100	[thread overview]
Message-ID: <200406241454.28088.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <1088084177.2029.8.camel@grendel>

On Thursday 24 June 2004 2:36 pm, Chris Brenton wrote:

> On Thu, 2004-06-24 at 06:44, Antony Stone wrote:
> > The other thing you see logged quite often for similar reasons is FIN-ACK
> > packets - the reply FIN-ACK is regarded as optional by many systems, so
> > netfilter often ends up logging (and dropping) the second one to come
> > along.
>
> IMHO this is completely non-RFC. It is clearly defined (RFC 793 page 22)
> that both sides must issue a FIN/ACK and receive an ACK before the
> connection is closed.

Oh, I agree it's RFC incompliant.   I didn't say it was official behaviour - 
just something you see happening :(

> What OS does not issue the reciprocating FIN/ACK?

Don't know off the top of my head - will let you know if I can find out.

> > No harm done though, because the first one has done the job.
>
> Actually not quite true as both sides will enter a fin-wait state (RFC
> 793 page 20) till the second FIN/ACK-ACK exchange takes place.

Depends what you mean by "done the job".   I meant the phrase in the sense of 
"no more data is going to pass across the connection".

> This chews up a session on both ends till their timers expire. Add up enough
> of them and it can kill a busy server (seen it happen and have had to
> stop state tracking to fix it).

Indeed.   Not necessarily as bad as a SYN flood attack, but similar in nature 
and consequences.

> Also, if you check the log entry that was posted:
> > Jun 23 16:42:43 javagreen kernel: New not syn:IN=eth0 OUT=
> > MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=202.138.101.5
> > DST=202.138.22.218 LEN=1500 TOS=0x00 PREC=0x00 TTL=122 ID=51601 DF
> > PROTO=TCP SPT=80 DPT=2162 WINDOW=64574 RES=0x00 ACK URGP=0
>
> Its a 1500 byte ACK packet. So iptables is not just blocking the FIN/ACK
> exchange, it can sometimes end up blocking data transfer as well. :(

Oh - I didn't see that posting - I was replying to a question apparently about 
RST-ACK packets getting logged (and dropped).

Dropping a normal ACK packet is another matter altogether, and clearly a Bad 
Thing (or at least, Highly Undesirable).

Regards,

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                     Please reply to the list;
                                                           please don't CC me.



  parent reply	other threads:[~2004-06-24 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 11:06 ACK,RST getting dropped in the firewall Manikandan
2004-06-23 11:32 ` Chris Brenton
2004-06-24  9:37   ` Gavin Hamill
2004-06-24 10:44     ` Antony Stone
2004-06-24 13:36       ` Chris Brenton
2004-06-24 13:52         ` Jozsef Kadlecsik
2004-06-24 13:54         ` Antony Stone [this message]
2004-06-24 15:48           ` Chris Brenton
2004-06-24 16:09             ` Antony Stone
2004-06-24 18:29               ` Chris Brenton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200406241454.28088.Antony@Soft-Solutions.co.uk \
    --to=antony@soft-solutions.co.uk \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox