Thanks , i could solve the problem by Enable promiscuous mode on the vSwitch on my VM ware

Couple of questions. Is the VM host using load balancing over multiple nics? If so make sure it is set to IP Hash with the switch configured accordingly. Have you created separate port groups on the virtual switch with  promiscuous mode only enabled on the group that carries the VRRP? Port groups are probably the way forward. Carp, VRRP etc are notoriously idiosyncratic on VMWare

So, thanks to everyone!! Was an issue related to the specific IP. In love with Pfsense again :)

Thanks, I really appreciate your input. It sounds like it's not a great idea. I'll raise it with our provider, but I think we're pushing the boundaries of what they offer. They're a hosting/server provider who deal in bulk rather that bespoke, so anything that deviates from their standard setup is unlikely to be possible. We may simply add a second pfsense instance to test out these extra IPs. The bulk of them are for one very specific use case which could be diverted through a separate pfsense VM without too much effort. Thanks again!

To my knowledge captive portal sessions are not synced period. You'll need to write an XML sync for CP sessions.

This problem seems to have been solved by a reinstall on both machines. Fingers crossed!

Okay, I flattened both nodes, reinstalled 2.2.6-RELEASE and then restored the config to the master, and just an XML with interfaces, gateways, CARP addresses and users to the secondary. After setting up pfsync and XMLRPC again, it seems to be alright, but I guess time will tell!

Hello, good morning! I have a pair (2.2.6) on HA under VMWARE ESXi 6 for my production environment, it is working really fine for me, apart from an issue that I can't use my WAN CARP IP for outbound traffic. This how to is simple and have everything you might need: http://blog.thedarkwinter.com/2015/03/pfsense-ha-hardwaredevice-failover.html For my sync interface I'm using a crossover cable, NIC to NIC.

From what I've heard the settings for VMware must be "IP Hash based."

OK, actually the workaround (disabling vmdq) did work, a reboot was necessary. Thanks for the help!

There are no checks for CARP failover outside of whether or not the system can communicate over the network on all its interfaces. There could be at some point in the future, nothing like that exists today though.

Silly question.  Glad no one answered.  Removed that NAT and it's working great! Thanks again for your help! Dino

IP Alias

This can be added to the growing list of "Realtek sucks" threads. I have had zero problems with a pair of APUs, however.

Answering my own question, the "moved permanently" error was caused by protocol mismatches.  I had HTTP enabled on my primary and HTTPS on the backup. From: https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_%28CARP%29 Before proceeding, set the same admin user password and webConfigurator protocol (e.g. HTTPS) on each cluster node. This protocol is set at:  System/Advanced/Admin Access/Protocol