@mikethiessen Thank you, I ended up doing just that and once the 8th spot was made, I deleted the other 2.

@Tadmin
A CARP setup requires at least two IPs within a subnet for the two nodes and a shared CARP VIP. All three have to be static to get CARP work out of the box. A shared DHCP VIP is not supported.

However, people posted workarounds here to get it up with DHCP as far as I remember. But this needs some scripting. Try the forum search.

@Phelton Don't know what you mean by your last comment but make sure that BASE is e.g. 1 on main and at least 100 on secondary. Also, use a different VHID Group for each network/carp ip

@MrPete You, Sir, are a lifesaver! I spent quite a couple of days figuring this out with no avail! Thank you a hundred times!!!

FWIW : I have moved all AD Server to the dhcp lan subnet, removed the ra server configuration, removed the virtual IP to have a second subnet, and all works flowlessly.

It seems ipv6 virtual ip routing is not working as expected on the LAN side.

@antoinef67 I registered an account just to say thank you sir, a life saver!

@gkuyuk Had it resolved after spending some time on it. Setting the MTU to 1420 and MSS to 1280 on the sync interface resolved the problem. The switch was set at mtu 9000 and with that setting and default mtu of 1500 things should have been working fine but appearently not. Wanted to put it here if anyone else have a similar problem.s

@ccMatze
Floating ip's in hetzner can be moved only via robot administration, or custom api by making calls.
If you need carp then you need to order a /29 subnet,
However I don't see any option for /29 (or any other subnet) for cloud hosts.

You need to rethink your approach. Hetzner cloud vm's are already redundant. So in case of failure, your pfsense instance will always be available.
If you really need such redundancy then you should consider using dedicated servers which of course creates its own set of issues and concerns.

@vinns said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):

right. thats the same result we got too. so nothing new on that. and i agree on the fact that, it could very well be that the support of HA sync does not include the FRR, afterall that is an additional package. i mean its not the end of the world to copy 30-40 lines from the xml and add them to the second node if that is the case so be it. :) many thanks for looking into this man , appreciate your help :)

:) 👍

@hoba

This seemed to work for one of our sets, so THANK YOU!

However, for anyone else that might be in the same boat, our state table was colsossal and therefore this may be a treatment, rather that a cure. *Or may be indicitave of an issue on one of the local networks

*I waited to hit submit until I found the issue - Camera system, wide open on separate VLAN in this case

We had the luxury (!) to run this remotely, in non peak times, with alternative, remote access, on the local intefaces - rather than WAN.

It took about 16 minutes for both on Xeon 3.2 physical, 8 vCpu, 8GB RAM 128GB fixed.

In fact, if you have alternative remote access to the local network, I'd recommend the exact of above with the states, wait for the states to clear, reboot each, then reenable 'System > High Availability > Synchronize states

I don't recommend doing this if you will have to travel several hours to complete on-site, and you don't have alternative remote access to the site. *just my 2¢