Messages

If four hours isn't long engough for you, you can increase the timout in SYSTEM: SETTINGS: ADMINISTRATION: Session Timeout

I upgraded 5 systems from 24.7.4_1 to 24.7.5.  The first three with Crowdsec installed.  All three with Crowdsec returned to the Lobby without rebooting.  On all three, I then initiated a reboot, two of which rebooted fine, the third hung up hard and had to be power cycled to recover it.

For the next two, I uninstalled the Crowdsec plugin, then initiated the upgrade.  On both of these systems, the upgrade went exactly as expected.  One of them did return to the Lobby briefly before rebooting, but both did reboot on their own withour issue.  I then re-installed the Crowdsec plugin withour issue.

This is certainly a Crowdsec issue.

I have five more system to upgrade, but I'll wait for a hotfix to test on them.

Upgrade to 24.7 went smoothly.  However, I did notice a cosmetic issue with the CPU Widget.  I have a Core i5-1135G7 CPU with 4 Cores, 8 threads.  The Widget is reporting it as 8 Cores, 4 threads.

[net.link.ether.inet.max_age]

Some devices (modems, etc.) have a feature in that they stop responding if they have not received an ARP request for a couple of minutes. The cache of BSD based routers (such as OPNSense) is longer than that.

Try adding net.link.ether.inet.max_age=120 to tunables, which forces the router to re-arp every two minutes and often solves this issue.

I've been seeing this as well.  I thought it coorisponded with my CRON job that runs, "Update and reload firewall aliases" every night at 1:07am, but maybe it has nothing to do with that?

Why use DNScrypt? Unbound does DoT (yup, it works with dns.opendns.com also).

I prefer DoH.  It's just a personal preference.

Have you tried this?

https://www.reddit.com/r/opnsense/comments/16q3e76/fixing_mellanoxcard/

Why are you creating an out rule?  Stateful firewalls like OPNsense work best with all rules as in rules.

Personally, I'd rather that OPNsense respond exactly as it is described.  I'd hate to try troubleshooting why performance to my NAS on the same LAN/subnet was poor, only to discover that all traffic had to be routed through my firewall, when it obviously shouldn't be.  I don't see creating a rule to allow it to route within the same subnet as a viable solution to allow my NAS to beat the crap out of my router.  At least now you know the root issue is with your NAS and you can allow it if you choose, but I wouldn't.

I've seen Unbound go stupid like this many times, and the bigger your total block list entries, the more chance of it happening.  If you are using other systems for DNS, you might try removing all blocklists in Unbound and then try starting it again.

Thanks for the follow up.  It looks like a fairly easy fix:

https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1979

Very strange, but I ended up un-installing the DNSCrypt-Proxy plugin, and then reinstalling it, and that downgraded it, and now it works.  I have no idea where in the upgrade process it got upgraded in the first place, but the uninstall/reinstall sequence seems to fix it.

[2024-02-06 20:27:45] [NOTICE] dnscrypt-proxy 2.0.45

I also was using port 5353 before, but that stopped allowing it to start as well, so I changed to 5053:

127.0.0.1:5053 [::1]:5053

This appears to be a fairly old problem with DNSCrypt-proxy:

https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1979

After upgrading to to 24.1.1, my DNSCrypt-Proxy fails to start.  I even downloaded the config and removed the DNSProxy section from it and restored the config without it, and then tried starting DNSCrypt-Proxy with nothing configured and it still won't start.  I'm seeing this in the log:

[2024-02-06 18:45:48] [FATAL] Unsupported key in configuration file: [fallback_resolver]   

[2024-02-06 18:45:48] [NOTICE] dnscrypt-proxy 2.1.5

[Flush DNS Cache during reload]

I've been troublshooting this issue for months, and didn't fully realize it was Unbound until reading this post.  Now when my internet goes down, TOP shows the unbound process at 100%.  I block DoH, and intercept all DNS and forward all Unbound request to DNSCrypt-Proxy, which means I have no fallback when Unbound goes stupid.  When this setup works, it works wonderfully.  However, when it stops, all DNS queries on my network go unanswered.  Even with this patch my unbound process would end up at 100% utilization nightly and I had to kill -9 <pid> it to get it to recover.

For now I've switched to using DNSCrypt-Proxy native, and I haven't seen a problem in almost two weeks.  However, I'm willing to go back to Unbound in the name of testing and troubleshooting for any developer that is willing to look into fixing this. I just need hints of what to collect for when it goes stupid.

I do have Flush DNS Cache during reload enabled, which I now wonder if that exacerbated this issue.