@marcosm said in What is it? 25.11.a.20250916.0600: @SteveITS If devel was saved previously and then never re-saved with the release branch. Alternatively there was a period of time where the saved branch was ambiguous between releases and a saved branch during that period could potentially result in the same behavior - the fix being the same, just resave the release branch. Well, as far as I remember when latest stable was released, there was no other branch to select, (or save ) I do remember checking this. So yes, if those instances where on beta (which they were) and then that changed to stable and upgraded, that caused the alpha to re-appear. Now that there are two branches available, one can save on stable and not see devel versions. It's a quirk affecting those fiddling with pre release versions, but then, those guys supposedly know what they are doing. (or maybe not )

Ran into this today. I had installed HAProxy a few weeks ago thinking I might use it, also installed the latest update, decided I didn't need it and uninstalled. Now this issue. Just throwing this out there, don't know if HAProxy was the problem, but the suggested commands cleared it up.

Just posting an update in case others have this issue. The android client is dual stack and at times it loses ipv6 connectivity but keeps ipv4 connectivity. I haven't figured out why yet but the result is the topic of this thread. Some, but not all, android clients appear to try and connect with ipv6 and hang, sometimes for minutes, until it finally connects using ipv4. Releasing the WAN interface and renewing the interface fixes the issue until it occurs the next time. Working the ipv6 connectivity under the thread: lan clients periodically drop ipv6 connectivity

I've reverted back to the original hardware now, but I did take the path of least resistance I'm afraid... I restored the original ACB matching the hardware (no configuration changes have taken place on the temporary system) rather than taking a backup on the temporary virtual machine, which skirted around interface naming issues. I also chose to "pre-install" all the packages before restoring the backup to minimise the actual downtime for users, so I skirted around the package installation issue as well, and it kept downtime to just the time of a reboot.

@stephenw10 Hm, how difficult would be be to have something like a differential install? What I mean: install a minimal freeBSD first, and then have an installer that transmutates the install into pfSense. That way, all the system/boot specific aspects are taken from FreeBSD: if FreeBSD supports a platform, it works, otherwise it won’t. And then the installer modifies whatever it needs to, to get pfSense set up. I undestand the complexities with bunch of different hardware, so I’m thinking how one could keep things for the pfSense team minimal.

It will probably make no noticeable difference. Try it and see. If you're running ZFS you can make a snapshot, test it and then roll back if it does cause a problem.

Anycast is a routing method for sending traffic to the nearest servers using the same IP. So here when you connect to 1.1.1.1 it goes to the closest servers. And when you connect to it over a VPN it goes to the closest servers to the other end of the VPN. That's important because if you check the resolve location it appears to be close the VPN location which is your source IP. Differences there can be used to detect connections using a VPN.

@stephenw10 said in Subnet Mask Update: You need to set the subnet mask on everything static in the subnet. You probably still have somethings set to /24 creating route asymmetry when they try to use their gateway instead of sending directly. Everything appears to be working correctly now. I think this was it. I have an UnRaid server that I thought I changed the subnet mask but it didn't change. Actually have to stop the array and change it. After doing this, I'm back in business!

You can just set the log level to query info in the Unbound advanced setting tab.

Ah, interesting. Yup AT&T expect to see their own router at the end of GPON/XPON and pfSense could well be doing something that doesn't play well. Obviously it still shouldn't panic like that. The panic appears to be caused by a race condition during removal of an IPv6 address. If the WAN was renewing a lease repeatedly that seems likely.

So you upgraded the secondary to 25.07 and it didn't hit the same issue?

Hmm, well it should start at boot. If it fails to start I'd expect some error to be logged.

You could try an afterfilterchange shellcmd to trigger a script. That would be triggered when any tunnel comes up.

Hmm, OK. Not much to go on in that report unfortunately. If it does crash again comparing it would be useful. I'll see if anyone else sees anything I'm missing.

You have to assign the OpenVPN client as a new interface so pfSense sees it as a WAN. It will then create a dynamic gateway for it you can use in a policy routing rule.

Thanks for following up. Good result!

Unlikely. The traffic handling for CP clients is identical in Plus.

PHP Errors: [08-Sep-2025 00:01:03 America/New_York] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /usr/local/bin/kea2unbound on line 344 If you are using Kea, with DNS registration enabled, and pfBlocker with DNS-BL be sure to use Python mode to avoid the PHP memory limit. You can also increase the PHP max mem value in Sys > Adv > Misc. But that shouldn't be required if you're using Python mode.