Messages

I saw #msg270385

It mentions php83-pecl-mongodb and that some people had that left over from a previous install of zenarmor. I had zenarmor till a few months ago. I suspect this was left over from then, and I didn't notice the crash error as the messages indicator isn't visible on the web interface on a small mobile phone screen which I use most of the time.

Anyway, I went ahead and deleted the package and restarted the webgui and the message is now gone.

After updating to 26.7.8 from 26.7.7 today, I get a crash report every second with these errors:

Code Select Expand

PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20250925/mongodb.so (Cannot open "/usr/local/lib/php/20250925/mongodb.so"), /usr/local/lib/php/20250925/mongodb.so.so (Cannot open "/usr/local/lib/php/20250925/mongodb.so.so")) in Unknown on line 0OPNsense seems to be working fine otherwise.

Since updating to 25.7.10 two days ago I am seeing rdr and nat rules showing up in the Firewall pie chart on the dashboard that i dont recall from before. They all have my pppoe address as the destination.

Is this something I might expect to see due to something changed in the update?

A day after making the above changes things look a lot healthier from the pihole side. PTR record requests are down and the OPNsense server is no longer the top client for DNS lookups. The lookups mentioned above are no longer featuring in any top lists.

Reading around they seem to be related to the bonjour protocol used by Apple devices.

I noticed that I had at some point added an entry to the 192.168.1.201 table in OPNsense for the domain * to my internal DNS.  I'm not sure why I added that since I don't mean to use DNSmasq in OPNsense for any DNS resolution other than receiving lookups from PiHole for reverse lookups of local devices.

I have removed that entry and confirmed it hasn't broken DNS on my network (yet), so I can observe over the next few hours whether this removes those lookups.

Looking at Pihole's query log it has many thousands of lookups for

• lb._dns-sd._udp.0.1.168.192.in-addr
• db._dns-sd._udp.0.1.168.192.in-addr.arpa
• b._dns-sd._udp.0.1.168.192.in-addr.arpa

coming from the OPNsense IP address. That's some kind of DNS discovery traffic.  Pihole was forwarding these back to OPNsense, so I think there is some kind of loop due to the entry I removed.

I use pihole as the DNS server on my network, with all clients told to use it via DHCP from DNSmasq running on my OPNsense box.

Daily I get warnings about rate limiting being applied to my OPNsense router's IP address, and OPNsense is making over 50% of DNS requests.

I have configured OPNsense to use only upstream DNS servers on the Settings > General page, and again for Zenarmor's DNS enrichment setting - so I would not expect the OPNsense server to be doing any DNS lookups via pihole at all.

Is there somewhere else that OPNsense might be configured to do DNS lookups?

I setup OPNsense at the same time I got a new Internet connection, so it was side by side with the old router which remained as the gateway for the old internet connection.

Old router: 192.168.1.1
OPNsense LAN interface: 192.168.1.2

I got everything working then switched over all the clients to use 192.168.1.2 as default gateway. This worked great. I then decommissioned the old router.

Now I want to set the IP of OPNSense LAN interface to 192.168.1.1 with as little downtime as necessary.

So I added 192.168.1.1 and 192.168.1 2 as virtual IP addresses for the interface. I can ping both and use as either as default gateway for clients. I then set the LAN interface IPv4 address as 192.168.1.1 and expected this to be used as the preferred IP for DHCP and other services, but 192.168.1.2 seems to be stuck.

I thought maybe it would fix itself after a reboot, which I needed to do anyway with the 26.7.8 release. But that doesnt seem to have changed things. For example DNSmasq DHCP clients are still issued 192.168.1.2 as their default gateway without this being specified anywhere.

If I delete the Virtual IP address all clients with it as their default gateway will lose access to the Internet.

What is the best way to resolve this and stop using 192.168.1.2 altogether? What happens if I delete the VIP 192.168.1.1 now that is configured under LAN interface? Is that safe?

Its interesting to note the privacy feature of Unbound.

Are there any technical downsides to just using DNSmasq for DHCP and Adguard for DNS on the OPNsense host and leaving Unbound turned off? 

Here's how I tried to fix it.

Connect monitor and keyboard to device.  The console didn't come up on the screen so I hit CTRL + ALT + DEL which rebooted OPNsense and I could see the boot process and got to the login screen. After logging in I saw a lot of lines relating to errors, so I pulled all the network cables which allowed me to interact with the CLI.

I then ran ifconfig to list all interfaces, and could see all the hardware offloading was enabled on igb0, igb1 and lo0,

I then ran these commands to disable all the offloading:

Code Select Expand

sudo ifconfig igb0 -txcsum -rxcsum -txcsum6 -rxcsum6 -tso -lro -vlanhwtag -vlanhwcsum -vlanhwfilter -vlanhwtso
sudo ifconfig igb1 -txcsum -rxcsum -txcsum6 -rxcsum6 -tso -lro -vlanhwtag -vlanhwcsum -vlanhwfilter -vlanhwtso
sudo ifconfig lo0 -txcsum -rxcsum -txcsum6 -rxcsum6 -tso -lro -vlanhwtag -vlanhwcsum -vlanhwfilter -vlanhwtso
These flags are referenced on https://docs.opnsense.org/manual/interfaces_settings.html

I confirmed this had worked with another ifconfig to see the current settings of the interfaces.

Unfortunately this didn't result in me being able to access the webgui, so I fell back to the recovery steps detailed at https://docs.opnsense.org/troubleshooting/config_reset.html and restored from a backup immediately before I enabled the hardware offsetting.  Once I rebooted I was able to login to the WebGUI and all was well again. Phew. 

I double checked that all the hardware offsetting is disabled and indeed it is.

os-auto-recovery-community sounds very helpful so I will go ahead and set that up now. Thanks for the suggestion meyergru!

Yeah - I read the docs (not what you linked but docs for Zenarmor and Suricata do say to disable offloading ) but did it anyway not realising the results of doing that would be so extreme :-)

Mistakes are better teachers than the manual...

I've done exactly the same thing just now, and can't access the web GUI.  It also seems to have stopped SSH from working.  But the internet connection is still up (for now).
I had enabled Zenarmor, and didn't realise that this had the same issues with hardware offloading as Suricata.
Do I really need to attach a monitor and keyboard to my hardware (which is in my dark basement) in order to resolve this?