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