Messages

[TIP :]

It's not a cookie, it's localStorage.

https://github.com/opnsense/core/blob/bb78d31407a4f36e585d8872ed15969e09832e2f/src/opnsense/www/js/opnsense_bootgrid.js#L633

Perfect! Thank's a lot!

I'm asking because my modified views get very often lost. I can't determine a pattern.

TIP :

Use a seperate Profile for your browser for all your OPNsense activities and perhaps also other Network/Server stuff that you need to do from time to time.

Mozilla based browsers use something like this :

Windows :
firefox.exe -P <YourProfielNameHere>
librefox.exe -P <YourProfielNameHere>
Linux/*BSD :
firefox -P <YourProfileNameHere>
librefox -P <YourProfileNameHere>

For the shortcut that starts the browser.

You can create the Profiles by starting the browser without the <YourProfileNameHere> part and after a few clicks you will have a new one by using the menu that appears :)

Nice idea.
If I'm not able to find the reason why the local storage gets lost, this will be my plan B :)

They're stored in your browser storage.

Thanks. Do you now how? As a cookie?
I'm not familiar with the possible methods to save such settings. But I would like to understand what's deleting them from my client.

Hi all,
I'm wondering how OPNsense remembers the modified WebGUI views e.g. when I changed the column order or width in the firewall rules overview. Are they saved in the browser storage or on the firewall with the other user settings?

I'm asking because my modified views get very often lost. I can't determine a pattern.

Thanks
Jas

Hi folks,

I noticed an increase of the CPU load during the last month and during my investigations I noticed also a big jump of the CPU utilization between the 21th and 22th of August 2024. I would suspect that the two have something to do with each other. (see attachment)

Unfortunately I didn't documented what I've changed during this days.
If it was an OPNsense update it must be version 24.7.1 according the timeline.

My CPU is an Intel Core i5-6200U Skylake-U Dual Core (4 Threads) 2,3 GHz with 16GB RAM.

Any ideas what could be the reason? The "top" output shows no processes with a high load.

Thank you.

Jas

There's a script in OPNsense called "unbound_watcher.py" which should update DNS records if a DHCP lease has changed.
But it seems that it monitores dynamic DHCP leases only and no static lease or IPv6 prefix changes.

To solve my "issue" I added a Unbound restart command to my monit script which monitors the WAN IP addresses of my appliance.

Good contribution! I hadn't thought about the ULA addresses before. But indeed, this could solve my problem. I'll have to think about it if it fits for my LAN.

Thank you very much!

Hi,

I've configured static DHCPv6 leases for some of my IoT devices to be able to resolve the DNS name to their IPv6 address in my LAN.

When my provider gives me a new IPv6 suffix DHCPv6 distributes the new suffix to all clients correctly.
But Unbound does not update the DNS AAAA records with the new suffix. Unbound resolves the names to the previous IPv6 addresses until I restart Unbound.

I'm sure that this behaviour was already disscused in the past. But I can't find the disscusion in the forum.

Have I missed a setting to force Unbound to reload when the WAN IP changes? Or what would be the best way to solve my little issue?

Jas

I had the same request and solved it by using OPNsense monit integration.

Because the test is not availabe over the GUI you need to create a config file under /usr/local/etc/monit.opnsense.d (e.g. 01-CertValidationTest.conf)

Add the following code

Code Select Expand

check host example.tld with address example.tld
            if failed
                    port 443
                    protocol https
                    with ssl options {verify: enable}
                    certificate valid > 30 days
            then alert

After a monit restart you should see the result on the "Status" page of monit.

I was able to solve it.

Nginx was configured to buffer the responses from the upstream server. Therefore, the interfaces and CPU load values for the widgets where send only when the buffer size has been reached.
This caused the 3-second-delay for the interface values, and a 30-second-delay for the CPU load values which was too long for the graph to show anything.

I've disabled "Response Buffering" in the location settings in Nginx.  :)

I've found out that the issue is caused by Nginx.

Nginx provides the OPNsense GUI for external and internal access. When I open the GUI directly all graphs/cards are fine.

Not sure if it is an configuration or plugin issue.

Does anybody use Nginx in combination with OPNsense? 

@geekguy: Try to delete the browser cache for the site. I can remember that it helped in the past.

Thank you for sharing.
I noticed the same when the tab with the gui goes to the background.

But my issues happen right after I've logged in and the tab has the focus. :(

I've issues with the new dashboard cards in 24.7.

The traffic graph is not continuosly. It shows empty parts for 2-3 seconds at the end.
The CPU graph is completly empty.

I tried different browsers and users. Same issues.

I run a test version of OPNsense in Hyper-V, and the graphs are fine there.

Any ideas?

Try this

https://docs.opnsense.org/troubleshooting/password_reset.html

Worked! Thank you.

If you enabled TOTP, you cannot login without it and you are obviously relying on the correct time setting, so that is a risk.

If the internet access is gone, NTP may be running, but how do you know if the time is right? See?

You should either have an SSH login ready with an SSH key (this does not need TOTP) or have the console accessible without a login in order to be able to fix things in case the time goes wrong.

You were right. It seems that the BIOS battery has no power anymore, and the system lost the time after I disconnected the power supply.
And I was wrong with my root user. The user was configured for MFA, too. I've changed it immediatly.  :)

Internet didn't worked because I'm using DNS-over-TLS and due to the wrong time, the certificates didn't match = no DNS.
But I'm still wondering, why the NTP query was successfull.

Nice issue. I'm glad for your help and that I was able to understand the reasons for it.

That sounds good!
I will try and report the result.