Messages

You can either wait for 25.1.6 next week or install OPNsense in a couple VMs - switch to development train and check for updates - then start playing with Dnsmasq DNS & DHCP - which is where probably most people will end up when ISC goes away.


I don't see much development done on KEA github, and the mere fact the OPNsense team decided to invest the time and effort into Dnsmasq DHCP after the initial KEA integration should be a good indication on where things are. Feature wise there's a ton more stuff you'll be able to do with Dnsmasq DHCP compared to what was possible in KEA - right out of the gate.


Bottom line, sure you have an issue. If it would have been up to the OPNsense team I'm pretty sure it would have been solved a while ago.
Given the new perspective I tried to depict above it's probably best to cut your losses and start preparing for better times than hoping magic will suddenly happen overnight in KEA land.

It's better to delete it instead, repair isn't very reliable.

Even better if you can get rid of it altogether.


At the very least delete it regularly before or after upgrades, so at the very least you'll know the DB is small and healthy.

Please open a new thread for your issue

Try this one

https://www.zenarmor.com/docs/network-security-tutorials/how-to-configure-ipsec-site-to-site-vpn-tunnel-on-opnsense

A reddit user has suggested updating the i226-V drivers which I'm going to test once I figure out how too with FreeBSD (lol)

Also found this reddit sub talking about how unstable the i226-V is... wondering if I done effed up getting this mini server - Reddit Post

This is bonkers, there's no driver to update outside regular OPNsense updates. Once the DNS issue is addressed you're good to go

Is unbound running there ? Do you see anything relevant in the logs ?

Did you change any of the default settings related to DNS ?


If you add 1.1.1.1 to System - Settings - General can you update the FW ?

The problem seems to be that using an dynDNS FQDN CNAME entry as `Local addresses` (e.g.  jashdejvmiuqlachhsqaxs.siteb.example.com), is not acceptable, as the other side sends an actual IP (41.41.41.41), for which the comparison fails.

I'm using FQDNs updated dynamically both for local and remote without issues.

[os-cpu-microcode-intel-1.1]

As long as you can browse the internet without other issues I don't see how this is HW related. The only thing missing and required by that CPU is the os-cpu-microcode-intel-1.1 package and that's an easy fix once the main issue is addressed.


You haven't said anything about DNS configuration/troubleshooting and update mirror you're trying. What is the output for these commands on the FW ?

Code Select Expand


 host opnsense.org

  host opnsense.org 1.1.1.1


Also from a machine in the LAN

Code Select Expand


 nslookup opnsense.org

 nslookup opnsense.org 1.1.1.1


Conflicting/outdated packages/repos are always gonna be problematic and the only proper course of action is to have those packages updated in their own repos.

Unsure what you're using there other than ZA, however forcing things in the CLI is not the proper way to fix things.

[import the config file - check for updates - reboot]

The other pain was the fact that we have a config backup, but the plugins (and their config/data) are not restored. Now I'm back on track, almost, but some plugins I still have to configure them. Tailscale for some reason is not behaving properly, but I'll check later, will probably reinstall it from scratch.

Question is: to prevent this from happening in the future, and shorten the restore cycle, what should I do? take a full image of the drive by pulling it out of the system every once in a while? isn't there a better way to achieve this?

For the official OPNsense plugins all you need to do is to import the config file - check for updates - reboot. The plugins will all be downloaded for you and upon reboot the FW will be working as expected with no additional configuration required.

For third party repos you'll need the configuration file of that plugin you're using, as it is not saved in the OPNsense one.

OPNsense 25.1.5_4 is now available and has a couple more captive portal fixes

Yes that's the path forward right now, the drive is still the unknown here.

Can anyone tell me if this bug has been resolved?  I'd be ready to update to current if it is....

Thanks to anyone who can help.

GM

Fastest way is to take a snapshot and upgrade to 25.1.5.

Leave ZA alone, there are no reports about it not working in 25.1.5. If you're on 25.1.4 then you need to upgrade first and then follow the steps below, as you might be encountering the lighttpd issue that was fixed in 25.1.5


Follow the steps mentioned here by Ad and Franco:

https://forum.opnsense.org/index.php?topic=46775.0

Just upgraded to 25.1.5 and it didn't reboot. Hooked up a monitor to see what was going on, and it can't mount root: unknown filesystem.

I took a snapshot before the upgrade, as I always do, but I can't see the usual menu that allows me to rollback to a chosen snapshot.

I'm at a mountroot> prompt, I guess it's expecting I specify a filesystem, I used zfs, but none of the ones I tried worked.

Any suggestion??

Drive full or dying most likely. Are you sure you're not skipping over the boot menu ? if that appears you could try booting the old kernel - just in case the new kernel wasn't installed properly.

Try a fresh install, see how the drive behaves.