I have been trying to set up an OPNSense router for quite some time now but each time I get a setup that seems to die some time after between 40minutes and 18 hours.
I have tried two different computers with three different NICs (all with different chipsets at speeds of 10G, 2.5G & 1G), different amounts of RAM, made up of different DIMMS, different storage media (m.2 nvme & sata ssd). I have tried with versions 25 & 26 of OPNSense.
Initially my network (no vlans or sub domains) was 192.168.0.0/16 but I have reconfigured it to 192.168.2.0/24 in case that was the problem.
I configure OPNSense with a single WAN ethernet connection to my fibre modem (with IP address provided by DHCP) and a single LAN connection to my network (with IP address 192.168.2.1). I make no further configuration changes whilst trying to get everything to work.
Each time, after an amount of time (between 40 minutes & 18 hours), the webGUI starts to break: Every "display section" of the dashboard will show "Failed to load widget" and the uptime will show something like 20000 days. Internet connectivity and DHCP services on my LAN do not seem to be affected. I can still SSH into the server and the system time remains accurate.
I don't know what else to try! How can I keep getting exactly the same fault on different hardware? Please, learned friends, give me the benefits of your experience and expertise!
"...and the uptime will show something like 20000 days"
System time fails? Results in all sorts of errors, as time is essential for many, many things on the interwebs. Check NTP. System board time? CMOS battery?
You are really alone with this kind of error...
Hi
NTP is working fine and the system time is correct. Even after leaving the machine off for several days, the time remains correct, so the CMOS battery and motherboard time are fine!
I have searched the forum and can't find any similar complaints! All I know is that I have tried two different computer systems and lots of different components and the outcome is always the same. Could it be that there might be a device on my network capable of sending packets that are fatal to OPNSense's webGUI?
Thanks for the suggestion.
Quote from: chemlud on April 17, 2026, 03:02:21 PM"...and the uptime will show something like 20000 days"
System time fails? Results in all sorts of errors, as time is essential for many, many things on the interwebs. Check NTP. System board time? CMOS battery?
You are really alone with this kind of error...
Quote from: roohoo on April 17, 2026, 01:11:29 PMI have tried two different computers with three different NICs
Could you post the full hardware specifications ?
Maybe someone recognizes something and can help you out...
To me it sounds like some kind of weird "jump" happening that could be related to bad compatibility with the BIOS/UEFI or some part of some kind of firmware involved, but then I would also expect to see the whole system crash and not just the webGUI to act weird ?!?!
Interestingly, this afternoon I grabbed another computer: A Ryzen 3900x-powered machine with 128GB of RAM, an M.2 nvme drive, and a Quadro video card. I installed OPNSense with a bare setup (just interfaces configured) and started it up.
Now, around two hours later, I have exactly the same issue: That's a third completely different computer used to install and run OPNSense that has the webGUI die in a few hours of running!
The only connecting factor appears to be my home network!
Are you running OPNsense for a couple of hours and when you connect to the web UI again, it's not working?
Or are you leaving the UI open for a couple of hours? I vaguely remember the latter not working for some people. I don't know, I never use OPNsense like that. Log in, configure or check stuff, close tab.
yea, have also encountered this, i accidentally had a tab open for a long time, and when i came back nothing was working in the UI, i could ssh, rebooted and the web ui working again. normally i don't do this, but i had the tab up, got distracted, and when i came back things were weird. i looked in the logs, lighthttpd logs, and saw nothing. so i rebooted and moved on with my life, but it was strange.
If it's the timeout issue, then no need to reboot. OPNsense is fine and it's just the web session that's gone stale.
Hit the browser refresh and log in again.
Quote from: OPNenthu on April 18, 2026, 12:23:05 AMIf it's the timeout issue, then no need to reboot. OPNsense is fine and it's just the web session that's gone stale.
Hit the browser refresh and log in again.
yea, i think i tried refreshing the page, lol. i even closed the browser and couldn't get to the login screen. all networking seemed fine and like i said, ssh worked and i rebooted it via the console and then the web ui worked again. i didn't report anything because i had nothing in the logs, so nothing was going to done about it (which is fine)
The logout logic of opnsense is a bit hit or miss... Most people never realize it because they don't keep sessions open for 4 hours.
This could have happened here.
Also changing from https to http can be catastrophic for up to 1-2 weeks. Chrome in particular if it has connected to a domain or ip using https beforehand, it refuses to acknowledge that http is a real thing.
Generally speaking, I would try incognito sessions.
Quote from: sopex8260 on April 18, 2026, 12:55:56 AMThe logout logic of opnsense is a bit hit or miss... Most people never realize it because they don't keep sessions open for 4 hours.
This could have happened here.
Also changing from https to http can be catastrophic for up to 1-2 weeks. Chrome in particular if it has connected to a domain or ip using https beforehand, it refuses to acknowledge that http is a real thing.
Generally speaking, I would try incognito sessions.
i tried just accessing the with curl which also failed. guess what, it could be something wrong with OPNsense. its not bug free. its also fine. nothing is perfect. but it doesn't seem like something anyone would prioritize, which is also fine.
Quote from: sopex8260 on April 18, 2026, 12:55:56 AMChrome in particular if it has connected to a domain or ip using https beforehand, it refuses to acknowledge that http is a real thing.
Google Chrome/Microsoft Edge/All other Chromium browsers are a disaster for local domains in general so no surprise there!
Mozilla Firefox based browsers are a bit better, but not perfect...
The best option is IMHO a browser that doesn't want to go to your Search Engine the whole time and just does what you tell it to do and for me that browser is Pale Moon : https://www.palemoon.org/download.shtml
Quote from: Patrick M. Hausen on April 17, 2026, 09:17:39 PMAre you running OPNsense for a couple of hours and when you connect to the web UI again, it's not working?
Or are you leaving the UI open for a couple of hours? I vaguely remember the latter not working for some people. I don't know, I never use OPNsense like that. Log in, configure or check stuff, close tab.
I'm setting it running and then leaving it alone. Nothing configured except for the interfaces and ssh access. Every now and again I log in to see what it's up to. I log into it from a myriad of different machines running lots of different browsers but the results are always the same.
The WebGUI currently shows an uptime of 20561 days, 16:30:07 (uptime run at the shell shows 2:10. The WebGUI also shows "Failed to load widget" under Interface Statistics and "No services found" under Services. The CPU, Firewall, Traffic Graph and Traffic Out graphs all appear to be showing normally. Memory use is currently showing 63% 12828/20260 MB which seems high.
Internet access appear to be working fine for all devices on my network.
I think I'm going to try installing pfsense to see if it can handle my network. I can't understand how the OPNSense WebGUI keeps dying on lots of different hardware, installed from different USB drives from different images downloaded at different times. The only conclusion I can draw is that there must be a device on my network sending traffic that is fatal to OPNSense!
I an going to give one of my machines to a colleague at work who currently runs OPNSense at home. He is going to try it on his network which should help troubleshoot further.
Thank you for all your suggestions thus far.
This is what my WebGUI looks like...
Can you show Interfaces: Overview, please?
As requested
Quote from: roohoo on April 17, 2026, 08:51:20 PMInterestingly, this afternoon I grabbed another computer: A Ryzen 3900x-powered machine with 128GB of RAM, an M.2 nvme drive, and a Quadro video card. I installed OPNSense with a bare setup (just interfaces configured) and started it up.
Now, around two hours later, I have exactly the same issue: That's a third completely different computer used to install and run OPNSense that has the webGUI die in a few hours of running!
I use Firefox (ESR) primarily and have it and MS-Edge operating in In-Private mode. I only have two extensions installed in each of them.
On the rare occasion the browser has timed out, the most I've ever needed to do is a browser refresh to regain the login page. I typically have the browser signed in to OPNsense for days without issue and no timeouts.
When you first sign in to the Web GUI, is the
Uptime being reported correctly and does the time on your computer match OPNsense?
The next time this happens, instead of rebooting, select option 11 to restart all services.
Which time zone have you selected in OPNsense?
In your environment, where is your DNS server located?
When you SSH to OPNsense, do you use the IP address or FQDN?
The screen shot you posted on the 18th shows your memory usage at 76.5%, has it gone above this mark?
Quote from: lmoore on April 19, 2026, 04:24:00 PMWhen you first sign in to the Web GUI, is the Uptime being reported correctly and does the time on your computer match OPNsense?
The next time this happens, instead of rebooting, select option 11 to restart all services.
Which time zone have you selected in OPNsense?
In your environment, where is your DNS server located?
When you SSH to OPNsense, do you use the IP address or FQDN?
The screen shot you posted on the 18th shows your memory usage at 76.5%, has it gone above this mark?
When you first sign in to the Web GUI, is the Uptime being reported correctly and does the time on your computer match OPNsense?
It is, occasionally, correct but most of the time it's >20,000 days. OPNSense time is correct
The next time this happens, instead of rebooting, select option 11 to restart all services.
I have tied this. Sometimes it works, most of the time it doesn't have any effect.
Which time zone have you selected in OPNsense?
Europe/London
In your environment, where is your DNS server located?
It's the OPNSense box.
When you SSH to OPNsense, do you use the IP address or FQDN?
IP address [ssh root@192.168.2.1]
The screen shot you posted on the 18th shows your memory usage at 76.5%, has it gone above this mark?
I'm not sure I trust this figure but it often goes above this. At the moment it's 93.48% - that's nearly 19GB! If this is correct, I put it down to either ZFS or FreeBSD making use of some free RAM. Here's the output of a top shell command:
1568 processes:1 running, 1567 sleeping
CPU: 0.9% user, 0.0% nice, 1.6% system, 0.0% interrupt, 97.5% idle
Mem: 11G Active, 1250M Inact, 4031M Laundry, 1685M Wired, 72K Buf, 1048M Free
ARC: 760M Total, 239M MFU, 364M MRU, 32M Anon, 13M Header, 110M Other
538M Compressed, 1384M Uncompressed, 2.57:1 Ratio
Swap: 8192M Total, 916M Used, 7276M Free, 11% Inuse
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11658 root 1 68 0 55M 25M lockf 0 0:00 5.13% php
21957 root 1 21 0 20M 6528K CPU2 2 0:02 2.54% top
344 root 1500 68 0 657M 295M accept 0 100:31 0.46% python3.13
14678 root 4 20 0 53M 7920K kqread 3 4:17 0.23% syslog-ng
96093 root 2 37 0 24M 6424K select 3 0:00 0.13% ntpd
24195 unbound 6 20 0 134M 38M kqread 1 3:23 0.06% unbound
93316 root 1 36 0 14M 2024K bpf 1 0:00 0.05% filterlog
42146 root 1 68 0 13M 1536K select 0 0:11 0.05% dhcp6c
11732 nobody 1 20 0 15M 1816K select 5 0:29 0.04% dnsmasq
95265 root 1 20 0 28M 7752K select 1 0:17 0.01% python3.13
41669 root 1 20 0 28M 5000K select 0 0:05 0.01% python3.13
65213 _flowd 1 20 0 13M 1660K select 2 0:06 0.01% flowd
33021 root 1 20 0 32M 5428K nanslp 0 0:08 0.01% python3.13
39760 root 1 20 0 13M 1256K select 5 0:16 0.01% powerd
57172 root 1 20 0 53M 27M nanslp 1 35:15 0.00% python3.13
80715 root 1 20 0 20M 7668K select 4 0:00 0.00% sshd-session
36291 root 1 20 0 14M 1528K kqread 3 0:01 0.00% rtsold
96883 nobody 1 20 0 13M 1212K sbwait 2 0:02 0.00% samplicate
38379 root 1 20 0 14M 1508K select 1 0:01 0.00% rtsold
76958 root 1 20 0 23M 6984K kqread 4 0:08 0.00% lighttpd
34669 _dhcp 1 20 0 14M 1684K select 1 0:01 0.00% dhclient
98197 root 1 68 0 14M 1616K nanslp 4 0:01 0.00% cron
49260 root 1 20 0 69M 14M accept 4 0:01 0.00% php-cgi
91065 root 1 20 0 53M 13M accept 5 0:01 0.00% php-cgi
90927 root 1 26 0 60M 8192B accept 1 0:01 0.00% <php-cgi>
342 root 1 68 0 29M 8192B wait 3 0:01 0.00% <python3.13>
21933 root 1 4 0 14M 1612K select 3 0:01 0.00% dhclient
9902 root 1 20 0 69M 14M accept 0 0:01 0.00% php-cgi
96048 root 1 20 0 53M 9440K accept 2 0:01 0.00% php-cgi
82910 root 1 20 0 53M 11M accept 3 0:00 0.00% php-cgi
4016 root 1 20 0 53M 14M accept 2 0:00 0.00% php-cgi
3936 root 1 20 0 53M 24M accept 2 0:00 0.00% php-cgi
47989 root 1 68 0 55M 24M lockf 0 0:00 0.00% php
68226 root 1 68 0 55M 24M lockf 0 0:00 0.00% php
90853 root 1 68 0 55M 24M lockf 4 0:00 0.00% php
35933 root 1 68 0 55M 24M lockf 4 0:00 0.00% php
13691 root 1 68 0 55M 24M lockf 2 0:00 0.00% php
60305 root 1 68 0 55M 24M lockf 1 0:00 0.00% php
94602 root 1 68 0 55M 24M lockf 4 0:00 0.00% php
30761 root 1 68 0 55M 24M lockf 0 0:00 0.00% php
With top running type "o" for order, than "res" for resident size followed by ENTER. Other possibilities are e.g. "swap" instead of "res". Lets try to find out who is using all that memory and why.
Also with the fresh install up and running could you try to disable Interfaces: Neighbors: Automatic Discovery?
I've recently set up a test system with only one NIC, there is no WAN interface as yet.
I set up a number of Aliases using URL Table (IPs) to consume as much memory as possible by the firewall.
I then reduced the installed RAM on the test system to 2GB.
The system is "thrashing" quite a bit and as the HDD in the system has a spindle, it is quite audible.
On occasions the widgets have failed to load and a refresh of the page will eventually bring up all the data.
I've not been able to reproduce the problem when the browser is unable to connect to the Web GUI.
I suspect your fundamental problem is due to defective RAM. However, I don't think it is defective in the region where the kernel is loaded - OPNsense would be crashing and most likely with a panic if it was.
I've included information from vmstat (systat -vmstat 1) as well as from top, as per Patrick's suggestion.
My production system has 16GB of RAM and I've never seen the RAM usage go up high, it's currently sitting just below 24%.
You need to identify what is using up all your memory - perhaps tables are being updated, though I think it is something else.
Do you have lots of tables being loaded from URL's in Aliases?
If you were to use a vanilla installation with rules to allow you connectivity to the Internet and to configure DNS in its most simplest form, may be the memory usage would be reduced. You could then add other services and see which one starts consume your RAM.
2Gb ram is not enough for GUI + widgets in the lobby + whatever services/plugins may be running.
Quote from: newsense on April 20, 2026, 12:10:57 AM2Gb ram is not enough for GUI + widgets in the lobby + whatever services/plugins may be running.
My very basic OPNsense configuration is using 2032 MB at this very moment so I think 4 GB or the recommended 8 GB RAM would be indeed the better choice.
However...
He has more than enough RAM and all of it is being "abused" by something somehow :
Quote from: roohoo on April 19, 2026, 05:55:52 PMAt the moment it's 93.48% - that's nearly 19GB!
That's pretty INSANE !!! :(
Disable Automatic Discovery.
Disable Automatic Discovery.
Disable Automatic Discovery.
...
What is this thread?
20561 days uptime is roughly 56 years. 2026 minus 56 is 1970.
Congrats, fix your hardware clock.
Cheers,
Franco
Quote from: franco on April 20, 2026, 12:48:08 PM20561 days uptime is roughly 56 years. 2026 minus 56 is 1970.
He's running a very old version. Worked great on ARPANET.
/*grin*
Quote from: franco on April 20, 2026, 12:48:08 PMWhat is this thread?
20561 days uptime is roughly 56 years. 2026 minus 56 is 1970.
Congrats, fix your hardware clock.
Cheers,
Franco
The hardware clock is working fine - and has been on all three completely different systems I have tried to run OPNSense on. The CMOS batteries had all been working fine too.
You've said a lot of things, but the math doesn't lie.
Cheers,
Franco
Quote from: franco on April 20, 2026, 12:48:08 PMWhat is this thread?
20561 days uptime is roughly 56 years. 2026 minus 56 is 1970.
Congrats, fix your hardware clock.
I don't think that's it :
- Why doesn't the whole system crash ?!
- When logged in via SSH there is nothing wrong with the uptime or the time & date ?!
Quote from: franco on April 20, 2026, 01:04:37 PMYou've said a lot of things, but the math doesn't lie.
Actually he still has not told us the hardware used of all these systems except for the Ryzen one that also had issues ?!
I still think it's the widgets tripping over the Power Saving or Clockspeed Switching of the CPU or something like that...
Quote from: connervt on April 20, 2026, 12:57:04 PMHe's running a very old version. Worked great on ARPANET.
/*grin*
LOL! NICE! ^_^
> I still think it's the widgets tripping over the Power Saving or Clockspeed Switching of the CPU or something like that...
One step at a time, but then again this also signals HW doubts.
Cheers,
Franco
Quote from: nero355 on April 20, 2026, 03:00:59 PMQuote from: franco on April 20, 2026, 12:48:08 PMWhat is this thread?
20561 days uptime is roughly 56 years. 2026 minus 56 is 1970.
Congrats, fix your hardware clock.
I don't think that's it :
- Why doesn't the whole system crash ?!
- When logged in via SSH there is nothing wrong with the uptime or the time & date ?!
Quote from: franco on April 20, 2026, 01:04:37 PMYou've said a lot of things, but the math doesn't lie.
Actually he still has not told us the hardware used of all these systems except for the Ryzen one that also had issues ?!
I still think it's the widgets tripping over the Power Saving or Clockspeed Switching of the CPU or something like that...
Quote from: connervt on April 20, 2026, 12:57:04 PMHe's running a very old version. Worked great on ARPANET.
/*grin*
LOL! NICE! ^_^
Thank you for your interest in my predicament!
System one was an HP ProDesk 400 G6 SFF with an Intel Core i5-9500 @ 3.00GHz, 8GB RAM. When I encountered issues, I tried swapping out various components including several different sticks of RAM, singly and in pairs, and various combinations of SATA and NVME drives including SSDs and spimming disks. I also tried different NICs including Intel x540, Intel x710, Intel i226, Intel 82571GB & Broadcom BCM5719 chipsets.
System two was a Dell Precision 3430 SFF with an i5-8500 @ 3.0GHz. 4GB RAM and a 256GB NVME drive. I tried swapping all the same RAM sticks, drives and NICs into this one too.
System three was a home-built Ryzen 3900x-powered machine with 128GB of RAM, an M.2 nvme drive, and a Quadro video card. Again, I swapped out the same components (RAM, drives, NICs)
All of these machines have yielded the same results with two different versions of OPNSense (25.x & 26.x).
I've been into the bios on each machine to ensure that all power-saving measures (c-states etc) are disabled.
The install is completely unmodified beyond interfaces: clean install with one WAN interface working with DHCP and one LAN interface with a 192.168.2.1/24 static IP address. DHCP is enabled over the range 192.168.2.50 - 192.168.2.199. One some of my attempts I have enabled various logging options and when running on systems with lots of RAM, I have enabled logging in RAM with a maximum of 10% permitted for each of the two types.
On my current install, I have not changed anything but the interfaces.
The only constant factor with each of my attempts is my home network. Could a faulty device sending malformed packets on my network take down OPNSense's webGUI?
If any of you are near (North) London, UK, you're very welcome to come and poke and prod my setup!
Quote from: Patrick M. Hausen on April 20, 2026, 08:39:56 AMDisable Automatic Discovery.
Disable Automatic Discovery.
Disable Automatic Discovery.
...
I shall investigate this when I get home this afternoon. Thanks.
Quote from: Patrick M. Hausen on April 19, 2026, 06:37:28 PMWith top running type "o" for order, than "res" for resident size followed by ENTER. Other possibilities are e.g. "swap" instead of "res". Lets try to find out who is using all that memory and why.
Also with the fresh install up and running could you try to disable Interfaces: Neighbors: Automatic Discovery?
And this!
Thank you.
Quote from: roohoo on April 20, 2026, 04:04:27 PMThe only constant factor with each of my attempts is my home network.
Could a faulty device sending malformed packets on my network take down OPNSense's webGUI?
Maybe... but it's a long shot...
You could Firewall the webGUI against all devices on your network and just allow one PC/Laptop that you know for sure is "clean" and see what happens ?!
Do you have any results from that friend you were talking about who you have given one of the systems to run on his network ?
At this point I hope Patrick is right and it's the Host Discovery Service messing around...
Quote from: Patrick M. Hausen on April 20, 2026, 08:39:56 AMDisable Automatic Discovery.
Disable Automatic Discovery.
Disable Automatic Discovery.
...
I really hoped that this was the solution, but no: Already disabled.
Not enabled ☹️
Quote from: nero355 on April 20, 2026, 07:07:47 PMDo you have any results from that friend you were talking about who you have given one of the systems to run on his network ?
I haven't got the machine to him yet. Hopefully later this week.
Quote from: nero355 on April 20, 2026, 07:07:47 PMAt this point I hope Patrick is right and it's the Host Discovery Service messing around...
Sadly not.
Another thing to be mindful of-
After you've checked & fixed the hardware clock issues and made sure to replace the battery, keep in mind that NTP will still fail to sync if the system time is significantly behind the real time (I think by 1000 seconds or more).
To get NTP working in OPNsense you need to make sure to set the system time close to the actual wall clock time and then restart the NTP service. You can use the FreeBSD 'date' command to do this.
I found this out the hard way on my Protectli that had a weak battery and NTP wouldn't sync after a power outage.
(Side note: the 'coreboot' UEFI on Protectli is very stripped down and at present doesn't have a method to set the system time, unlike the AMI BIOS, so it's left as a runtime activity for the user to set the clock. A good CMOS battery is important.)
Quote from: roohoo on April 20, 2026, 09:20:35 PMNot enabled ☹️
Prior to my previous post, I had disabled this option too, but its effect was inconclusive.
Yesterday afternoon (my time: GMT +08:00), I re-enabled the option and left it running overnight.
Looking this morning, this is how the process appears in top (time is BST) - viewed with and without listing threads:
Quotelast pid: 13247; load averages: 0.19, 0.30, 0.30 up 1+07:11:09 00:46:42
66 threads: 1 running, 65 sleeping
CPU: 0.3% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.6% idle
Mem: 75M Active, 101M Inact, 5424K Laundry, 466M Wired, 204M Buf, 1325M Free
Swap: 8192M Total, 189M Used, 8003M Free, 2% Inuse
PID USERNAME PRI NICE SIZE RES SWAP STATE C TIME WCPU COMMAND
94669 hostd 20 0 31M 2996K 0B bpf 3 0:01 0.00% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd{hostwatch}
94669 hostd 20 0 31M 2996K 0B uwait 2 0:01 0.00% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd{hostwatch}
last pid: 18592; load averages: 0.17, 0.29, 0.30 up 1+07:11:17 00:46:50
54 processes: 1 running, 53 sleeping
CPU: 0.6% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.4% idle
Mem: 75M Active, 101M Inact, 5424K Laundry, 466M Wired, 204M Buf, 1325M Free
Swap: 8192M Total, 189M Used, 8003M Free, 2% Inuse
PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME WCPU COMMAND
94669 hostd 2 20 0 31M 3008K 0B uwait 2 0:01 0.02% /usr/local/bin/hostwatch -c -S -p -P /var/run/hostwatch/hostwatch.pid -d /var/db/hostwatch/hosts.db -u hostd -g hostd
I've since rebooted this system and it is back to using 8GB of RAM.
Perhaps the issue could be something in the environment, like in this story - https://www.theregister.com/2026/04/17/on_call/?td=rt-4a
When you installed OPNsense on the new computers, did you restore the configuration from a file or did your reconfigure from scratch?
As far as I can ascertain, based upon these settings in OPNsense, FreeBSD will periodically write the OS time to the RTC;
- machdep.disable_rtc_set: 0
- machdep.rtc_save_period: 1800
There have probably been changes, but my understanding is that BSD would read the RTC at start-up and rely upon other sources for time whilst running. During shut down, the TOD would be written back to the RTC.
Perhaps you could post the current listing of /var/run/dmesg.boot.
At this time it appears you have two problems;
- OPNsense detects an anomaly whereby the uptime is reported to be around 50 years
- Your system is may be using excessive amounts of memory
Have you tried performing a Factory Setting of the BIOS and not making any changes to it and then installing OPNsense?
I don't have IPv6 in my environment so I can't test with this.
Did you alter anything in
Services:Network Time: General?
It may be worth removing all the listed servers here so OPNsense doesn't attempt to synchronise the time from an external source.
To obtain more information about the processes in top, you could use the following in a wide screen session;
top -awo res -s 1
Thank you for the suggestions regarding time, but the system time is perfectly correct and doesn't change. As you can see from the original screenshot I posted, it's only the webGUI reporting the uptime incorrectly. The Current- and Last configuration change- times are spot-on. The time reported by the date command in the shell is the same.
On each of the new machines, I have performed a clean, bare install and gone on to configure just the interfaces. I have not imported any configurations.
I have tried a complete return to BIOS factory settings as well as curating each BIOS option individually. Neither makes a difference. Google Gemini, ChatGPT and Grok all told me that the problem was almost certain to be (with the Intel chips) the c-states configuration but disabling this made no difference either.
I hope to get a chance to investigate where my RAM is going to this evening...
Again, thank you all.
Well let's trace what calculates the uptime then:
https://github.com/opnsense/core/blob/9f56b9ea20d721558ae6baec07ce5adb2afbed53/src/opnsense/www/js/widgets/SystemInformation.js#L42-L43
--->
https://github.com/opnsense/core/blob/9f56b9ea20d721558ae6baec07ce5adb2afbed53/src/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api/SystemController.php#L134
--->
root@opn-dev-02:~ # configctl system sysctl values kern.boottime
{"kern.boottime":"{ sec = 1776690464, usec = 852213 } Mon Apr 20 15"}
And here without configd as wrapper:
root@opn-dev-02:~ # sysctl kern.boottime
kern.boottime: { sec = 1776690464, usec = 852213 } Mon Apr 20 15:07:44 2026
If you are using AI it should be able to go from there to see what is wrong.
EDIT: Also if that is broken you are in FreeBSD territory, since OPNsense does not rewrite such a sysctl
Also very minor addition to this weird thread. Don't use .local as your domain suffix. It is reserved for mDNS (RFC 6762) and queries for it will never reach your DNS resolver. While at it also don't use .test, .example, .invalid and .localhost as they are also considered reserved per RFC 2606 and later RFC 6761.
I can imagine a lot of "weirdness" can be explained by this.
Quote from: Monviech (Cedrik) on April 21, 2026, 10:09:30 AMhttps://github.com/opnsense/core/blob/9f56b9ea20d721558ae6baec07ce5adb2afbed53/src/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api/SystemController.php#L134
Looking at this section of code and the image @roohoo has provided, which includes the
Load average being reported as "N/A", would it be reasonable to say the $boottime variable contained NULL values for kern.boottime and vm.loadavg, considering the count in line 139 was not satisfied for the load averages to be represented?
What exactly is returned with the command is something that is of the highest interest. I did find a small parsing error that was fixed by a collegue while looking at them.
Pretty sure that is not related to anything of here but it was a nice catch.
https://github.com/opnsense/core/commit/293e645d89edb53c7f3fd2388740f28f5ec50346
Quote from: roohoo on April 18, 2026, 06:49:10 PMThis is what my WebGUI looks like...
The other oddity in @roohoo's screen shot of OPNsense is the CPU widget which isn't listing the information about the CPU which is represented here;
https://github.com/opnsense/core/blob/9f56b9ea20d721558ae6baec07ce5adb2afbed53/src/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api/CpuUsageController.php#L42
Perhaps the high memory usage @roohoo is experiencing may all tie in with the System Information, CPU, Disk and Services widgets.
Quote from: lmoore on April 22, 2026, 03:20:26 PMPerhaps the high memory usage @roohoo is experiencing may all tie in with the System Information, CPU, Disk and Services widgets.
I was also wondering what would happen if you would remove all of them ?
Maybe things will quiet down ?!
Quote from: nero355 on April 22, 2026, 03:42:01 PMI was also wondering what would happen if you would remove all of them ?
The widgets @roohoo has is stock standard. The test machine I reconfigured to use 2GB of RAM had the same widgets. I set up 5 aliases using URL IP tables, each loading the same IP set of over 3-million entries. Enabling three tables was fine, keeping in mind this is a test system doing nothing more than loading and checking for updates of these IP tables every 30-minutes, plus other house keeping tasks.
When the 4th table was loaded thrashing was observed. After several minutes it would settle down. When the IP table was being checked/updated, the level of swapping was again evident.
When the 5th table was loaded, it never seemed to settle down. I was able to disable the aliases and bring it back down to only 3 being loaded - it took a while to happen, but it did happen.
When the memory was being hammered with swapping, the Memory widget doesn't show it so much with its graph, it's just at a point in time when the system gathers the information. Using systat to show vmstat information every second, RAM usage was often on 90%+ until it settled down.
Using top and watching the Swap activity, the numbers for paging in and out were quite evident and high.
That said, the worst I experienced on the test machine were the widgets failing to retrieve data - most evident with the 5th table loaded. They would often refresh themselves after a period of time but the Uptime never went out of whack.
Hopefully, @roohoo can get to the root cause of the issue.
Quote from: Monviech (Cedrik) on April 22, 2026, 02:44:13 PMPretty sure that is not related to anything of here but it was a nice catch.
https://github.com/opnsense/core/commit/293e645d89edb53c7f3fd2388740f28f5ec50346
I see. You are avoiding upsetting the apple-cart when a ":" is included in the data of a kernel state, e.g.;
dev.em.0.%location: slot=31 function=6 dbsf=pci0:0:31:6 handle=\_SB_.PCI0.GLAN
I agree, not in this case.
I don't believe it! I decided that I'd try reinstalling OPNsense as a VM under Proxmox so that Proxmox acted like a sort of Hardware Abstraction Layer. I even boosted the RAM to 64GB so that OPNSense could have 16GB.
The result: Exactly the same. The firewall appears to keep working, with all my network's devices keeping their Internet connectivity, but the webgui is displaying nonsense - with the characteristic 20000+ days uptime (the correct uptime, as displayed in the shell, being 1 hour 45 minutes).
I'm so disappointed as I thought that this might cure my issues - with Linux drivers handing virtual hardware to OPNsense, but it wasn't to be!
Please:
root@opn-dev-02:~ # sysctl kern.boottime
Quote from: roohoo on April 25, 2026, 05:05:55 PMI don't believe it! I decided that I'd try reinstalling OPNsense as a VM under Proxmox so that Proxmox acted like a sort of Hardware Abstraction Layer. I even boosted the RAM to 64GB so that OPNSense could have 16GB.
The result: Exactly the same. The firewall appears to keep working, with all my network's devices keeping their Internet connectivity, but the webgui is displaying nonsense - with the characteristic 20000+ days uptime (the correct uptime, as displayed in the shell, being 1 hour 45 minutes).
I'm so disappointed as I thought that this might cure my issues - with Linux drivers handing virtual hardware to OPNsense, but it wasn't to be!
That completely rules out the issue with opnsense. Your clients are broken, or something between your clients and opnsense.
The keyword is "webgui" here... as it seems, not even the time being off is present when using SSH.
When the problem occurs only on the web gui, it has to be the client, which means browser or some kind of plugin. I would try another browser first.
Quote from: meyergru on April 25, 2026, 06:39:26 PMThe keyword is "webgui" here... as it seems, not even the time being off is present when using SSH.
When the problem occurs only on the web gui, it has to be the client, which means browser or some kind of plugin. I would try another browser first.
But...
Quote from: roohoo on April 18, 2026, 06:45:13 PMI'm setting it running and then leaving it alone. Nothing configured except for the interfaces and ssh access. Every now and again I log in to see what it's up to. I log into it from a myriad of different machines running lots of different browsers but the results are always the same.
Should not be the issue then I guess ?!
Could still be a plugin or an antivirus engine.
Quote from: Monviech (Cedrik) on April 25, 2026, 05:29:52 PMPlease:
root@opn-dev-02:~ # sysctl kern.boottime
Also, after booting:
sysctl kern.msgbuf
I installed Sophos firewall to see how it fared. For the first 15 hours, it worked perfectly, then all internet access stopped. It had dropped the connection to my (Gigaclear) fibre modem. Rebooting the VM had no effect. Only physically turning off the machine and turning it back on worked.
I'm starting to think that my wildly unlikely hypotheses that something on my network - or Gigaclear's - is sending malformed packets that can kill a router might actually be the case.
I was going to try pfsense too, but I've lost my enthusiasm.
Sorry I didn't get to try your troubleshooting ideas but constantly changing my router got really old really fast and my wife and others grew most perturbed every time their connectivity was interrupted!
Thank you again.
If I decide to investigate the benefits of OPNsense again in the future, and the troubles remain the same, I'll report in on this thread.
Thank you all.
Quote from: roohoo on April 26, 2026, 03:06:02 PMI installed Sophos firewall to see how it fared. For the first 15 hours, it worked perfectly, then all internet access stopped. It had dropped the connection to my (Gigaclear) fibre modem. Rebooting the VM had no effect. Only physically turning off the machine and turning it back on worked.
I'm starting to think that my wildly unlikely hypotheses that something on my network - or Gigaclear's - is sending malformed packets that can kill a router might actually be the case.
Weird stuff... :(
So no results from any of your OPNsense machines at that friends house for now ??
I'm happy I found this thread as I'm suffering from the exact same problem on my private opnsense router.
The WebGUI is quite unreliable, the dashboard loads widgets only seldomly (oftentimes after a fresh restart) and my uptime shows the exact same weird value of 20611 days. Also other parts of the WebGUI, like for example the DHCP leases overview, often don't show information. A few page reloads later it might. System updates via the WebGUI don't work as well. Via SSH everything is fine.
Just to make things clear, system time seems to be fine.
root@fw:~ # sysctl kern.boottime
kern.boottime: { sec = 1778614567, usec = 705583 } Tue May 12 21:36:07 2026
top doesn't show high load, but I'm wandering why this machine swaps with 8GB of RAM.
last pid: 64090; load averages: 3.05, 10.70, 11.72 up 26+00:13:03 21:49:10
1559 processes:1 running, 1558 sleeping
CPU: 3.4% user, 0.0% nice, 14.2% system, 0.0% interrupt, 82.5% idle
Mem: 4147M Active, 47M Inact, 9520M Laundry, 1463M Wired, 56K Buf, 476M Free
ARC: 470M Total, 231M MFU, 109M MRU, 8365K Anon, 5040K Header, 117M Other
259M Compressed, 933M Uncompressed, 3.60:1 Ratio
Swap: 8192M Total, 3637M Used, 4555M Free, 44% Inuse, 12K In
I'm pretty sure it has to do with my configuration or something going havoc on the network. Any business opnsense installation i came across doesn't show this behaviour. But I ran out of ideas how to identify these problems? Any suggestions what to look for or which logs might be helpful?
Quote from: tschips on June 07, 2026, 10:10:20 PMBut I ran out of ideas how to identify these problems?
Any suggestions what to look for or which logs might be helpful?
Have you read the whole topic and done everything mentioned along the way ?!