Messages

I just got this rather scary message during the update to 25.7.6. The update appeared to stop.

I couldn't log in at the console, I got this error:

Password:
sh: /usr/local/libexec/opnsense-auth: not found
Login incorrect

The GUI then gave a 404 error.

After a couple of minutes it sprang back into life.

I've never seen this behaviour before - is it expected?

The update appears to have now completed successfully, as far as I can tell.

I had the same "Danger. Unexpected error, check log for details" error but when I refreshed the OPNsense main dashboard page, version updated to 25.7.6 and a check for updates came back with "There are no updates available on the selected mirror".

I am reluctant to reboot in case I'm left with a broken OPNsense.

Is there anything I can check to ensure a reboot will succeed?

Just checked the other way by configuring only "Register domain feeds" and unticking all in "Type of DNSBL".

Now the "Size of blocklist" number does change. I assume that this number should tally with the number reported on TIP?

E.g. with no other blocklists ticked, the size of blocklist number is 358,597. However, the previous count from TIP is 438,574 and current is 539,551 using the numbers from my current plan (free edition).

There seems to be an anomally.

Installed, registered and now have blocked information in the widget. Nice and slick :-)

One question though. I've ticked the box to register domain feeds after confirming Unbound has blocklists enabled. Am I supposed to see a q-feeds specific blocklist appear in the "Type of DNSBL" drop-down?

If so, there's nothing there for q-feeds, just the default. I've tried disable/enable blocklist, Unbound restart, and uncheck/check of "register domain feeds".

Hi RutgerDiehard,

No you're not supposed to see our list in that dropdown. If both are activated (in our plugin and blocklists in general in unbound) then the list is active. You can verify by checking the number of IOCs in the Unbound report. It might be something we will improve later on though ;)

Thanks for the quick reply :-)

I assume you mean by looking at the "Size of blocklist" in the Unbound DNS report?

If I untick "Register domain feeds" in q-feeds and recheck the "Size of blocklist" number, it does not change.

Is this correct or am I looking in the wrong place?

Installed, registered and now have blocked information in the widget. Nice and slick :-)

One question though. I've ticked the box to register domain feeds after confirming Unbound has blocklists enabled. Am I supposed to see a q-feeds specific blocklist appear in the "Type of DNSBL" drop-down?

If so, there's nothing there for q-feeds, just the default. I've tried disable/enable blocklist, Unbound restart, and uncheck/check of "register domain feeds".

I have OPNsense continuously open in a tab in my browser and regularly check logs, Zenarmor live sessions and dive in for general tweaking.

I also have my OS theme change depending on the time of day; dark at night, light during the day. Generally, all my sites will follow suite such as Facebook, Unifi, Portainer etc. etc. It would be awesome if OPNsense was able to follow the OS or browser theme automatically.

I imagine it would work by choosing a "Light" theme in Settings -> General and an opposing "Dark" theme. A toggle button would then allow "Automatic" adjustment based on system settings.

For me, this would complete an otherwise excellent product. Would love to hear others thoughts on this.

Yes, I see the same after upgrading to 25.7; nothing in Reporting -> Insight at all.

This is what worked for me:

Code Select Expand

ifctl -6pi pppoe0

OPNsense updates just offered a Netdata update which I installed. When I attempt to access Netdata on http://[IP]:19999, I get "File does not exist, or is not accessible:" message.

I've tried removing and then reinstalling with the same result.

Not had any issues with Netdata previously so I assume it's the update that's broken it.

Stumbled across another thread with similar sounding symptoms which has been fixed by an update here https://github.com/opnsense/core/issues/8797

I applied the fix, removed a device from a network and connected to another. Then reconnected the device back to the original network. Now when I check Adguard Home/nslookup the host has the correct DNS name.

Looks like this fixes the issue I'm experiencing!

I do have to connect to a new network, then change back to the original for DNS to reflect the correct host.domain name. Simply resetting the network adapter does not work.

Is there a way of removing all current hosts registered via DHCP6 so when they renew their addresses, they will automatically register the correct domain?

Sounds like this may also apply to my issue here https://forum.opnsense.org/index.php?topic=47488.0

Is it worth trying the patch to see?

Hi all,

Thank you for your patience. We've identified a fix for the issue and are currently testing it. If you'd like to test it as well, please reach out to support for detailed instructions. The fix is scheduled to be included in the 2.0.1 maintenance release later this week.

2.0.1 was offered as an upgrade yesterday after checking for updates in OPNsense. I've installed, removed and re-added my subscription key - to enable additional device and policy support - and can confirm the packet engine is running without issue this morning.

I had incredibly flakey IPV6 performance with a PPPoE connection. In the end, changing the WAN MTU fixed it completely.

For Windows, I used this to determine what the MTU should be https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

I've made some changes to my current configuration - basically, I'm rolling out IPV6 to additional VLANs within my environment - and I've noticed some strange behavior with DNS registrations. I had hoped that this was a known issue but as my first post had no responses, I thought it may have been an error in my configuration.

So I've been back through the configuration to make sure I've not made any mistakes.

My configuration is as follows:

Adguard home running on DNS port 53
dnsmasq running on 53053
Unbound running on 65353

Adguard home is configured to send all queries to 127.0.0.1:65353. It also uses 127.0.0.1:65353 for Private Reverse DNS Servers with "Use private reverse DNS servers" and "Enable reverse resolving of clients' IP addresses" ticked.

Unbound has query forwarding for all internal domains and in-addr.arpa/ip6.arpa sent to 127.0.0.1:53053 with external resolvers using DoT to Google/Cloudflare.

With this configuration, everything works. Adguard home shows correct host names in its console, reports in OPNsense (traffic and Insights) show correct hostnames and Zenarmor reporting/live sessions show correct hostnames also.

I have a ::/56 prefix from my ISP which I have created multiple /64 ranges. For each range, I have created a static IPV6 address and assigned it to the interface I want to provide IPV6 addresses on. I then create a DHCP6 range in dnsmasq with the correct interface, start address within the range and end address. No constructor and a prefix length of 64. RA mode as default and use domain of domain.internal.

When I enable Router Announcements in dnsmaq and reset my network adapter, I get an IPV6 IP from the correct range and all external IPV6 test sites work correctly. At this point reverse DNS for hostname (host.domain.internal) resolution works successfully.

Then I add a new IPV6 address to another interface and create a new DHCP6 range for this interface with a new domain - domain2.internal, I then add a device to the new VLAN and it correctly gets a new IPV6 address from the correct range. I check in Adguard home, OPNsense, or manually run an nslookup for the IPV6 address, the reverse DNS is also correct for the new range.

However, If i reset the adapter of the first device - host.domain.internal - that sits in the first domain, it picks up the correct IPV6 address but its DNS name is registered as host.domain2.internal. This is shown whether I check Adguard Home console or use nslookup.

Interestingly, OPNsense Reporting -> Traffic -> Top Talkers does not resolve an IPV6 address to a hostname but it will for an IPV4 address.

So, has anyone seen this before? Is there anything I can check or test to see where this is going wrong?

I've used static IPV6 addresses in this example but I've also followed the instructions and used tracked WAN address and constructors in the DHCP6 ranges; the result is the same.

This has been increased in version 2.0.

Version 2.0 release notes:

Code Select Expand

Improvement
Home edition now supports 200 devices and 5 policies (1 Default + 4 Customizable).