That's not an answer for what you're looking to accomplish. Can only sync the entirety of that portion of the config (which almost certainly won't be identical across everything), and can only do so to one other host. Some have hacked up their own solutions to accomplish parts of that, specific to their general config management usage. We'll have a solution for centralized management in the future.

@BlueKobold: I my testing I have come across and issue with the pfsense/bsd implementation of LACP. In front of the cluster or behind it, to the LAN or WAN side I mean? Do we talking about dynamic LAG over LACP and automatic set up or do we talking about static LAG manual set up? active/passive or active/active only dynamic lacp sends the fast/slow pdus, so must be dynamic.

@Stevej: Cool so just be sure assuming they give me a /29 (using fictional IP) Master 1.1.1.2 Slave 1.1.1.3 Carp 1.1.1.1 DC gateway 1.1.1.4 Route my RIPE /21 to 1.1.1.1 and all is well. Correct. @Stevej: I'm assuming I'd just configure my virtual ips (from my ripe range) as carp in the vip table? Use type Other VIPs if you're just using for NAT. If public IPs directly assigned on an internal interface, then you want a CARP VIP on that subnet on the internal interface.

The interfaces should, ideally, be identical for pfsync to function properly since the states are bound to interfaces and they use the physical interface names when doing so. That can be worked around by using single NIC LAGG entries but that can be tricky/cumbersome.

Morning, Thank you for the reply, i solved it yesterday, i was just testing in the interim to make sure. Turns out it was a "school boy error" that i only noticed when i was setting up the test lab….i missed enabling mac spoofing on the LAN NIC on one of the PFs' :P ha ha. The solution to this problem was a caffeine increase. ;)

Depends on how your routing works. Generally speaking, no, not without source NAT to one side or the other (which is bad for anti-spam appliances), and not in a way that's geographically redundant, where using a single public IP. Multiple MXes with separate IPs is the best if not only option for redundancy. There are options, tends to get complex though. Probably more than you'll find reasonable help with on a forum because of the complexity. Would be a good fit for professional services.

Hi, since pfSense 2.2 3 IPs in one subnet are no longer necessary: https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#CARP https://doc.pfsense.org/index.php/High_Availability#Common_Requirements However, I've never tried and there are some limitations: https://forum.pfsense.org/index.php?topic=87546.0

What is the gateway for this /29 .104 would be the wire or network, so you would .105 through .110 as viable hosts with .111 being broadcast.  So they gave you 5 of the six viable address is .110 the gateway?

Changed the Interfaces under ESX into promisious mode. I left NAT still disabled and no changes into firewall rules. After a reboot the tunnel came up from the CARP address. Now syncing the tunnel configuration to the second node, thanks for the hint wikidd :) i can continue testing and look how stable it will be.

IP aliases respond to ARP. Again: https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses I have a public IP assigned to a server in the LAN (other IPv4 range / subnet as the WAN). Is this a routed subnet? In that case the HA comes from your ISP routing the subnet to the CARP address on WAN. Then you need three of the public addresses on the inside (but publically addressed) interface.  One for each HA unit and one for CARP.  Then the other hosts on the publicly-addressed segment use the CARP IP as their default gateway. I don't see any need for VIPs other than the CARP VIPs. Maybe draw up a diagram if I'm misunderstanding what you're trying to do.

Reboot of server did the job. ISP did not release the subnet untill a restart of WAN via PPPoE.

Sometimes you need a second set of virtual eyes :) I changed the VHID (still waiting for the Data Centre to assign/confirm a VHID I can use) and so far it seems stable. You would think I would remember this from the last time we had a similar unstable connection which turned out to be the same problem. Thanks for the assistance.

Is that IP address only configured as a CARP VIP on both nodes? Is the CARP VIP status correct on both (Primary shows MASTER, secondary shows BACKUP)?