OMG. My bad! I have protected the HTTP directory password. The password was stored on the external system in the browser. So LE could not access it. Sorry for my misfortune :-(

No. You set up outbound NAT on the inside interface of the HA pair. You need connections to the backup node to appear as they are coming from the master node's inside interface. That way reply traffic is same-subnet so it will be routed correctly.

This should be configured in both directions since you might want to access the primary while the secondary is master.

René,

Depends on your modem. You can. Ask your isp for the instructions. But to you can try to log on to the modem and look for DMZ host or forwarding host and have it send all the data to your internal private specific IP address.

Niels

@dlogan What you are trying to do is difficult because you have an interface network and not a subnet routed to your interface address. You want to do something that is normally accomplished by routing but you cannot route an interface address into another inside network because it is not routed to you.

You have four choices:

Put a switch between your ISP and your WAN ports and just assign two different addresses to both pfSense and the other router's WAN. Your ISP might or might not support this. (Some ISPs put weird/nonsense limits on the number of MAC addresses, etc.) The pfSense firewall would not be involved in the traffic flow to/from that router at all. Bridge an inside interface with the WAN and put the router WAN on the inside bridge port. Your ISP might or might not support this as above. The pfSense firewall could be involved in the traffic flow using firewall rules on the bridge member interfaces if properly-configured. Use 1:1 NAT to NAT one of the interface addresses (an IP alias VIP on your pfSense WAN) to the inside address of the router WAN (A private RFC1918 address, usually). This is what people commonly do when they absolutely have to use an ISP router on the outside for various reasons but want to use a pfSense firewall behind that. Tell your ISP you need another subnet routed to your WAN address. You can then route that subnet properly to an inside network and use it directly on inside devices.

I found a solution - restart :). It seems that the advskew wasn't picked up correctly. I set it to 0 but it reverted to 100 on both nodes which went unnoticed. After making sure it is at 0 for the primary and removing and readding peer IP it recovered.

@netblues Sure, thanks ☺

CARP IP aliases can be temporary or permanently disabled via PHP Shell.
So, problem has been solved.

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.