For anyone interested in the exciting conclusions... it worked fine in the 16x slot for 2 weeks and is still in there now
I put an I340-T4 in the 1x slot at the same time and left that running and that has been perfectly fine as well

It seems to be an incompatibility between the 1x slot and the I350 specifically but i'm not sure why. In either case, the issue seems to be resolved

It may be something specific to AM5 and the I350 in the 1x, or just the I350 and the 1x alone but if anyone else for some reason tries the same, at least you know what symptoms manifest and what the cause was

Thanks again for those that helped and commented

@Belcebu-Gdl

Hola.
Cuando ocurra el problema, yo revisaría desde el ordenador con cliente openvpn (en este caso desde el ordenador con openvpn connect) si hay conectividad al servidor openvpn (pfsense).
Aunque no es lo más común, yo tengo el servidor openvpn escuchando en tcp en lugar de udp. Si está en tcp, puedes desde el ordenador cliente comprobar si hay conectividad con el comando telnet a la ip y puerto del servidor openvpn. De esta manera puedes ir acotando el problema y ver si el problema es de servidor, de red o del cliente.
Un saludo.

It would seem the answer to my question is "/etc/rc.gateway_alarm" is run.

Nothing in there for DHCP leases from what I see. More about restarting VPN sessions and flushing states.

Reverti o servidor para outra versão e atualizei, não funcionou a parte de Data Encryption Algorithms, ela não voltou.

Decidi parar de procurar solução, já que não obtive ajuda aqui e na internet, e resolvi colocar o wirguard no local. Mas estou ainda com algumas questões. Funcionou, estou acessando o fileserver do outro lado, mas alguns serviços como Impressora que usa SMB para fazer scaner, não envia via túnel.

You can download it here now:

https://raw.githubusercontent.com/ianb/alexa-sites/refs/heads/master/top-1m.csv

The problem is solved; it was indeed the network cable that had a loose connection.
It's in the trash!
Thank you all for your help.

Yesterday we built a new pfSense 2.7.2 cluster, master firewall was running for over a week without problems, but about half an hour after setting up CARP and pfSync to the new slave it died with known hvevent problem. It then died several times, again and again.. Not sure but maybe it has something to do with either CARP/ConfigSync/pfSync or multicast traffic (because we know dying pfsense setups without carp configured, so might be multicast traffic in the network which triggers something).

We have had the same experience with our only OPNsense setup, of which the master is running smoothly since we removed the slave firewall.

Yes, those are the correct versions in 25.07-RC. The newer pkgs are currently only in head, what will be 25.11. They may be pulled back into 25.07 at some point if necessary though.

@Proton retro bowl said in VoWiFi slow failover when using GW Groups:

I have theese GW groups:
e947b6a3-6853-4534-a448-05e780e72965-image.png
I have a statis route for Mullvad GW to exit through starlink:
ebd2ec98-90a0-4646-9af4-8ddfd609bb32-image.png
On both Mullvad GW i have:
8f24a410-ce6b-430f-acb9-ce97a7ff84b0-image.png
The same for DOME GW.

Default Gateway is group :
adb3cbe1-1276-48a2-a07b-e29b797d6610-image.png

and the othe rgroup lookes like this:
5cfa03be-dd61-4bb0-b562-c4fc9dc6c5b9-image.png ,

I have also set:
ea0c1c09-dd93-4722-9479-dc0f019f06ea-image.png

And i have my floating rules like this:
a86219e7-b85f-4fb0-a8df-374beaeb0f04-image.png

Including QOS settings.

The idea is that when the boat is near land the DOME GW is avtive and is top priority. VoWifi also exit there if possible.
So - when we only have Starlink - i force all VoWiFi traffic through WG GWs to always have VoWiFi work even then starlink has exit node abroad (get norwegian ip = allowed ViWiFi).

So to my question:

When both Dome and starlink is online, i can call using VoWiFi, no issues. But when Dome failes, it takes several minutes (5-6) before the mobile again can call. or get a call.
Why is this?

I know we are using UDP trffic and STATES here and that a cell phone can have a delay before he checks and reestablishes VoWiFi again, but is there something i can do to make the transition to WG GWs through starlink faster?
How can i kill the STATES faster?

I have also tried sloppy states and state timeout set to 25, but with same result.

Suggestions?

THX!

You can try implementing a script that automatically flushes states when it detects a Gateway change, as this will significantly reduce the switching delay. The problem you are experiencing is that VoWiFi UDP connections still hold the old state, so the device takes time to check and reset. When the state is refreshed immediately, VoWiFi will reconnect faster and avoid the current 5-6 minute wait. Additionally, you can also consider reducing the state timeout value further or enabling the flush states on gateway down feature if your system supports it.

@gemg83 I see what you're saying - it could be the jump from 12.3 to 14 on the BSD side.

It really hampers the use of limiters in multi-WAN setups so it feels like an important bug (I call it a bug as it doesn't behave at all how the UI or documentation suggests, it's more like using them on a floating rule).

Wel, really strange
I disabled the Allo VPN floating rule and restarted pfsense
Now, VPN works even with the block rule and without pass rule, as expected
Really strange that it needed a reboot and the logs I posted above

@jc1976 can you check if you hit the same issue as: Squid: "Undefined symbol "_ZTVNSt3__117bad_function_callE" after upgrade to 2.8?

@stephenw10 I believe that is mpt attempting to talk to the RAID card as if it was in IT mode, trying to count the individual drives ("REPORT LUNS"), and the card replying "No, this is RAID, you can't talk to the drives directly" ("ILLEGAL REQUEST").

I'll run a fs check next time it's convenient to take down the entire network. Probably this evening.