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



  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