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

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

Not sure if it will help much, but I feel like I had a similar issue that with one of our VIPs and CARP. I was able to resolve the issue by rebooting the backup firewall followed by rebooting the master after the backup is back online. Something with failing over all of the VIPs to both firewalls during the reboots fixed the issue.

I am in a similar situation.  I have a number of firewalls that I have upgraded and need the limiters working.  I really don't want to revert back to 2.1.5

Ok so I got to the datacenter and restarted the webconfigurator on the slave which seemed to sort things out for a short period of time. However this morning, the web UI on the slave has failed again and I am getting sync errors again.

I will go and do a full restart of the slave today but failing that, what else can I look at or do without having to do a full rebuild?

Why would you do that and why do you consider it a problem?

It and will not allow you to detect when one member of the LAGG goes down

Well you could look for traps from the switch/stack doing the LACP for LACP issues but it really seems like overkill but it depends on the application.

Everything always comes down to the endpoints. Unless you are going to LACP to two NICs in every endpoint to two different switches (You can LACP a group across stack members or sometimes with multi-chassis trunking), when the switch that the endpoints are connected to has a problem, those endpoints lose connectivity.

On all of your LANs:

X.X.X.1 CARP
X.X.X.2 Master interface
X.X.X.3 Backup interface

All clients pointed to .1 for routing, DNS, etc.