And none of the guides said to put a rule like that in place at the top. In fact many caution against it.

Thanks guys, makes sense. Using the decode as method works.

@ramses-sevilla said in Some doubts configuring High Availability in pfSense 2.4.4.:

Well, then, if the primary node crash I can't modify the config until repare the primary node and be up, isn't it?

Correct. The only thing you should be worrying about when the primary is down is fixing the primary. You could keep a record of changes and then make them again once the primary is online, but there is no way to feed those back to the repaired primary automatically.

Is there no other way to mount the cluster to avoid this problem?

Nothing easy. You could completely change the secondary config so it becomes a new primary, but then you couldn't just turn the old primary back on, you'd have to reconfigure it as the new secondary. That's a significant amount of work, though (changing sync settings, manually adjusting IP addresses, VIPs, etc)

Yes, that's OK, the CARP VIP should be used as upstream gateway.

Do you syncing the states?

When the second box is master and upstream traffic is blocked, what does the filter log show?

good morning,

first of all - thank you for your replys! I teststed again - but to be more precise here are some additional details:

I activated Sync Status now on both devices the messages about blocked V4 Packet didn't come again

So now - I guess there is (maybe) a missleading idea in my testcase or a missing function - I dont't know:

Case: Diconnecting USERLAN (Cutting cable): Backup device went in Master State with Interface USERLAN WAN Interface remains as BACKUP Internet connection is losst and didn't return until the cable is plugt in again Case: Powering off the Master Device: Backup device went in Master State with ALL Interfaces Internet connection is working as expected

My guess is now - maybe the case of a "broken" cable is not covered of the pfsense HA Cluster? Or do I have to dig deeper and there is a missconfiguration on my site?

Best regards
Martin

That is not normal, but the version you are on is so old there is no telling what is wrong. You need to upgrade to a supported release (2.4.4-p3) and try again. Chances are, it won't be a problem after the upgrade.

You can do the upgrade from ssh.

@jimp said in Debug CARP backup promoting itself?:

That can pretty much only be a layer 2 issue. Investigate your switch. Especially if it has any "smart" multicast or broadcast features like storm control.

Thanks

I found some debugging steps for my switches (Extreme networks) and ended up turning off IGMP snooping and it started to work.

IGMP snooping was enabled on all VLANS but only one was having problems. Go figure, but at least we're back in business.

Thanks!

Thanks for this confirmation. Indeed even /32 it will still works(confusing that with the VIP). But anyway i will keep it as the subnet mask of the gateway.

As @Derelict suggests, consult the docs, and to that I would add that it is important to remember that at the base of Ethernet communication, it is between two mac addresses, layer 3 comes after, consequently, you need to make sure that the layer 2, mac address visibility is as you expect it to be on the devices facing the CARP cluster, both upstream and downstream, and as well as on pfSense boxes.
Packet captures (detail level full) are a great way to check this, and pay particular attention to the ethernet addresses.

@pmisch said in HA more secure firewall rules:

Obviously no one is actually concerned with nonrestrictive rules for local interfaces.

Of course we are. But that depends of the scope of the setup. Also it has something to do with filtering. As we do inbound filtering, the packet - for a direct connection to be exploited with a "pass any rule" - has to come from the other firewall's sync interface. Actually we set the IF up with "from: sync_net" to "sync_addr" but you'd also have to setup HA with unicast so no multicast address is used. Of course you also need the right port for https if you modified the WebUI port and need pfsync protocol like @Derelict explains.

For posterity, the problem was initially solved by changing the switch between the two CARP members.

Apparently the Aruba-flavoured HP switches call home ( to activate.arubanetworks.com ), and while I'm not sure why this wrecks things for a multi-WAN CARP setup, once the feature was disabled on the switch it ceased causing STP problems.

We only found out because we had to replace the (replaced) CARP switch in a hurry (next planned setup will have redundant switches too).
The guy who arrived first grabbed the first unattended switch he could find (it was the HP), without knowing the problem it initially caused, and was just happy to have it already configured with the correct VLAN groups. Asking around, it turned out the only change in configuration was the mentioned call home feature being disabled.

Hope this helps someone. It had me banging my head against the rack for way too long.

Works best if you do.

In general, if it is worth HA it is worth doing right. Especially if you are responsible for moving multi-gigabits of traffic around.

Okay seemd 18.9 ist the 2.4.4._p2 and 19.1 ist 2.4.4_p3.
Both system have installed the p3 release according to /conf/upgrade_log

[16/16] Upgrading pfSense from 2.4.4_2 to 2.4.4_3...
[16/16] Extracting pfSense-2.4.4_3: ..... done

@Mode: Please move to install / Update category

Problem "solved".
I have monitoring on my wan gw and both on my core router.
I have disabled the monitoring on my wan gw and the error gone. So if you only have 1 public ip the gw monitoring should be off. Not the best solution but this workes only.

Sounds like your ISP is not compatible with CARP. Some aren't.

https://forum.netgate.com/topic/134297/cox-and-the-carp-mac/
https://forum.netgate.com/topic/146254/carp-outgoing-traffic-black-hole/

Thank you for your response. We are going to use CARP.
We will also build LAGGs for upstream and downstream links so the probability for failure should be pretty low.
We thought about using BGP because our upstream devices can handle that and because it would mean less cabling / ports.

Just FYI I got an answer to this, just not the one I wanted. See my response in https://forum.netgate.com/topic/134297/cox-and-the-carp-mac/17

Yeah that's too bad. Thanks for pursuing it further and reporting back.

@zimmy6996 said in CARP/HA VMWARE ESXi 6.0.0 - Breaking HA after latest ESX patching ....:

Net.ReverseProsCheck

Hey there Zimmy, i am setting up a similar setup within my vmware environment for HA, i have a couple questions for you. 1. where can i find the Net.ReverseProsCheck setting on my host? 2. on your secondary (slave) pfsense vm node did you configure all of the interfaces with an ip or only config the lan and carp interfaces. for example my primary pfsense has about 8 different networks: lan/wifi/wan/sonos/etc do i need to recreate all of these interfaces and set them with a static ip on the secondary box? Thank you in advanced any bit of guidance you can provide would be greatly appreciated.