@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)?

I did try just bringing the interfaces up/down with ifconfig, but this didn't seem to work correctly… I also tried bringing down the physical interface rather than the ppp interface, but that just caused pppoe to stall and never reconnect. There's options in the webui to connect and disconnect a ppp interface, is there some way to trigger this from the cli?

Sorted… Had to set the VIPs interface to Localhost for whatever reason.

There are several problems with that: HA nodes with CARP must have identical interface setups. You can't have three different ISPs across two nodes and have it work properly. Failover signaling happens via CARP VIPs not the sync interface and those VIPs decide to fail over based on multicast heartbeats on each segment with a CARP VIP (e.g. LAN) Using HA for "Multi-WAN" is not viable. There is no way to signal node failover based on a WAN failure. For proper HA, all nodes must be connected to all the same ISPs, though that isn't always possible, without that you can't have a setup that will cover both HA and WAN failover.

I have migrated to IKEv2 because of the strongswan's L2TP implementation does not work for the clients behind their firewall. IKEv2 works with CARP without any problem! Best regards yarick123