ARGH! It's always the same, you think you try everything then you post on a forum, then you go back and read the doco and find what you've done wrong. For my NAT rule i was setting it to the LAN CARP VIP, not the WAN CARP VIP. As shown in doco and videos. Apologises. And as for my DNS not working, i had not set the LAN CARP VIP to listen for DNS queries. Apologises folks. All done

Yep I'd like to see central management for my pfSense boxes too. But self hosted, not somewhere in the Internet aka Cloud. So you have all this fancy stuff with HA, MultiWAN and so on...unable to control anything because the central portal is down? Only marketing guys can think of this shit putting Firewall management in the Cloud. -Rico

Your clients need to be set to use the CARP VIP as their default gateway. This is usually done in the DHCP server settings. You need to set outbound NAT so traffic sourced from clients leaving the nodes uses the CARP VIP. Youtube: High Availability Youtube: High Availability Part 2 https://docs.netgate.com/pfsense/en/latest/book/highavailability/index.html

@JeGr said in OpenVPN HA Sync failover: Wouldn't that only happen if you manually shutdown the primary node? Just curious, as in a failure (e.g. uplink down) case, no one would get the exit notify as the line is down? But yeah in an update scenario where you shut down the primary for updating, it would definetly cut links quicker than a timeout. Of course a hard failure will probably not send anything from the OpenVPN process. Those are actually pretty rare compared to setting maintenance mode. An interface down event would (unless the down interface was necessary to send the disconnect advisories)

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