It turned out it's faulty switch... Replaced it and all well.. Sorry for the trouble and thanks for all suggestions !

bump

@alkaid So maybe your backend server is configured to use the secondary node as default gateway. The default gateway on your local devices behind the HA pair should be the CARP VIP of the subnet.

@terrorbyte704 This is, what I was trying to tell you.

@planedrop FWIW I restarted our backup router just now. The "wait" counter never reset because our a/v was interrupting the "up?" check due to the self-signed cert. (this is not going to happen to most people, but is expected behavior in this case, with Bitdefender) Turns out the web GUI was using a new "GUI default" cert that it created at the boot instead of the real cert I mentioned above. Not real sure of the path there. I thought when I posted above it had already been set to use the new cert, but I can't go back and look again, now.

@doni49 Sadly all screenshots are lost. If the browser doesn't show a certificate, either HAproxy does not deliver any, because it's not assigned correctly, or you are connected to the wrong host.

Thank you very much for your reply. I've managed to get it to work - thanks for your help. A couple of points: • I needed also to add a rule specifically to allow DNS traffic from the DNS Resolver in the firewall across the 4G WAN, otherwise DNS doesn't work (because it doesn't hit on the LAN rule) • In addition to changing the gateway manually (which is fine), I also need to tweak the DNS Resolver setting so that outbound requests go across the 4G WAN and not the normal WAN. Not sure if there's a way around that? If I enable both outgoing interfaces in DNS Resolver, then it seems to distribute DNS traffic even when the gateway doesn't need to failover.

@johnpoz That is what I intended to say I am just dyslexic when it comes to VLANs.

@SteveITS Thank you for this. I expected to see something similar with my primary's NICs. I did however set up CARP a number of times with the UI in 2.7.2, which may have triggered the problem in my case. I have bi-directional pfsync set up, but XMLRPC sync is only from the primary to the secondary. I will report the issue to the developers.

@CaptainKeyboard The hint to consider rule was in my first post. But glad, that's working now.

@viragomann thank you!

So I edited config.xml (plus 63 IP Aliases) and held my breath... The web interface of the secondary firewall became unresponsive for several minutes (the command line was still available). During this time, the secondary sent dozens of messages about assuming CARP state whatsoever. Eventually, things settled down and I could access the web interface again. I found that both firewalls considered themselves master for the "interface" CARP IP and all Alias IPs associated with it. I temporarily disabled CARP on both firewalls and enabled it again. Now things look okay.

@nxsysop Hi, i know this is an old post, but wondering if your solution worked. We are also trying to setup using a pair of 8200's. We are going to use LACP, but wasn't sure if static or dynamic would work with the Dell switches which are setup using VLT. Thanks

I didn't find a solution until now to have HA with IGMP Proxy. Has somebody a solution which works fine?

i have replicated topology in GNS3 Lab and have same issue: [image: 1711556968503-immagine-2024-03-27-172830.jpg]

@kprovost I have now got this working, I have no idea what I did differently but on two newly built virtual machines I have it working.

It’s generally recommended to avoid using the Virtual IP (VIP) to access the GUI for security reasons. The VIP is typically exposed to more traffic and potential attacks, so accessing the GUI through it could expose sensitive administrative interfaces. Instead, it’s safer to access the GUI from a management interface or VPN that’s not directly exposed to the internet. When you route all traffic from the Test subnet through the pfSense firewall using a specific LAN IP, you’re essentially creating a single point of failure. If you want to use the VIP (10.0.2.101) and still have the traffic appear to come from the load balancer’s public IP, you’ll need to ensure that the VIP is correctly configured for outbound NAT and that the load balancer is set up to handle outbound traffic from the VIP address.