I've had a pair of redundant firewalls using pfsync for years. I've noticed in the past that whenever I rebooted the secondary firewall, the carp interfaces on the primary would flip to backup and then back to master as the secondary one rebooted. I never really noticed any issues with it, so I just ignored it.

Since upgrading to 6.7 though, if I have an active ssh connection to the carp IP address on the primary when I reboot the secondary and these interface flip-flops occur, my connection is dropped, which is undesirable.

It looks like this is happening because by default the pfsync interface is in the carp group, so when it goes down, it demotes all of the carp interfaces on the system. I can see why this would be useful for a setup using multicast and more than two firewalls, as if you are not synchronizing states, you are probably not the best choice to be the active owner of the virtual IP addresses.

However, for only two firewalls, when you're using the syncpeer directive for the pfsync interface, it seems it would be better not to default to belonging to the carp group? With only two firewalls, if one of them has broken synchronization, so does the other, so is there any real point in trying to migrate away from the one that's currently master?

I updated my configuration to remove the pfsync interface from the carp group and now when I reboot there are no issues with the carp interfaces changing state or connections being dropped. Would it make sense to not automatically include the pfsync interface in the carp group if it is using the syncpeer directive?

Thanks…

Reply via email to