You can't do that.  Please see: https://forum.pfsense.org/index.php?topic=132909.0

CARP is done on the interfaces themselves. There is a far-too-common misconception that the SYNC interface has something to do with CARP. It does not. It is generally used for state sync (pfsync) and configuration sync (XMLRPC sync). If you have two WAN interfaces, each with an address and sharing a CARP VIP, those interfaces themselves need to be able to exchange CARP heartbeats. The same is true for all CARP/HA interfaces. These are multicast using 224.0.0.18. https://portal.pfsense.org/docs/book/highavailability/index.html A useful troubleshooting tool is to packet capture for CARP traffic on the interface you think should be BACKUP but is MASTER instead. The built-in packet capture will decode CARP and show you the base/advskews, etc. In the default configuration the base/advskew of the primary should be 1/0. It should be 1/100 on the secondary. You will probably see nothing but 1/100 being sent by the secondary where it should be receiving the 1/0 from the primary but it is not. If it was, it would assume BACKUP status and stop the 1/100 heartbeats. A very common misconfiguration is adding an interface but not tagging the new VLANs through all the way between interfaces, etc.

Yes, there is. Configure your machines as real HA with CARP as it should be: https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP) And then set up a Multi-WAN configuration with the two ISPs: https://doc.pfsense.org/index.php/Multi-WAN

You don't configure a CARP cluster like that. You configure everything on the primary and duplicate it on the secondary, preferably by letting XMLRPC sync do the duplication work. The secondary does nothing until a failover event occurs. Best source of info: https://portal.pfsense.org/docs/book/highavailability/multi-wan-with-ha.html See sig for a link to get access to the book cheap.

Editing the XML would be the only viable way to shift them

You saved me a lot of time… The problem was in interface numbering(OPTX). I Have just fixed it and it is working! Thank you!

Yeah…get a switch, preferably two managed switches that can be stacked, support LACP and a shared backplane = full switching redundancy Plan 2 physical connections for each "link", one to each switch for each device (VM Host or pfsense), and use the LACP protocol to bundle the links together. Either switch, pfsense, or link fails and it just keeps on ticking.

Your dedicated sync interface should not have a gateway set. Try adding allow all any any rules to the sync interfaces on both boxes. Backup unit won't get the allow rule from the master until it sync's once. y3- I replied on your thread, IMO it is not related to this thread.

There's some odd quirks in the Broadcom Trident II ASIC on the Arcticas that make it impractical to SPAN on the switches (they insert dotq tags on SPANned packets originating on untagged ports but destined for tagged ports - you wind up with a mix of tagged and untagged packets coming out your SPAN port). We do have a workaround for the moment: running a script on the firewalls that periodically does an arping (using the CARP mac) if that firewall is currently the carp master, and a trigger on a CARP state change that does an immediate arping on a BACKUP->MASTER transition.

Hi, thanks for the commands, I'll have a look into this later this week. Regards Marco

You can use a single public IP, with some restrictions. Here are some notes I took, not definitive, but they worked for me. Put private ips on the WAN interfaces of the primary and secondary firewalls. I used the public ips with a 10. for the first octet and the correct subnet mask If it's a /30 you may have to use .1 and .2 or something. It probably doesn't matter. Leave the gateway blank for now. Un-check the block private option. Make sure you are cabled in correctly, you may want to put the secondary in carp maintenance mode Add a CARP vip on the interface with the public IP. Add the gateway add an outbound nat rule, something like this- WAN 'this firewall' * * * (CARP IP) * NO Restart dpinger after adding the rule. Update interface with gateway. Gateway status should show up on primary, but will be down on secondary. Add port forwards and outbound nat as usual, using public carp. (Not interface address)

Proxy Server: General SettingsGeneral -> Advanced Features -> Integrations Add the option: http_port 192.168.0.237:3128 192.168.0.237 is the virtual IP.

try this, after the system comes back up, and pfsense master fails back then goes down, try to reboot your modem. It's possible it has something to do with the modem and its arp table.

Just reporting back my success. I successfully brought up a temporary node to the same version as my other node. Moved the slave VM over and tested the fail over. Both way worked. I later had a look at the event logs and I saw the incompatibility of the integration software on VM on my host. All these trouble and it was because the VM on the node didn't have the right version of integration software…. I hope this can help others too... If you are running pfSense on a VM, make sure you check the integration software and have the correct version installed. Sometimes when you migrate back and forth, you lose track on the software version and it may not be compatible with the host's version! Thank you.

Thanks for your tips! Thats almost exactly the way I do it right now because of this strange behavior.

Hindsight is 20/20  :-[ I'm taking a short outage on the weekend to update the primary properly. Lesson learned.

I'm not quite sure I followed but I think we have a similar setup in our data center.  Our WAN IP is in a /29 along with its gateway (a data center router).  A /25 is routed to our WAN IP.  pfSense's LAN IP is in the /25 (x.x.x.1) so is the gateway for the "LAN's" public IP addresses. If you want a second device in the "outside" /29 you need to set it up in parallel with your pfSense not behind it.  A router won't pass "WAN subnet" traffic back through into the LAN since that's not where it is supposed to go.

Alright, I have a new issue now that I have used the tcp_outgoing_address command to specify my VIP for all outgoing HTTP traffic. Nothing in my setup has changed except for enabling the clamAV engine in squid.  Since doing so, pages load slowly or not at all. If I remove the tcp_outgoing_address command from my custom options, the problem goes away. Files from eicar.com are caught by clamAV and there is no impact to performance. As soon as I re-enter the tcp_outgoing_address into my squid custom options everything goes in the crapper. Any ideas anyone?