Messages

The problem is most likely with emergingthreats. I reported it to their forum : https://community.emergingthreats.net/t/opnsense-suricata-rule-update-for-et-telemetry/1952/22

As pointed by gpb, the incorrect logging is not limited to IPv6. Since 25.1.1, having IPv4 only and NAT redirection for ntp and dns, my 2 associated 'quick pass no log' firewall rules for ntp and dns generate wrong cosmetic block logs. This misbehavior was not present in 25.1.
My other pass rules don't generate any block logs

That's expected behavior from the firewall component. It cannot filter based on hostnames but only on IPs and ports.
You should use a DNS blocklist with unbound for your purpose. That way you won't get these expected name resolutions.

Faced wireguard errors and not connecting.
Looks like the new code cannot handle dns resolutions and requires ip address for Endpoint address.

Your setup should work with siteB having a /16 or /24 (NAT has nothing to do here and there is no madness) if you have the redundant static routes set for each tunnel at both sites. At least on cisco and juniper, it would work.
Don't know if there is something fishy with bsd handling for 2 static routes with the same destination prefix.
If the static routes don't work, you might try the frr plugin and setting a routing protocol like ospf with redistribute connected. Ospf would only need to be enabled on the 2 tunnels.

Suggest you read the pfsense page about arc tuning so you can limit its usage https://docs.netgate.com/pfsense/en/latest/hardware/tune-zfs.html

Still having weird thing maybe related. The tab "ui/diagnostics/firewall/pf_top" shows Rule = null for all entries.
"ui/diagnostics/firewall/states" shows the rules properly.
Just did a reinstall of base to be sure and still the same. Is that expected or not ?

Had the same problem with empty widget after base reinstall. It started to populate entries in the widget the next day. Don't know if there is any log rotation involved but maybe leave it alone for now and check back tomorrow if it finally works.

6.5 seems fine. No crash so far.
Please improve the QA. Are updates not pushed first to development branch and test gear before deployment to production branch ? This issue and the others would have been quickly spotted. Guess it's better to wait a week before deploying updates

I guess almost constant crashing is a good way to prevent security risks.
More seriously, I think it would have been better to keep the previous version or go for 6.3 and highlight the risks rather than providing an updated version that doesn't work and will trigger people to ask for help.

Squid6.4 keeps crashing and dumping core. This wasn't happening with the previous version.
Always the same fatal error in cache log :
kid1| FATAL: assertion failed: stmem.cc:98: "lowestOffset () <= target_offset"   

This isn't an isolated occurrence - see https://www.mail-archive.com/squid-users@lists.squid-cache.org/msg25028.html. Crashes were apparently not happening in 6.3

Widget still remains empty for me after reinstalling base and having Live view showing labels again