Messages

Something similar happened here as well after the latest update. It fixed itself though. I may have rebooted the modem and/or the router though, not exactly sure what fixed it.

If I am reading this correctly, only rules for Dhcp4 are autogenerated, not for Dhcp6? https://github.com/opnsense/core/blob/265c86ad567fd40e3d347b8d5a2c9a8bbd8cf3ce/src/etc/inc/plugins.inc.d/dnsmasq.inc#L99

My number of system generated rules didn't change even with (Dhcp4) fw rule autogeneration enabled. I will have to debug where it went wrong. Of course I selected a valid interface as suggested above.

You, as a beginner

LOL love the spirit here!

It's not about the size of the wave, it's about the motion of the ocean ;)

That's why I mentioned the Privacy Extension in my post. I want to randomize all address over the ocean, in this case the /56. Addresses in a /64 are regarded as coming from the same source when it comes to tracking, like a /32 in IPv4 terms. Using the full /56 would make it a little harder to track. Why waste them.

Ahh too bad :-\
Thanks guys!

I have a very simple IPv6 setup. No VLANs, no prefix delegation to other routers. I request a prefix from my ISP, get a (random) ::/56 assigned and use Track Interface on the LAN-side which chops the /56 into /64s depending on the prefix id. A static /56 DHCPv6 configuration on the LAN side breaks every time I'm getting a new prefix. That's why I'm only using SLAAC via an unmanaged RA in the LAN.

Now, since I like the Privacy Extension very much, I would like to make the entire /56 available for SLAAC on the LAN side instead of just one /64. How could I do this with a non-static/stateless (redarding a specific IPv6 prefix) approach?

I already tried with 0 in "Prefix Interface Site-Level Aggregation Length" (instead of 8 ) which did not work in combination with the Track Interface option.

I had been experiencing an issue where the CPU usage spiked to 100% when accessing the OPNsense dashboard or navigating through the UI. When using the top command, I saw one or more php-cgi processes consuming close to 100% CPU and using up all available memory until they were terminated. This problem worsened over the past few weeks, and I found myself having to manually terminate the php-cgi processes frequently.

While exploring the file system, I stumbled upon the /var/lib/php/sessions directory and discovered I couldn't list its contents due to the sheer number of leftover PHP session files. These files were so abundant that they severely impacted PHP's session handling capabilities. I was unable to delete the files using rm * due to their volume. Ultimately, I had to remove the entire directory with rm -f /var/lib/php/sessions/ (it gets recreated automatically).

I traced the issue back to an unusually high value set for Session Timeout under System -> Settings -> Administration. I don't recall changing this setting to a value in the millions of minutes, it just makes no sense. I don't know how the default was changed, maybe during previous a config restore?

After deleting the session files and setting the timeout back to 240 minutes no more CPU hogging php-cgi processes!

I'm sharing this in case anyone else encounters a similar issue.