All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Marco <listaddr@gmail.com>
Cc: netfilter@vger.kernel.org
Subject: Re: conntrackd questions
Date: Thu, 21 Feb 2013 19:37:11 +0100	[thread overview]
Message-ID: <20130221183711.GA6061@localhost> (raw)
In-Reply-To: <CAHPDOiFpF2+F8CTJ_fF26bXaCtTCUMDPV8JtZT-HX+m2u1j3AA@mail.gmail.com>

Hi Marco,

On Thu, Feb 21, 2013 at 01:23:30PM +0100, Marco wrote:
> 2013/2/19 Pablo Neira Ayuso <pablo@netfilter.org>:
> 
> > There are several things that you can check to troubleshoot
> > conntrackd:
> 
> Ok, I think I see what's happening. To understand, I captured traffic
> both on the client, and on the upstream router (upstream to fw1 and
> fw2).
> On the client, I just see that when wget stops downloading, the
> traffic stops in the middle of the TCP flow. The client is just
> waiting for the server to send more data.
> 
> But on the capture taken on the upstream router, I see that, at the
> point when the client hangs, there are many RST packets directed to
> the website from which the client was downloading. Obviously, this
> resets the connection and the client has a hard time waiting for more
> data. I suspect these RST are coming from one of the firewalls. For
> example, while there is a failover from fw1 to fw2, but fw2 hasn't
> synchronized the full conntrack table yet, data comes back from the
> website; fw2 doesn't know anything about it yet, so it sends RSTs.

Thanks, that's a much more accurate report, I can help you better with
that.

> Could a race like this be possible? I can probably live with that, but
> I'd like to understand if my analysis is correct.
> If I disable external cache, it still happens, although less frequently.

The firewall sends an RST if it finds no state information / the
traffic is considered to be invalid by the TCP tracking code.

In your previous config, assuming you use a 3.x kernel, I saw you did
not enabled TCPWindowTracking On. That allows the new primary to
recover TCP window tracking from the middle.

Another possibility is to disable disable TCP tracking.

echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal

I think they are documented in the official docs, let me know if not.

It's also good to have a "sane" stateful rule-set, ie. one that drops
invalid traffic, see the rule-set in:

http://conntrack-tools.netfilter.org/testcase.html

for instance.

Regards.

  reply	other threads:[~2013-02-21 18:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-19 14:18 conntrackd questions Marco
2013-02-19 19:52 ` Pablo Neira Ayuso
2013-02-21 10:14   ` Marco
2013-02-21 12:23   ` Marco
2013-02-21 18:37     ` Pablo Neira Ayuso [this message]
2013-02-22 10:12       ` Marco
2013-02-25 15:45         ` Pablo Neira Ayuso
2013-03-06 10:54           ` Marco

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=20130221183711.GA6061@localhost \
    --to=pablo@netfilter.org \
    --cc=listaddr@gmail.com \
    --cc=netfilter@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.