Hello Dotdash, Thanks for your reply. My diagram was not complete, I already had the VIP setup for all interfaces. It's working since this morning. I'm not exactly sure what was wrong. I've setup the DHCP servers as I've already done a few times without success, but this time it worked. I let a few days go by before making my final attempt. I red the chapter about configuring CARP (especially the DHCP part) before proceeding. Maybe I needed the break. Anyway, this issue is solved. Thanks !

Viragomann put me on the right track, though there was a catch.  The original problem was that I wanted to perform CARP firewall rules synchronization between a master and a backup, but the backup had an extra interface (a wireless access point) the master didn't have.  Consequently, the rules for the extra interface were been deleted whenever the rules synchronized.  Viragomann suggested creating a dummy interface on the master for a non-existent VLAN, giving it the same name as the wireless interface on the backup firewall, and putting the rules there.  The basic idea was good, but with a problem. The problem comes in the way that the interfaces are named.  When I created the dummy VLAN on the master, pfSense named it "OPT5".  I then renamed it to "wireless" to match the interface name on the backup.  It seems that renaming OPT5 to "wireless" is a cosmetic change only.  Internally pfSense still calls it "OPT5", and all the rules are associated with "OPT5".  When CARP performs the firewall synchronization, it copied all those wireless rules to the backup firewalls "OPT5", which was some other VLAN.  On the backup, pfSense knows the wireless interface as "OPT4".  I had to delete everything on the master firewall associated with OPT4 and above, and recreate them in the right order so that their internal "OPT" names aligned with the ones on the backup firewall.  Once I did that, synchronization worked great. Thanks, Viragomann, for putting me on the right path.

I appreciate the honesty and I totally see your point.

To switch from CARP back to a stand-alone unit you can remove the sync settings from System > High Avail Sync and from the DHCP server tabs. CARP VIPs and NAT can be left as-is.

Yes.  The description field doesn't seem to like transferring over some special characters.  It's annoying but I've been avoiding characters that appear to disappear. Dino

Gentle bump to see if anyone knows anything about this these days… I saw this post, which I think could be relevant: https://forums.freebsd.org/threads/tftpd-and-interface-alias-issue.37695/ It looks like that by modifying inetd I should be able to achieve what I want, but not sure what needs changing.

Assuming they are on the same subnet, what happens when you simply setup High Availability Sync without setting up CARP?

@rcpao: /sbin/ifconfig from the shell shows which NIC a VIP is associated along with with via the VIP's netmask, broadcast, and vhid, but not the VIP's MAC Address. CARP MAC addresses are generated algorithmically and follow the scheme for VRRP.  See this: https://tools.ietf.org/html/rfc3768#section-7.3 for details. Run a packet capture on the interface with the CARP IPs and watch some traffic.  You should see those MAC addresses in the frames. Cheers Jon

Hi, I have been struggling with the same problem recently in a similar setup, and I also have found the mentioned MAC learning filter VIB, but I wanted to ask few questions before I go for it. It is not clear to me, that after I install the VIB, on which vm network ports should I enable the dvfilter? I suppose those VM-ports have to be filter enabled which are connected to a port group with promiscuous mode enabled, right? Another point is, that this MAC filter never forgets. Once a MAC is stored in the MAC table, it remains there for good(!?), which a little bit worries me, since if the MAC table is full, the filter would no longer be capable to prevent the packet flood. But on the other side, I personally do not know how many MACs can be stored for a given port in the MAC table. Do you happen to have any experience with that, or a workaround whether the MAC table can be emptied somehow manually once it gets full? Thanks, Leva

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.