All,
maybe I have misread the documentation, hence the post here.
I have two opnsense boxes (740/2752) and have had quite some busy nights.
The DC I run has two links (both /27 on ipv4, one of those does also have a /48 v6 network).
Until recently, I had the systems running as VMs on top of proxmox quite successfully. Now, with the addition of 10G Links the virtualization approach reaches some limitations I am not willing to take - hence the boxes.
Altough I do have subscriptions for the sysems I run the community tree (that way I have a bit of a leap to test things until the features reach my customers).
Now: First: Ipv6 and CARP.
I have set up as follows:
WAN:
2a02:123:4567:ffff::1 is the gateway (ip address obfuscated...)
2a02:123:4567:ffff::2 is the carp IP
2a02:123:4567:ffff::3 is the first node
2a02:123:4567:ffff::4 is the second node
I have added a virtual interface fe80::/64 on this address as I was being told to do so in order to circumvent split brain situations wit radvd.
LAN1:
2a02:123:4567:1::1 is the carp ip
2a02:123:4567:1::2 is the first node ip
2a02:123:4567:1::3 is the second node ip
I have added the fe80::/64 here, too. doesn't make too much of a sense to me to use the same IP twice - but lacking other information I went for it. I also tried another subnet (fe80:1::/64) but that did not make any difference.
to make it short: the whole thing (ipv6) is barely working. it works for ~1-2h, if I'm lucky: 3h - but after that it simply stops.
Does anybody have a clue what's wrong here?
Second issue:
- When I reboot the first firewall... I have to unplug the second firewall because as soon as the first firewall comes up again I lose all (ALL!) network connectivity.
This seems to be related with the first problem because once I remove all ipv6 carp stuff everything works as intended.
I run CARP on a separate VLAN and the interface itself does have a private space ipv6 address. I can ping between nodes.
during the outage the log on the primary fills with tons of:
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 75@vlan01: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 74@vlan01: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 70@vlan01: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 50@vlan019: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 48@vlan019: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 26@vlan06: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 47@vlan019: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 32@vlan013: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 34@vlan015: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 62@vlan012: BACKUP -> MASTER (preempting a slower master)
2026-03-01T23:09:34
Notice
kernel
<6>[124] carp: 44@vlan019: BACKUP -> MASTER (preempting a slower master)
While the backup machines says it's going to backup mode.
Just FYI: I have configured two active/backup laggs on both machines and extensively use VLANs.
I have been using opnsense for years (before that pfSense) and have never ever seen something like that.
(side note: At the moment I can ping wan sided nodes using ipv6 but somehow the routing does not work in direction of the WAN. Still: opnsense tells me (and I have confirmed it) that the ipv6 gateway is reachable)
any idea is appreciated. All I want is a stable active/backup situation that reliably works, routes and fails back. At current, it is simply not usable as a HA solution for me here. I would hate to have to go back to a single node firewall infrastucture.
Kind Regards
Tobias
You are supposed to pick a valid address from the fe80::/10 (link local) range with a /64 prefix length, not fe80::/64 literally. E.g. fe80::1/64. I use fe80::<VLAN ID>/64. That will be the default gateway for router advertisements in that network. Cloud providers like Hetzner frequently use fe80::1/64 everywhere. But fe80::/64 is simply not a valid address.