All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Freyermuth <freyermuth@physik.uni-bonn.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter@vger.kernel.org
Subject: Re: Running an active/active firewall/router (xt_cluster?)
Date: Tue, 11 May 2021 11:28:23 +0200	[thread overview]
Message-ID: <6279603e-9db2-c519-7834-3217c809edd5@physik.uni-bonn.de> (raw)
In-Reply-To: <d05f4990-b3d3-52e6-ac22-ad55620b866a@physik.uni-bonn.de>

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

Hi Pablo,

a short additional question after considering this for a while longer:

Am 11.05.21 um 00:58 schrieb Oliver Freyermuth:
>>> [...]
>>> Basic tests show that this works as expected, but the details get messy.
>>>
>>> 1. Certainly, conntrackd is needed to synchronize connection states.
>>>     But is it always "fast enough"?  xt_cluster seems to match by the
>>>     src_ip of the original direction of the flow[0] (if I read the code
>>>     correctly), but what happens if the reply to an outgoing packet
>>>     arrives at both firewalls before state is synchronized?
>>
>> You can avoid this by setting DisableExternalCache to off. Then, in
>> case one of your firewall node goes off, update the cluster rules and
>> inject the entries (via keepalived, or your HA daemon of choice).
>>
>> Recommended configuration is DisableExternalCache off and properly
>> configure your HA daemon to assist conntrackd. Then, the conntrack
>> entries in the "external cache" of conntrackd are added to the kernel
>> when needed.
> 
> You caused a classic "facepalming" moment. Of course, that will solve (1)
> completely. My initial thinking when disabling the external cache
> was before I understood how xt_cluster works, and before I found that it uses the direction
> of the flow, and then it just escaped my mind.
> Thanks for clearing this up! :-)

Thinking about this, the conntrack synchronization requirements would essentially be "zero",
since after a flow is established, it stays on the same machine, and conntrackd synchronization is only relevant
on failover — right?
So this approach would not limit / reduce the achievable bandwidth, since the only ingredient are the mangling filters —
so in case we can't go for dynamic routing with Quagga and hardware router stacks, this could even be a solution
for high bandwidths?

Cheers and thanks,
	Oliver

-- 
Oliver Freyermuth
Universität Bonn
Physikalisches Institut, Raum 1.047
Nußallee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5432 bytes --]

  reply	other threads:[~2021-05-11  9:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-09 17:52 Running an active/active firewall/router (xt_cluster?) Oliver Freyermuth
2021-05-10 16:57 ` Paul Robert Marino
2021-05-10 21:55   ` Oliver Freyermuth
2021-05-10 22:55     ` Paul Robert Marino
2021-05-10 23:21       ` Oliver Freyermuth
     [not found]         ` <CAPJdpdDNmTq_yafDU12w1xz7PUTm4zZr6vt2nGciv=baGYwP1A@mail.gmail.com>
2021-05-11  9:08           ` Oliver Freyermuth
2021-05-10 22:19 ` Pablo Neira Ayuso
2021-05-10 22:58   ` Oliver Freyermuth
2021-05-11  9:28     ` Oliver Freyermuth [this message]
2021-05-11 12:24       ` Pablo Neira Ayuso
2021-05-11 21:37         ` Paul Robert Marino

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=6279603e-9db2-c519-7834-3217c809edd5@physik.uni-bonn.de \
    --to=freyermuth@physik.uni-bonn.de \
    --cc=netfilter@vger.kernel.org \
    --cc=pablo@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 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.