That's how you sync states.

So, the box that sits at 192.168.2.1 (master) should have 192.168.2.2 (slave) entered into 'pfsync Synchronize Peer IP'  and 192.168.2.2 should have 192.168.2.1 entered into this box then? And, in 'Synchronize Config to IP'under 'Configuration Synchronization Settings (XMLRPC Sync)', 192.168.2.2 should be entered on the master box, with nothing entered on the slave. I'll do that next time I'm on-Site (as the remote VPN doesn't like 192.168.x.x and just lets me to the shared address of 10.64.0.1 Many thanks.

Did you ever find an answer for this? I have the same thing happening.

Your config is unusual, and technically incorrect probably with the /128 IPs on the interfaces. I believe if you put an IP within the /64 of the CARP VIP on each interface instead of that /128, it will likely work fine.

Hi, Jim! I'm not having any VHID conflict so far. I'm gonna need create a virtual lab to reproduce the issue but I'm kinda busy right now. I'll let you know in a few days. Thank you anyway!

There is no simple way to retain changes made to the secondary. If you try to sync them back to the primary later, other things may break unless you're careful (e.g. fix CARP VIP skews, DHCP failover IP addresses, etc) If you know the primary node will be gone for quite some time, just grab a backup off both units, power it off, restore the primary backup file to the secondary, and now you just took your "secondary (formerly known as the primary)" is down for maintenance. :-) When the time comes to switch back, you could either restore the secondary node config to the repaired unit or swap them back around.

I recall this question, cause I thought my setup didn't work because of a faulty router advertisment setup. I figured it was not faulty at all. The flaw was in the CARP setup. There are dedicated HA interfaces on each CARP member, configured with an IPv6 ULA and physically connected directly to each other. This doesn't seem to work. As far as I'm concerned I strongly suggest NOT to use ULA for High Availability sync. https://redmine.pfsense.org/issues/4648

Hello Dotdash, Now Its working very well without IP conflict! CARP is the best!!! Thank you so much! Hugs, Cesar

Another important point to check when using DHCP failover which can have an impact on the recover/normal mode is the adskew advertisement. As mentionned on the GUI: Ensure one machine's advskew<20 (and the other is >20). On th virtual CARP IP I would check if the primary firewall respect this. I previsouly had issues with the DHCP service going into recover mode because of this, since I set all the CARP on the primary node to skew 0 everything is stable.

Yes, they are both in the same switch. That's what i was afraid of, even if i block all all the traffic between those networks they'll still be able to reach directly….... Well thank you for the response VLANs it will be :)

@salmonbaytech: On both routers I have all my networking configured in a LAGG with vlans on top.  Router 1 is plugged into port 21 on both switches and Router two is plugged into port 22 on both switches. Are you sure the Netgear switches do LACP across the two switches (As in you can plug a cable into each switch and correctly bring up the trunk to PFSense)? Generally when you are doing LACP, it needs to be the same layer devices on the ends. HP has a few switches that will do it –- I believe they call it distributive trunking.

A /28 has 16 total IPs in it. Your network addresses would fall on .0 and .16 Broadcasts would be on .15 and .31 50.0.1.10/28 is a usable address.

Solved this on my own I think. Wasn't spanning tree.  It was the vrrp we also enabled between the two switches. I thought using the VLAN tag as the VHID was a nice way of keeping things lined up but since the switch uses the same for it's vrrp tag apparently that's where everything broke. Simply incrementing my VHID on the pfsense pair by 1 has everything working again.

Never mind, I guess.  Went to lunch and they were all synced when I got back.  Seems to be syncing changes as expected again.

It seems, that one provider had failed and it is working now. Unfotunately some users have "blackouts" from time to time for about ~5 minutes. Do you think it could be problem with outbound NAT or where should I look?

Problem solved. Thanks everyone. NAT problem was found for ISP#2.

Well, you can disable CARP on the master in Status > CARP (failover) I think there are a couple new widgets in 2.2.1 that deal with resetting the demotion score or something.  I haven't looked at it yet. Yeah: https://doc.pfsense.org/index.php?title=2.2.1_New_Features_and_Changes#VIP.2FCARP