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.
next prev 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