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 17:09:50 +0100 [thread overview]
Message-ID: <200406241709.50795.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <1088092124.2029.28.camel@grendel>
On Thursday 24 June 2004 4:48 pm, Chris Brenton wrote:
> On Thu, 2004-06-24 at 09:54, Antony Stone wrote:
> > > > 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".
>
> I *think* this may be the point of confusion. A FIN/ACK only means that
> the _sender_ is done transmitting data.
Agreed.
> So just because one side of the connection issues a FIN/ACK, it does not
> mean the session is over. The other side of the session may have a lot
> more data to transmit so the session can stay active for some additional
> period of time. Here in lies out problem. Netfilter is reacting to the
> first FIN/ACK and killing off the session before the other end finishes
> communicating and issues it's own FIN/ACK.
In my experience (with things like SMTP, HTTP) it appears to be the server
which generally issues the (first) FIN/ACK, telling the client that there's
no more data (by which time the client has finished anyway, since it issued
the request and was just waiting for the response to come back). It seems
not to be often that the client sends a FIN/ACK once it's finished sending
the request, knowing that there's plenty of data to come in a reply (if there
were, I think netfilter would have been changed quite some time ago).
I wonder how other stateful firewalls (eg: CP FW-1?) handle this sort of thing
- do they listen for *both* FIN/ACKs (and thereby leave themselves prey to
half-open connections littering their connection table for systems which
don't bother to send the responding FIN/ACK)?
Regards,
Antony.
--
There's no such thing as bad weather - only the wrong clothes.
- Billy Connolly
Please reply to the list;
please don't CC me.
next prev parent reply other threads:[~2004-06-24 16:09 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
2004-06-24 15:48 ` Chris Brenton
2004-06-24 16:09 ` Antony Stone [this message]
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=200406241709.50795.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