This appears fixed in 2.3.1-RELEASE-p5.  (I can't spot anything that could be related in the release notes.)

That explains it. CARP works on every interface where a CARP VIP exists, not the sync interface. They'll switch over completely where the secondary knows it needs to take over and the primary sees that fact, but they have to be able to communicate on all the VLANs and interfaces for that to function.

That sounds like the interface stayed up but would not pass traffic any more, either due to something on either interface (primary or secondary) or something in layer 1 (bad pair out but not in maybe) or layer 2. It is not possible for HA to know what to do in that case. Disable CARP on the malfunctioning master or unplug the failed interface / shutdown the switch port and HA will shutdown CARP on all interfaces and swing to the backup. The answer is more redundancy like LAGG interfaces to stacked switches so traffic will continue to pass in a carrier-up-but-no-traffic-passing situation on one interface. This image is what I get when I change the VLAN on one interface's switch port so carrier stays up but traffic (including CARP) no longer passes between nodes.  

Simply ended up using VLANs for this situation.  Previously had been told that the switch did not support VLANs, found out otherwise. Further… configured VLANs on pfSense under: Interfaces > Assign > VLANs and Interface Assignments.

Hello, Have you checked that the OpenVPN Interface is the VIP and not the physical Interface?

Sure, but what if the primary (now a backup) is not reachable through any interfaces, and you must make changes to the firewall (secondary, now acting as master) right away? What do you do? Write down every config change, then execute them in the primary as soon as it comes back online? There might be an even worse scenario: what if I don't even realize that I'm making changes to the secondary? Don't people usually complain about this potential issue? I'm not sure whether this is not very common, or if there's an alternative which I'm not aware of. Please, don't get me wrong, I don't mean to offend (plus, english is not my native language), that's just out of curiosity, but I was told that Cisco ASA works as I thought pfSense should: whoever's the master, becomes the config replication source. Is it really that complex to implement such a feature? Maybe I'm just looking at things from the wrong point of view, but I'm afraid people will frown at this if config replication might become an issue. So I was looking for a solution Thanks for your time and patience anyway.

Hi, I don't think so! Because my system already have a default from 1631000. My server has 16GB RAM. Today active states in my system is 400000 May be I have to change something on /usr/local/etc/php.ini However, I have no idea if this will work. Im lost!! Thanks a lot Cesar

It looks like (as expected) carp: interface down is an actual carrier loss on the interface. Here are two CARP events on a backup node. The first is a unplug/plug of the patch cable. The second is removing the interface from the same VLAN as the master node, which leaves the interface up but stops CARP advertisement reception. Jun 16 07:08:03 pfSenseB kernel: carp: demoted by 240 to 240 (interface down) Jun 16 07:08:17 pfSenseB kernel: carp: VHID 66@igb1: INIT -> BACKUP Jun 16 07:08:17 pfSenseB kernel: carp: demoted by -240 to 0 (interface up) Jun 16 07:13:02 pfSenseB kernel: carp: VHID 66@igb1: BACKUP -> MASTER (master down) Jun 16 07:13:36 pfSenseB kernel: carp: VHID 66@igb1: MASTER -> BACKUP (more frequent advertisement received) What is your switch logging on the switchport in question? I'd take a good look at your switching and cabling.

https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_%28CARP%29 All interfaces including VLANs that should be redundant have to be able communicate with their CARP partner. So all interfaces have to be connected to switches except the Sync.

Hello, I'd recommend the following setup: Virtual Network Adapter with a vMAC connected to pfSense WAN Set in OVH Control Panel the same vMAC for the 4 IPs Assuming the block purchased was 198.51.100.4/30 (198.51.100.4 - 198.51.100.7), you'd configure pfSense WAN statically with the following settings: IP: 198.51.100.4 Mask bits: 32 (equivalent to 255.255.255.255) Gateway: Not set Configure LAN as suits your better, example: IP: 10.10.10.1 Mask bits: 24 (equivalent to 255.255.255.0) Gateway: Not set Then add a gateway manually for the WAN (If your dedicated server is at 203.0.113.X, you'd use 203.0.113.254 as the gateway) and set the advanced option "Use non-local gateway through interface specific route" to allow gateway outside subnet. Add the virtual IPs to your WAN: 198.51.100.5/32, 198.51.100.6/32, 198.51.100.7/32 In the past this used to be much more complicated (I've followed those tuts to a certain extent on earlier pfSense versions): http://blog.magiksys.net/pfsense-firewall-default-gateway-different-subnet http://magiksys.blogspot.pt/2012/12/pfsense-bridge-gateway-vmware-ovh-ip.html Regards, Jorge M. Oliveira

Because you didn't have one on the primary at the time. Add the rule(s) on the primary, add again on the secondary so the primary can sync to it, then sync.

Try to disable Virtual IP sync in XMLRPC (I had some issue with it in the past) Align Advertising Frequency for VIP's in on both nodes, and manually set skew to 1 on Master and 100 on Backup. If still not stable, the pfSense doc's recommend to increase Adv.Freq. with 1 until stable situation has achieved….