Messages

I just run a very basic DNSMASQ to Unbound, which queries DNS over TLS to Control D.

The excessive DNS requests are a pretty recent phenomena, which I don't really understand either. It's occurring both randomly and infrequently during intervals where there is no activity, but I don't think that's something possible to pin down.

Looking for some thoughts or ideas regarding a DNS issue.

I use Control D (DNS over TLS through Unbound), which has an abuse policy that will block your IP for 24 hours if you exceed 3,000 queries a minute.

I also have several Amazon Echoes, which twice over that last two weeks started randomly spamming excessive requests in the middle of the night (over 50,000 requests in a 10 minute period to api.amazon.com).

As a result, when I wake up I have no DNS service available and have to shift to a less preferred backup. How would you guys go about resolving this problem? At the moment, the only thing I can think to do is set up an override in Unbound so that the API requests are sent to a specific IP instead of being forwarded...

As another data point, I upgraded to 25.1.8_1 without incident. I am running CrowdSec and using a GeoIP blocklist. I am in the U.S.

Are you blocking IP's in Ireland, and have rules set up to block both inbound and outbound?

I can't get CrowdSec services to run after the update, and I see someone else reported the same issue on Reddit.

Error    configd.py    Timeout (120) executing : crowdsec decisions-list
Error    configd.py    Timeout (120) executing : crowdsec alerts-list

I'm also seeing other report no issues. Any ideas?

Hi, I am the maintainer of the plugin and can't replicate the issue.

Could you please run

# cscli support dump

and send us the resulting file at support@crowdsec.net? It will send part of the configuration and some logs, nothing sensitive.

Also let me know if "cscli hub update" and "cscli hub upgrade" work without errors.

Thanks!

It's definitely GEOIP blocking that was the problem, and not a problem with CrowdSec or OPNsense. The service isn't starting if it can't connect to api.crowdsec.net, which appears to be running an IP in Ireland. If I reboot and leave the firewall rules in place, the service won't start. I have to modify or disable the rule to get it to start. It's a "me" problem.

Yes, I disabled the floating rules associated with IP block lists to get it working.

Besides GEOIP, then only other list I use is FIREHOL3... which I guess could also be the problem if it's running a false positive. I'm just used to GEOIP being the underlying problem behind something not working right.

For the others that were impacted, I identified the problem:

It's because of GEOIP block lists. I disabled my firewall block lists, and the service started running again.

I didn't realize this until after I reverted to 25.1.7_4, and the service still wouldn't start. Re-ran the update, and still wouldn't work. Turns out it was just firewall rules all along.

What country is CrowdSec running in? It's odd that this wasn't a problem up until today.

I can't get CrowdSec services to run after the update, and I see someone else reported the same issue on Reddit.

Error   configd.py   Timeout (120) executing : crowdsec decisions-list
Error   configd.py   Timeout (120) executing : crowdsec alerts-list

I'm also seeing other report no issues. Any ideas?

My understanding is that flowbit warnings can be ignored. If you're not running any servers, don't have open ports, and you're only running it on LAN then I don't think you're going to see much. Another reason you won't see much is because 90% or more of your traffic is likely encrypted, which Suricata can't monitor... a key reason many people don't bother running it at all.

To test your configuration, enable rule ""OPNsense-App-detect/test". Then open powershell and copy/paste this and press enter:

$url = "pkg.opnsense.org/test/eicar.com.txt"
$dest = "C:\temp\eicar.com.txt"
Invoke-RestMethod -Uri $url -OutFile $dest

It should hang up, and an alert will be generated saying "OPNsense test eicar virus".

Unbound on port 53, DNSmasq on port 53053, and set up the Unbound query forwarding in accordance with OPNSense docs:
https://docs.opnsense.org/manual/dnsmasq.html

I followed the examples at that link for my configuration, and it's running flawlessly for me across 5 different interfaces. Unlike the first person who responded to you, I feel like this was a pretty rock solid initial release for a lighter and more efficient DHCP. From what I've gathered between here and Reddit, the majority of the people having issues decided to wing it with their setup and didn't read the guides first.

For anyone that cares, the online guide spells most of this out in the examples section. At least three of your main points are explicitly covered, so I never ran into these issues when swapping over.

For anyone that is feeling apprehensive about doing this swap-over from ISC to DNSmasq:

I'm a complete idiot with a semi-complicated setup, and still got it working first try. The guide is dumbed down enough that I didn't have any issues, and everything is working perfectly fine. It did take me ~1 hour to do it since there were a lot more steps than the initial setup for ISC, but it wasn't difficult (just repetitive).

Same issue:

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

Same issue, but I was starting to have problems before 24.7.12. The token was expiring after approximately 5 days despite consistent heartbeats. I contacted ET Labs and they said they've received multiple reports of this and were looking into it.

Something has further degraded though... just like you guys, updating the token isn't fixing the issue anymore. I can't update ET Pro rules, the widget doesn't work, and I'm getting the same error in my logs as above. That said, I'm confident it's not an OPNsense issue.

Sorry to bring up an old thread, but this latest 24.7.7 update seems to have helped reduce the CPU utilization problem. I'm still not at pre-24.7 levels, but it's definitely a welcome steep drop I can see in my health reporting charts. Another user in the update thread on Reddit has posted the same positive observation.

Does anyone know what changed that improved this?

I also use a Protectli VP2420, and after the 24.7 update have had higher CPU temps and utilization. After a little research on things to mitigate the problem, I added the "dev.cpu.0.cx_lowest" tunables.

This reduced my CPU temps by ~4C, and haven't noticed any issues. I was concerned about possible stability or latency issues, but so far it has been a positive improvement.