Well, it looks like my expectations about the self-protection were wrong! I found in the system logs of the pfSense firewalls that it was flagging the checks from zabbix as an attack, and would periodically block all access from the zabbix server IP. I was able to whitelist that IP from the login protections, and I haven't seen any issues since. I still have no idea why this issue only manifested for the backup firewalls and not the master ones, seeing as their configurations are nearly identical, but hopefully this helps someone else in the future!

Hello Like said on documentation : pfsync Synchronize Peer IP If left blank, the firewall will send state data using multicast to all hosts on the chosen Synchronize Interface. In practice, state synchronization is more reliable when sent directly and not via multicast.

@empbilly said in Compatibility between VRRP and CARP: The vlans I have are in a lagg with 4 physical interfaces. Would this be a problem? No. In former pfSense versions the network ports for a (virtual) network interface have to be the same same on both nodes. E.g. the port for VLAN 305 has to be lagg0.305 on both. Configuring a lagg was a way to achieve this if the hardware was different. But as far as I know, this is not necessary anymore since FreeBSD 12. However, I configured it only this way. Do I need to have one network (10.10.10.0/24) or can it be one IP only (10.10.10.1) for each VIP in the vlans? You have to configure each IP and as well the VIP with the correct mask. I have the vlan ADM_LAN with the network 10.60.0.0/23 and GW 10.60.0.1 On pfsense backup can I put the GW 10.60.0.2? If you have 10.60.0.1 already configured as gateway on all your internal machines it might be easier to turn this into the CARP VIP and change the interface IP on the primary to anything other, maybe 10.60.0.2 and use 10.60.0.3 for the secondary. Another point is that we have an AD in our infrastructure, and the AD IP is the DNS in some vlans. How does this work with VIP? This has nothing to do with HA. It should work like before. Maybe I'm getting you wrong?

@viragomann Or put the pfblocker file on an inside network that both nodes have ready access to. Sync it to a reachable server or something.

@thale BTW: CARP IP on LAN interface works fine and no any issues. The packet loss issue is only happened on CARP IP on WAN interface.

@nikim Simply hit "Add new patch", enter a description like "CRL lifetime fix" and the patch ID below and save it. pfSense will pull and apply the patch then.

Thank you. I thought it is correct behavior, just wanted to confirm.

@william-mandell I'm guessing one is a WAN IP or other interface, since it's the same device? The traffic graphs use some level of smoothing so they are probably just being generated enough apart to appear different. Is there a second one? (you posted this in the HA subforum...)

@spunky_surveyor It appears that even if you specify listening_ip=eth0/24 in /var/etc/miniupnpd.conf it won't bind to the CARP VIP. As a result UPnP will work with some applications that don't mind the fact that the router IP advertises itself. But NAT-PMP and many others will fail because the VIP isn't getting picked up by the miniupnp daemon. This appears to be fixed in miniupnp upstream and is an old bug in PFSense due to an ancient historical lack of multicast support in CARP VIPs. A workaround for NAT-PMP is to create a NAT Port Forward for: CARP IP : UDP 5351 to Router IP : UPD 5351

Can anyone give some pointer on this?

@mrpete I also have a century link connection that runs on VLAN 201. I currently have the modem in bridge mode and have PFSense taking care of the log in. I am currently struggling with setting up the CARP properly on the boxes. Do you have a guide that I could follow?

@wifi75 Up until relatively recently pfSense needed the same hardware on both in order to sync states. However as of 22.01/2.6, that's no longer a requirement. So it should be possible to use any hardware. https://docs.netgate.com/pfsense/en/latest/highavailability/pfsync.html#pfsync-and-physical-interfaces

Well alllllrighty then haha. Thanks for the quick reply!

So from an old ticket: https://redmine.pfsense.org/issues/7010?tab=notes I'm confused why aliases on loopback interfaces would need a sync for HA cluster

I think there needs to be some work done e.a redesign of the whole xmlrpc process thing. I could easily see times that one firewall is broken and it takes weeks to perhaps months ( depending on supply of hardware vendor ) to get replaced and sycing can be moved back to original primary device. There should become an option to track changes on secondary device and have information tracking on primary device and as soon primary comes online there should become an option to sync the rules between devices. So basically what I am saying here is that a secondary node should have more involvement in this whole xmlrpc config process. Like there should also become an option when primary comes back online you can still keep the secondary running as the main firewall rule util you are sure the primary firewall is working correctly again. Just my 2 cents of thoughts.