In other words:

Using the CARP VIP you get guaranteed failover and consistent behavior across all client platforms. Using both you are completely reliant upon the client to behave in specific ways, which only gets worse on networks with many different types of clients.

@Derelict

Thanks for the confirmation that the behaviour is as expected. Very much appreciated.

I think I'm at least partially encountering this bug, which I updated with what I'm seeing: https://redmine.pfsense.org/issues/6579

Thanks for the reply

Thanks for contacting me. We did mostly static reservations but then it got too much overhead with devices coming online.

And yes, when the backup dhcp answers it registers with unbound on the backup DNS where I can see the entry. but the backup DNS does not sync back to the master, and when there is an update from the master the entry in the backup gets wiped (i think, didn't verify).

I thought I had a solution by blocking dhcp from 0.0.0.0 to lan-address:67 which gets propagated to the backup. and dhcp traffic is only received via the carp address. That seemed to work but then I found a client with which it did not work haven't found why.

The proper way is to turn DDNS and have a separate DNS server to take the registration from either dhcp server. This will also solve one deficiency of pfsense where it can not resolve/access DNS servers on the other side of an ipsec tunnel (if you have branch offices) We had to resort to having a second caching DNS server for that purpose to forward inquiries too.

@JeGr

Hi JeGr

Thank you for you explanation.

I've talked to my provider and they can supply me with a transit network and route a /29 through it.
Though their /29 is more expensive than renting a /24 from a provider. My concern is if they will
be willing to announce this /24, if they have to or they can refuse? the price they will charge for it
I will clarify it tomorrow.

PROBLEM SOLVED:

Call on OVH to activate the promiscuity mode on our WAN interfaces.

From now on everything is working, thank you for your help.

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.