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