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.

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.