Got an answer from OVH that CARP is not possible for their hardware dedicated servers due to network design. I've solved this using OVH Control Panel API - https://api.ovh.com buy some OVH failover IP's (one or subnet block ) and assign them to "master" firewall in OVH Control Panel create identical "IP alias(es)" for OVH failover IP's attached to WAN interfaces on both "master" and "backup" firewalls.     Yes, create identical IP Aliases - no IP conflict will ever happen. wrote a Python script that moves above OVH failover IP's to "backup" server in case "master" firewall stops responding for let's say 10 seconds     Script can work on backup server on any other Linux/Windows server anywhere. Works just fine - API failover IP move takes about 50-55 seconds to finish. So, if scripts timeout for your "master" firewall is set to 10 seconds - you are looking at max 60-65 seconds outage for your services. Boom.

Got an answer from OVH that CARP is not possible for their hardware dedicated servers due to network design. I've solved this using OVH Control Panel API - https://api.ovh.com buy some OVH failover IP's (one or subnet block ) and assign them to "master" firewall in OVH Control Panel create identical "IP alias(es)" for OVH failover IP's attached to WAN interfaces on both "master" and "backup" firewalls.     Yes, create identical IP Aliases - no IP conflict will ever happen. wrote a Python script that moves above OVH failover IP's to "backup" server in case "master" firewall stops responding for let's say 10 seconds     Script can work on backup server on any other Linux/Windows server anywhere. Works just fine - API failover IP move takes about 50-55 seconds to finish. So, if scripts timeout for your "master" firewall is set to 10 seconds - you are looking at max 60-65 seconds outage for your services. Boom.

No, the drives don't have to match. But you really ought to get on a somewhat recent version…

Solved! Everything else was correct except the NAT Outbound, now all the servers read the correct IP and are back on the server list. [image: 7wAuUge.png]

Thank you for your answers. Everything worked using viragomann rule, in source I used "This firewall" instead of 127.0.0.0/8 and it worked anyway.

Give the servers a private address and do a 1:1 NAT ? https://doc.pfsense.org/index.php/1:1_NAT Firewall -> NAT -> 1:1

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.