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:
smime.p7s
Description: S/MIME Cryptographic Signature
