I would like to know the same information.

Hi, your spent time on this topic has been very informative for me, I appreciate it.

Cheers.

Hello,

it got solved by simply disabling and re-enabling 'HA' feature in vSphere cluster settings. I suppose there are some scripts that rebuild the Distributed Virtual Swtiches when HA feature is enabled.

Regards,

Luigi

See above: It can be worked around.

If you were that adamant about redundancy you'd be using lagg/LACP interfaces already, and the problem doesn't exist when lagg interfaces are used.

The issue occurs in a multiwan gw environment, when the default gateway is set to static. after setting the default gw to dhcp, Dashboard update check on the backup pfsense is working.

Can you confirm that haproxy is running and listening on the port you are trying to access in diagnostics\sockets ?

Do you use the carp-monitoring feature of haproxy? Which could cause that haproxy is shutdown on the backup machine, it might still be starting the first half second after fail-over..

Thanks CMB. I will work with the VMWare team to look into this.

Are your interface configurations of SYS correct?
You use a public IP there. Are both IFs in the same subnet?

Got it, I didn't see that since it was the same cause but a different symptom. Thanks for the heads-up, I'll update the redmine issue and flag it for closure.

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.