Messages

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


These are the instructions I was provided by Zenarmor support to roll back to the previous stable version:

Code Select Expand

If you wish to reinstall the previous Zenarmor version, please follow these steps:
 
Edit the repository file at:
/usr/local/etc/pkg/repos/SunnyValley.conf
#url: "https://updates.zenarmor.net/opnsense/${ABI}/25.1/--nodeuuid--",
url: "https://repo.zenarmor.com/opnsense/${ABI}/25.1/latest",
 
save it.
 
pkg update
pkg install -fy os-sensei
 
I followed these instructions yesterday morning and ZA has been stable for the last 24 hours. I didn't need to revert any tunable changes.

Quick question, do you all have "Do not pin engine packet processor to dedicated CPU cores" checked or unchecked?
I had mine checked but I tried unchecking it now and will see if that does anything.
I have Suricata installed but not enabled for IPS mode.

Mine was unchecked. I didn't test with it checked.

Crashed again this morning with Suricata completely disabled. However, I could start it again from the dashboard page.

Zenarmor has provided instructions to downgrade to previous stable version, so I will roll back while the issue is worked on.

Further to this, I run Suricata on the WAN interface which has been perfectly fine and have not had any issues for months. Recently, Suricata has been very quiet and there have been no detections for several weeks. So, questioning its value, I've just disabled Suricata IDS/IPS. I am now able to start the Zenarmor packet engine and it stays running.

One to note for troubleshooting purposes and maybe a workaround while this is resolved.