Messages

Run this command and post here the output.

Code Select Expand

opnsense-update -p

Install OPNsense.

Import configuration.

Check for updates, after reboot check for updates again to retrieve all plugins. Reboot one last time.

So in ISC on the selected interface I disabled " Enable DHCP server on the <named> interface " option. Save and apply.

Back in KEA-select only the interface(s) for which I already recreated the vlan information and reservations- start service.

I had no issues running both KEA and ISC in parallel, each on their own interfaces/vlans, while working on moving the vlans from one to another.

One subnet at a time is not possible. ISC will "cling" to all interfaces even the ones it is not actively serving, so Kea cannot bind to any of them. It's all or nothing.

Funny story, when KEA first appeared in OPNsense this is exactly how I migrated 4 FWs with no downtime:

1) Create KEA vlan and migrate reservations

2) Stop ISC, remove vlan from the active pool, restart ISC and KEA and check DHCP on the KEA vlan.

3) Move on to the next vlan


I've no idea if or why things could have changed in the meantime.

Sam created this script to help migrating to either Kea or Dnsmasq and made a video about it on his YouTube channel —- unsure what happened with that video.

The repo is still available though:


https://github.com/sheridans/isc2kea

Try to update manually and post here the output:

Code Select Expand

opnsense-update -bkr 26.1.3
If no errors show up reboot the machine when asked.

As good as it gets. The warning will go away eventually whenever a newer pkg is ready.

Reinstall elastic with

# pkg install -f elasticsearch8


The rest looks good.

There are two options available in both Unbound and Dnsmasq that are not exposed in the GUI, that can help with minimizing the outbound DNS traffic.

—max-cache-ttl=<time>
Set a maximum TTL value for entries in the cache.
--min-cache-ttl=<time>
Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled.

It would be best to open a feature request ticket on GitHub OPNsense/core for this referencing this thread.

It is important to have these options to both resolvers since people may use one resolver or another.

What do you mean a manual complication? I did not install it manually. I run vanilla OPNSense.

OPNsense has extensive check to make sure the FreeBSD repos are disabled.


The fact you ended up with pkg from FreeBSD instead of the one from OPN means that the system was modified on purpose by "something" which in turn pulled packages from FreeBSD. This is why you're seeing the db version mismatch after you reverted pkg to the one in OPN.

The db warning is not catastrophic to my knowledge so you can continue to use the system as is.


More importantly though it may be possible to have there other packages from other repos that may cause trouble in the future.


For now it would be best to post here an audit so we can get a better understanding of where you're at.

ZFS or UFS ?

If on ZFS depending on how many logs and/or snapshots you have the disk may have run out of space during the update process.

If that's the case recovery will require a fresh install, importing the configuration and checking again for updates until both updates and plugins have been installed.


If on UFS there's still a chance to fix things if you can get to a terminal or console, make sure there's some free space available and then try to update again from there

If there's anything wrong in AGH the best way is to report it on GitHub. OPNsense doesn't control how AGH works.

AGH updates happen every 4-6 weeks, so as long as you don't see one published in GitHub there's no real reason to check for updates. AGH will notify you in the GUI as soon as an update is available

Does it mean it's random in your eyes ?

It is not random.

It is not a OPNsense issue.

I explained why it happened and how to consistently trigger it if you wish in a vm.

The way to think about this issue to avoid other accidents in the future is this:

Do not run out of space while the ZFS file system is modified during OS updates

If you would have been lucky enough to run out of space while the updates were downloading you would have been able to recover and avoid total data loss. Once the updates are being installed you're past the point of no return.

That number of requests is a bit high, I'm assuming they're coming from a lot of lists or aliases.

More importantly though, you're lacking a DNS caching capability.


I've solved this issue by having AdguardHome installed on the FWs and by setting up caching there, with a minimum of 20 minutes and a maximum of 40. Everything works fine and any misbehaving clients that ignore the above values and continue to make requests are served by AGH from cache.

If you know enough to play with Arch then install wireshark and see what happens after the DNS query. The giveaway here should be a bunch of retries right after the DNS reply, and then you can see what ip/port are being used and then check the live log on the FW for it