On Wed, Apr 20, 2011 at 4:22 AM, David Gwynne <l...@animata.net> wrote: > you might be able to upgrade your passive firewall to 4.9 next to the active > 4.7 one. it looks like the protocol stayed the same so they should be able to > talk to each other.
This would seem to be the case. This (http://undeadly.org/cgi?action=article&sid=20090301211402) is an absolutely excellent bit of writing about the improvements to pfsync, BTW. Thanks for letting that be shared. > however, it looks like bulk updates were broken in 4.7, which would explain > your failover problems. you can work around that by going "pfctl -S > /dev/stdout | ssh activefw pfctl -L /dev/stdin" as root on the passive fw. As an initial seeding of state? It seems to me that only some of my flows get affected when failing over (not everything is reset and traffic can still flow). It appears that both firewalls have an approximately congruent set of states, but usually a "pfctl -ss | wc -l" can be off by several hundred, to several thousand states at times. My hunch is that state creation and counter updates are not updated synchronously, so when failing over there are still some updates in-flight, and for flows that are moving their sequence numbers at a decent clip I could see why they might get reset. Have you ever used pfsync with the "defer" option set? I can imagine that it just takes longer for sessions to start since each firewall would have to wait for the insertion of the state on the other firewall, but I wonder how much latency that adds in practice. Another open question would be what to do in the case of multiple firewalls receiving the multicast update (not applicable for me, but something I'm considering trying). I wonder if there ought to be a hook for defer to count the number of related received state insertion messages it gets before starting. > as a matter of interest, are you using ospf for failover on one side of your > firewalls? I'm hooking CARP interfaces up into ospfd to signal to my IGP which firewall is active at a given time. ospfd seems to have hooks into CARP which will change LSA metrics based on the CARP state. For the interfaces that these firewalls are announcing into the IGP, CARP is used to direct upstream traffic at the active router. Cheers, jof
