I, myself, was trying to do the same exact thing.  I found this: https://b3n.org/pfsense-firewall-ha-failover-cluster/ It worked for me. I did it with my first machine being hardware and my second being virtual with a managed switch. Just trying to help here.

You can manipulate the skew to achieve this, pretty sure you will have to disable Virtual IPs from the HA config sync, other wise the sync will make sure the secondary is larger then the primary. also: I am not advocating you do this, I have never tested this sort of config. Not sure if any strangeness might occur.

What is the nature of the failure? Is it an interface down, as in no carrier, or something else? Failover is all or nothing. If an interface fails on the primary, it demotes ALL CARP on that node and the secondary takes over. There is no "this is active on one node and this is active on the other."

Excellent. In that configuration the server is running on both nodes all the time. Whichever holds the CARP VIP gets the traffic from the clients. You can also bind the openvpn server to the CARP VIP (select that instead of WAN in the server config). That makes the server die on the BACKUP node and start on the MASTER node. I like the port forward technique because it results in fewer things that have to happen on a failover event. Especially as the number of server processes goes up.

Thanks for your answer. I've added a line in /etc/rc.carpmaster to execute my script and it's working well but I notice that /etc/rc.carpmaster was overwritten during last update. The second method could be more stable but I'm not familiar with pfSense package, is there any doc about package structure?

CARP/HA is incompatible with dynamic addressing. Get a static /29 from them instead and you'll be all set.

More information… it appears that I can successfully telnet to the VIP on port 26 from another LAN. When initiated on the same LAN/subnet as the VIP, the connection never responds. On this subnet there is only one firewall rule that allows all in/out on any protocol for IPv4+IPv6, so I there isn't any possible rule that could be blocking.

Sorry, I have been away for some times. –> First option: I got vmx0, vmx1, vmx2 and vmx3. After adding the new NIC, it appears as vmx4 and the existing NIC remain unchanged. Edit: I tried adding a different type of NIC (E1000 instead of VMXNET3) and both scenario worked. So I guess you are right, it is somehow related to the interface naming scheme.

You need three addresses.

Thanks, not sure what that CARP event would mean in practice. If WAN is down I don't really care if pfsense would switch between the units as long as it is restored when WAN is up again. But I'm getting the feeling that I'm introducing more ways things can fail rather than mitigating actual risks, I'll see if I can get into the network some other way and restore functionality manually when something have happened.

The configuration versions of pfSense must be identical on both units. It can't synchronize from 2.3.4 to 2.3.2 because they have different configuration formats https://doc.pfsense.org/index.php/Versions_of_pfSense_and_FreeBSD 2.3.4 is revision 15.8, 2.3.2 is 15.5. Attempting to synchronize that could cause a bad configuration to be loaded on the backup unit. Upgrade both to 2.3.5-p1 (or preferably 2.4.2-p1) and try again.

Hello, again! I managed to resolve this problem myself, when I found that Snort package, which I had installed and configured on WAN, was dropping the state on the slave (the box that is becoming the master on failover), because of the ongoing download for which the initialization was only seen by the snort on the previous master. Hence Snort thought it was an intrusive packet and denied the connection. That also explains, why it was all good again on the master box after failing back. Hope this helps someone, and sorry for the wasted time!

Yes. Being in a virtual environment might cause an unplugged cable to NOT result in an actual interface DOWN to the virtual machines because they are still connected to the vswitch. If your virtual environment supports simulating an unplugged interface there you should try that. In short, it is up to your hypervisor to actually take an interface down from the VM's perspective. I use XenServer and that is pretty hard to simulate there - at least in the 2 minutes I devoted to trying to figure out how to do it. You might also try just taking the interface down in software ifconfig xn0 down Dec 15 20:21:39 kernel carp: 236@xn0: MASTER -> INIT (hardware interface down) Dec 15 20:21:39 kernel carp: demoted by 240 to 240 (interface down) Dec 15 20:21:39 kernel carp: 239@xn0: MASTER -> INIT (hardware interface down) Dec 15 20:21:39 kernel carp: demoted by 240 to 480 (interface down) Dec 15 20:21:39 kernel xn0: link state changed to DOWN Dec 15 20:21:39 kernel carp: 240@xn2: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn2: 3 Dec 15 20:21:39 kernel carp: 237@xn2: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn2: 3 Dec 15 20:21:39 kernel carp: 241@xn4: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn4: 3 Dec 15 20:21:39 kernel carp: 243@xn5: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn5: 3 Dec 15 20:21:39 kernel carp: 238@xn1: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn1: 3 Dec 15 20:21:39 kernel carp: 242@xn5: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn5: 3 Dec 15 20:21:39 kernel carp: 228@xn1: MASTER -> BACKUP (more frequent advertisement received) Secondary takes over for all VIPS. All VIPs on primary are either INIT (the two on xn0) or BACKUP (everything else.) ifconfig xn0 up Dec 15 20:23:44 kernel carp: 236@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: demoted by -240 to 240 (interface up) Dec 15 20:23:44 kernel carp: 239@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: demoted by -240 to 0 (interface up) Dec 15 20:23:44 kernel xn0: link state changed to UP Dec 15 20:23:44 kernel carp: 236@xn0: BACKUP -> INIT (hardware interface up) Dec 15 20:23:44 kernel carp: 236@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: 239@xn0: BACKUP -> INIT (hardware interface up) Dec 15 20:23:44 kernel carp: 239@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 check_reload_status Linkup starting xn0 Dec 15 20:23:44 kernel carp: 239@xn0: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 236@xn0: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 241@xn4: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 240@xn2: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 237@xn2: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 243@xn5: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 242@xn5: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 238@xn1: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 228@xn1: BACKUP -> MASTER (preempting a slower master)

I have the very same issue, but there's no apply button to fix. Need to change the VIP from IP Alias to CARP and then back to get it to work.