I too would like to know the answer to this.  I also have a similar MLPPP configuration and would like to know if CARP Failover will work.

Now it is working. I've had to choose for the OpenVPN server the CARP VIP as an interface.
Thank you!

Hmm, ping and RDP started working when I checked the "Default gateway" box on the Fiber Link.

Not sure I understand why that is….

Thanks, that fixed the issue.

It's disabled when the configuration format is different between them, as marked by the "<version>XX.Y</version>" in config.xml

If the configuration version is different, they cannot sync because it could push incorrect data.

That said, synchronizing between different versions has never been officially supported, nor recommended. It may have worked by chance before, but we never recommend running different versions for any measurable amount of time. Just long enough to make sure the updated node is functional/tested, which shouldn't involve any configuration changes.

Any blog post or diagram should tell you to get a /29. That is how it is done. Anything worth HA is worth doing right, IMHO.

And you cannot use Automatic outbound NAT with CARP/HA. It must be manual to the CARP VIP is used there.

Try these:

net.inet.igmp.default_version=2
net.inet.igmp.sendra=0
net.inet.igmp.legacysup=1

I have resolved the issue, it appears I was hitting a change in pfsync as of pfsense 2.2 as shown here

https://forum.pfsense.org/index.php?topic=93052.0
https://forum.pfsense.org/index.php?topic=93132.msg519077#msg519077

Since I was using VMXNET3 interfaces in ESXi and VirtIO interfaces in Proxmox they show up as different hardware since they have different drivers and pfsync cannot function properly.  The work around in the previous threads was to create a LAGG but the simpler solution in this case was to change Proxmox to use VMXNET3 interfaces and my states are synced perfectly now.  Changing both VMs to use E1000 interfaces likely would have worked too.

It works for me in Chrome here on 2.3.3. Make sure you clear the browser cache (ctrl+F5, or shift+reload) between tests.

I tried switching between each of the possible VIP modes and the correct fields were enabled each time.

Solved!

On the controller's firewall i had to disable "Prohibit IP Spoofing".

@Elegant
You already have Dial on Demand.
What I have read here http://sirlagz.net/2014/12/22/pfsense-carp-and-pppoe/ and here http://theartofservice.com/pfsense-carp-and-pppoe.html is that you also need to disable the Gateway monitoring. Then PPPoE will only be created on 2nd Firewall when 1st one goes down.
I have not done this myself though yet.

@KOM:

A port-forward / 1:1 NAT must be mapped to something.  In your case you would map it to the local IP of the CentOS box.  That's how it works.  And as I mentioned earlier, if you're uncomfortable forwarding traffic to a host on your LAN, then create a DMZ via new interface or VLAN and move your CentOS box there.

Ok, so I will run a physical ethernet cable between my OPT1 interface and a physical interface on my ESXi Server. I'll assign that interface to CENTOS within the ESXI Controller.

What will my configuration look like in PFsense?

Thanks viragomann  ;)

Does WAN stay MASTER/BACKUP or is it always MASTER/MASTER?

There's not a lot to happen there. Setting CARP maintenance mode hard sets the advskew to 254 and if the primary receives a more recent advert from the backup it will go into a BACKUP state on that VIP, likewise if the backup does not receive a more recent advert from the primary it will go MASTER.

Running a mismatched pair can be challenging and is not recommended. But this should work. State sync is another matter.

How are the WAN ports and the DCGW physically and virtually connected? Do both WAN ports see the CARP adv traffic like they should? (Packet Capture on CARP.)

I too am receiving this error that I believe is related to PHP-FPM

Sometimes if you restart php-fpmd service in the secondary node the SYNC completes. I sometimes need to reboot the FW in order to get the config syncronized.

My issue of the unexplained ignoring of the MAC address bypass list was solved by upgrading to a development snapshot (2.3.4 something) but in a failover to the backup router, which still had 2.3.2-Release-p1, the problem still existed, so we upgraded that to whatever snapshot was available that day. As soon as the 2.3.3 maintenance release is out we'll try that and see whether the problem comes back or not.

The problem of CARP LAN addresses not responding to workstation ARP requests has not been solved. (Summary: we change static IP address on interface to something else, create CARP virtual IP on LAN with the original IP address, at which point workstations on the network cannot see the CARP IP address. Using a packet sniffer we observe that the router's LAN interface is not responding to ARP requests by workstations for the gateway IP address. Rebooting the router and every other device on the network, including switches and workstations, did not solve the problem.)  We will try that again after the maintenance release as well.

thanks