This makes me want to cry! WebGUI instability on all different hardware!

[nero355]

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?

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...

[roohoo]

Disable Automatic Discovery.
Disable Automatic Discovery.
Disable Automatic Discovery.
...

I really hoped that this was the solution, but no: Already disabled.

[roohoo]

Not enabled ☹️

[roohoo]

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 ?

I haven't got the machine to him yet. Hopefully later this week.

At this point I hope Patrick is right and it's the Host Discovery Service messing around...

Sadly not.

[OPNenthu]

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.)

[lmoore]

Not 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:

last 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 I can test 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