- active: internal cache contains the flow that represents the SSH
connection.
- backup: external cache contains the flow that represents the SSH
connection.
I started from scratch a new PoC with two simple debian nodes and with
only three interfaces, which eventually let me do the drop policy.
Before, I could see the states being synced on the internal/external
cache. As far as I remember, I could see the states in the previous PoC
even if it was only doing NAT, without any filtering. Now it's even
worse. The backup node doesn't even see the states in its external
cache (both with FTFW/UDP and NOTRACK/UDP).
Are tracking rules in the filter table absolutely mandatory to make the
states known to conntrackd? I ask that because, conntrack -L can see
the local states without anything specific.
If so, does tracking rules initiated with nftables also work, or do I
have to use iptables instead?
If so, on which chains should I have absolutely have a drop policy
(input / forward / output)?
Is there a MWE with nftables rules somewhere that I could test?
By "inbound session", I guess you refer to the SSH connection you use
for testing, but is this a SSH connection to the guest VM? Is this
DNAT to the guest VM or simply routing?
Yes, I was talking about a connection from the outside to a guest system
behind DNAT. Same goes for the new PoC, it's just that the VRRP nodes
are now guest systems themselves. To simplify the PoC (and have way
less network interfaces, no bonding, no bridges, no vlans), I've put the
gateways as guest and they now have only three interfaces.
eth0 -- front-facing
eth1 -- internal network
eth2 -- cluster network for the sync
so I could afford using a drop policy without too much headache.
Such guess VM gets migrated to the active node and the active node
forwards traffic to the guest VM?
No, my experiments so far have nothing to do with guest migrations. I
was only testing that the SSH connection remains during VRRP fail-over.
There are other interesting use-cases where we could consider using
conntrack-tools which are specific to virtualization, but that's a whole
different story. And given the problems I face with the most KISS setup
even with this MWE new PoC, I guess I would use something else for that
purpose (NetBSD PF+PFSYNC+CARP just works out-of-the-box and is
active/active by default, which is what I need for that other use-case).
/proc/sys/net/netfilter/nf_conntrack_tcp_loose
Ok, that helps not to loose SSH the connection immediately, but still,
with the newer simple PoC I cannot even see the states replicated.
I also noticed this setting, is that required?
net.netfilter.nf_conntrack_helper = 0
It would be nice to have a fully working MWE tutorial available, to be
able to test the simplest active/passive setup. I will be glad to
document mine, if I finally manage to get it working.
