Hmm, that's very generic. That function is used by numerous things. Was anything else logged at the time?

If you are accessing pfSense using the new gui via Nexus then removing the package would break access to the firewall which is obviously... undesirable! If you don't need to use it just don't enable it.

@PatRyan See the end of this thread as it looks related.

@w0w Red Hat Enterprise Linux 9.7 (Plow) on a HP HP EliteDesk 800 G5 SFF and a Mellanox Technologies MT27500 Family [ConnectX-3] (ConnectX-3 10 GbE Single Port SFP+ Adapter) mlx4_core feeding a managed l3 switch only for vlans

@Antibiotic I did test. It's no longer crashing with both "static port" and "eim nat" checked together. Not sure still what the behavioral differences are between running with just one vs both checked. This will hopefully get some more documentation and examples over time.

@p1erre said in [solved] wireguard issue: same like there: https://forum.netgate.com/post/1229105 but the bug fix for redmine#16475 should be in the latest RC, so disabling limiters shouldn't be required? I had a limiter for buffer bloat active on the WAN when I tested earlier, so perhaps what you saw was another bug manifesting? Btw, I didn't test remote access WG in any of the previous 25.11 versions so I have nothing to compare with.

@Gertjan said in Kea registrations: Looks like you have a ' or " in one of your host names. no, the errors were caused by cached leases from previous RC. Once I had cleared them the issues was gone.

I found a config created just before the package removal fest begun and managed to restore it. There's no automatic installation of packages it seems, and manually installing Nexus gives me this, unhelpful...: [image: 1764196584371-screenshot-2025-11-26-at-23.35.47-resized.png] However, I managed to install it running "pkg install pfSense-pkg-Nexus". The other packages have also been reinstalled, and my pfSense appears to be back in action, fingers crossed.

@marcosm But it is only the DHCP entries that are duplicated, none of the other entries are which suggests it's something specific to DHCP

I installed another secondary pfSense node and configured only the necessary interfaces, VIPs, and HA. I restored only the firewall rules and tried to sync — it worked fine. Then I deleted all rules except those needed on the SYNC interface. After that, I installed pfBlockerNG (without configuring anything). Sync stopped working immediately. As always reports synced sections... but test firewall rule is not synced. configuration diff shows only date/time changed. Nov 26 17:41:15 pkg-static 26347 pfSense-pkg-pfBlockerNG-3.2.9_1 installed Nov 26 17:41:17 php-fpm 582 /rc.filter_configure_sync: Gateway Recovery: killed policy routing states for tier 2 in failOVERWANS Nov 26 17:41:17 php-fpm 582 /rc.filter_configure_sync: Gateway Recovery: killed policy routing states for tier 2 in IPV6_group Nov 26 17:42:06 php-fpm 84114 /xmlrpc.php: Configuration Change: (system)@10.0.88.1: Merged in config (dhcpdv6, staticroutes, gateways, virtualip, system, hasync, aliases, ca, cert, crl, dhcpd, dnshaper, dnsmasq, filter, ipsec, kea, kea6, nat, schedules, shaper, unbound, wol sections) from XMLRPC client. Nov 26 17:42:06 check_reload_status 653 Syncing firewall Nov 26 17:42:06 check_reload_status 653 Reloading filter This leads me to think there is some underlying problem on the primary node, or that it is somehow related to the interface configuration. I’m not sure.

Yes.

@pst said in Some observations testing 25.11.r.20251118.1708 on Netgate 2100: DNS lookup of DHCPv6 leases As has been reported elsewhere, I noticed DNS lookup is not working for IPv6 addresses. Currently : nslookup host gives me the ipv4 address, and nslookup host.t gives the ipv6 address. Marcos was able to successfully address it yesterday.

Thanks for the report. This will be fixed in the release.

I've been seeing the same since last week. One or two insta-refreshes is all it's been taking.

@marcosm Appreciate all this clarification. Thanks.

Well it far higher than even the 1M default we usually set and that is generally far bigger than it needs to be. But you also show only 1400 states which is nothing. If you exhaust the mbufs that would definitely cause a problem. But you should also see that logging an error.

@SteveITS Thank you!!

Are you able to reproduce this, e.g. by rolling back the BE and trying the update again?

@marcosm I just upgraded to the latest version, and the Wireguard service is now running.