Hi *,
I will leave a small update here as I have found a working solution for
my needs of an active/standby firewall providing also SNAT for clients.
I've ended up with `net.ipv4.ip_nonlocal_bind=1` and a SNAT rule which
is active on booth firewalls, and using conntrackd with
```
Sync {
Mode FTFW {
DisableExternalCache on
}
```
to inject connection directly into the backup peer.
/* I have tested with the defaults from the source-directory but had no
luck with SNAT connections. The first failover worked /most/ of the
time, but a second failover mostly resulted in minutes of nothing, till
wget tried it again... I experimented with explicit flushing and
dropping of connections on the old master peer, but in the end
`DisableExternalCache on` seams to just work without any hassle or
tuning. */
Failover is handled with keepalived, but I assume that the default
failover script provided via the source directory, contains tasks which
are not needed when using FTFW with `DisableExternalCache on`?
Maybe my assumption is wrong, but
`-c` "commit the external cache into the kernel table" does nothing as
there is no external cache anymore.
Why `-f` "flush the internal and the external cache" exists I simple do
not know.
`-R` "resync"; see `-c`...
`-B` "send a bulk update to backups" still makes sense..
Is it correct that for FTFW with `DisableExternalCache on` the
transition to MASTER only needs `-f` and `-B`?
The transition to BACKUP using `-t` and `-n` would be left unchanged,
correct?
A (striped down) modified excerpt from
conntrack-tools-1.4.3/doc/sync/primary-backup.sh:
```
MASTER)
conntrackd -C "${CONNTRACKD_CONFIG}" -c
conntrackd -C "${CONNTRACKD_CONFIG}" -f
conntrackd -C "${CONNTRACKD_CONFIG}" -R
conntrackd -C "${CONNTRACKD_CONFIG}" -B
;;
BACKUP)
conntrackd -C "${CONNTRACKD_CONFIG}" -t
conntrackd -C "${CONNTRACKD_CONFIG}" -n
;;
```
I don't know the reason for it or if it is even an issue; on ~300K
connections created over ~24h I see ~ 700 failed. But did not get any
complains from users on this test-network. I have tested/performed
multiple failover, over hours to provoke "issues".
Thanks again,
Bernd
