The only interface that should respond to ARP is the interface that holds that MAC address.

If the Comcast device is also responding, it is broken.

This should NOT be the end of the world if everything it does is perfect from a CARP perspective but I suspect it is not.

The ONLY frames that should ever be sourced from a CARP MAC address (like 00:00:5E:00:01:0xVHID) Is the CARP advertisement itself from the current MASTER node. No other traffic should ever be sourced from that MAC address.

ARP responses for the WHO HAS the CARP VIP will be sourced from the interface MAC address and contain 00:00:5E:00:01:0xVHID in the ARP protocol payload in IS AT. What you are posting does not provide enough information because both the ARP payload and the source/dest MAC addresses of the frames themselves all matter here.

All of this pretty much has to work perfectly. This would not be the first time an ISP device was not compatible with CARP/HA because of games it wants to play.

I'll create a ticket then, thanks for the second brain ;)

Edit: Opened it as #9539 in Redmine

What, specifically, is not working?

Thanks a lot!

you cant imagine the help you just gave me! :)

Frank

Just as I'm curious: I thought 2.4.4(-p1+) was already config rev 19.1? At last that's what my cluster systems tell me in system log?

Again, the proper forum for documentation feedback is the give feedback link on the page.

@JeGr thank you for your reply
finally i found the problem it was related with GNS3 because my 2 sites are connected with it. the cloud's i used to represent my LAN block the VIP of the LAN when i shutdown the Master.

Huh? No a router can not have the same networks or overlapping networks on multiple interfaces, ie its wan and lan..

But if the /29 is routed to you this would never be the case since your wan would be the transit network and wouldn't overlap with your routed /29

This has zero to do specific with pfsense - and is just basic 101 routing.

Here lets do an example...

isp .1 --- 1.2.3.0/30 --- .2 wan pfsense opt .1 --- 4.5.6.0/29 --- devices .2, .3, .4 etc..

And sure pfsense could also have lan network in 192.168.1.0/24

Now your isp routes 4.5.6.0/29 to your 1.2.3.2 address.

Okay. Noted. Thank you.

I spoke too soon, it's still not working 100% of the time.

When the backup-pfsense is entering MASTER-status, not all of the time Radius gets started correctly, sometimes I see the following in the Radius-logfile, right afster started it gets stopped again:

Mon Apr 15 14:16:21 2019 : Info: Ready to process requests
Mon Apr 15 14:16:21 2019 : Info: Signalled to terminate
Mon Apr 15 14:16:21 2019 : Info: Exiting normally

Sorry. I have no idea what you are even asking.

The basic things that need to be changed to run pfSense HA in VMware ESXi are described here:

https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-high-availability-clusters.html?highlight=esxi#hypervisor-users-especially-vmware-esx-esxi

So now everything worked fine for a little while.

But then I saw this:
ntp_status_unreachable.png

Using a shell on pfsense I can ping each NTP server and I can also use ntpdate to set the clock. So basically it's not a firewall or routing problem I think.

NTP log doesn't show anything unusual or different compared to the master firewall.

I'll keep looking.

You can probably get away with having only one proper WAN with two single-address WANs as long as:

All addresses are static (not DHCP, PPPoE, etc)

You ensure that the default gateway in the routing table is always the interface where the secondary can get out (has its own routeable interface address)

The main issue is that the secondary can access the internet (get updates, resolve DNS, etc) when it is CARP BACKUP.

Is there a quick way to copy the config from the secondary over to the replaced device?

We had a similar failure here.