"Recent posts
#91
25.1, 25.4 Series / Re: unable to update and openV...
Last post by aniki - December 16, 2025, 04:01:21 AMIt comes back to why the ntp is not working
#92
Intrusion Detection and Prevention / Please updating the Default DN...
Last post by Armani - December 16, 2025, 03:09:08 AMDear OPNsense Team,
I would like to suggest a more frequent update cycle for the default blocklists available in the system, specifically in the Services: Intrusion Detection (Suricata Rules) and Services: Unbound DNS: Blocklists sections.
Please verify and maintain the default list sets in the Services: Intrusion Detection and Services: Unbound DNS: Blocklists sections.
The problem is that in the current configuration, some links to sources are inactive (the lists have been removed by their authors), and some new expected lists are missing from the default OPNsense packages/configuration.
For example, the Unbound DNS: Blocklists ruleset lacks lists of the most abused top-level domains (TLDs) Normal and Aggressive, the same applies to Suricata, as the collections lists are not up-to-date.
Please ensure that these lists are regularly updated and supplemented to ensure all default lists are up-to-date, accessible, and functional. Including more comprehensive and regularly updated community lists would significantly improve the default security level of OPNsense installations.
The current infrastructure for downloading these lists is excellent; this request only concerns updating the default sources.
Thank you for considering this enhancement.
I would like to suggest a more frequent update cycle for the default blocklists available in the system, specifically in the Services: Intrusion Detection (Suricata Rules) and Services: Unbound DNS: Blocklists sections.
Please verify and maintain the default list sets in the Services: Intrusion Detection and Services: Unbound DNS: Blocklists sections.
The problem is that in the current configuration, some links to sources are inactive (the lists have been removed by their authors), and some new expected lists are missing from the default OPNsense packages/configuration.
For example, the Unbound DNS: Blocklists ruleset lacks lists of the most abused top-level domains (TLDs) Normal and Aggressive, the same applies to Suricata, as the collections lists are not up-to-date.
Please ensure that these lists are regularly updated and supplemented to ensure all default lists are up-to-date, accessible, and functional. Including more comprehensive and regularly updated community lists would significantly improve the default security level of OPNsense installations.
The current infrastructure for downloading these lists is excellent; this request only concerns updating the default sources.
Thank you for considering this enhancement.
#93
25.7, 25.10 Series / Memory protection faults
Last post by teb - December 16, 2025, 02:27:36 AMI have been getting a lot of memory protection faults in the last couple weeks. This is on an official OpnSense DEC2750. I am thinking the RAM has gone south, so I was going to order replacement. It looks like it is DDR4, but in what configuration? 2x4GB?
I got this a while ago, so I can't imagine there is a warranty on it that is still valid.
Is there something else I should look at?
Thanks,
Travis
I got this a while ago, so I can't imagine there is a warranty on it that is still valid.
Is there something else I should look at?
Thanks,
Travis
system_20251213.log:<13>1 2025-12-13T22:39:54-05:00 mira.domain.org kernel - - [meta sequenceId="228"] <118>[4] savecore 245 - - reboot after panic: general protection fault
system_20251214.log:<13>1 2025-12-14T02:41:49-05:00 mira.domain.org kernel - - [meta sequenceId="190"] <118>[4] savecore 230 - - reboot after panic: general protection fault
system_20251214.log:<13>1 2025-12-14T15:27:22-05:00 mira.domain.org kernel - - [meta sequenceId="190"] <118>[4] savecore 237 - - reboot after panic: general protection fault
system_20251214.log:<13>1 2025-12-14T18:40:23-05:00 mira.domain.org kernel - - [meta sequenceId="189"] <118>[4] savecore 245 - - reboot after panic: page fault
system_20251214.log:<13>1 2025-12-14T22:32:22-05:00 mira.domain.org kernel - - [meta sequenceId="189"] <118>[4] savecore 230 - - reboot after panic: general protection fault
system_20251214.log:<13>1 2025-12-14T23:29:41-05:00 mira.domain.org kernel - - [meta sequenceId="19"] [3391] panic: general protection fault
system_20251214.log:<13>1 2025-12-14T23:29:41-05:00 mira.domain.org kernel - - [meta sequenceId="24"] [3391] vpanic() at vpanic+0x161/frame 0xfffffe00cdb97ae0
system_20251214.log:<13>1 2025-12-14T23:29:41-05:00 mira.domain.org kernel - - [meta sequenceId="25"] [3391] panic() at panic+0x43/frame 0xfffffe00cdb97b40
system_20251214.log:<13>1 2025-12-14T23:29:41-05:00 mira.domain.org kernel - - [meta sequenceId="36"] [3391] KDB: enter: panic
system_20251214.log:<13>1 2025-12-14T23:29:41-05:00 mira.domain.org kernel - - [meta sequenceId="224"] <118>[4] savecore 225 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T01:00:54-05:00 mira.domain.org kernel - - [meta sequenceId="26"] [5421] panic: general protection fault
system_20251215.log:<13>1 2025-12-15T01:00:54-05:00 mira.domain.org kernel - - [meta sequenceId="31"] [5421] vpanic() at vpanic+0x161/frame 0xfffffe00cbdeeaa0
system_20251215.log:<13>1 2025-12-15T01:00:54-05:00 mira.domain.org kernel - - [meta sequenceId="32"] [5421] panic() at panic+0x43/frame 0xfffffe00cbdeeb00
system_20251215.log:<13>1 2025-12-15T01:00:54-05:00 mira.domain.org kernel - - [meta sequenceId="46"] [5421] KDB: enter: panic
system_20251215.log:<13>1 2025-12-15T01:00:54-05:00 mira.domain.org kernel - - [meta sequenceId="235"] <118>[4] savecore 225 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T01:42:09-05:00 mira.domain.org kernel - - [meta sequenceId="190"] <118>[4] savecore 225 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T08:09:38-05:00 mira.domain.org kernel - - [meta sequenceId="19"] [23193] panic: general protection fault
system_20251215.log:<13>1 2025-12-15T08:09:38-05:00 mira.domain.org kernel - - [meta sequenceId="24"] [23193] vpanic() at vpanic+0x161/frame 0xfffffe00ce2e6b70
system_20251215.log:<13>1 2025-12-15T08:09:38-05:00 mira.domain.org kernel - - [meta sequenceId="25"] [23193] panic() at panic+0x43/frame 0xfffffe00ce2e6bd0
system_20251215.log:<13>1 2025-12-15T08:09:38-05:00 mira.domain.org kernel - - [meta sequenceId="36"] [23193] KDB: enter: panic
system_20251215.log:<13>1 2025-12-15T08:09:38-05:00 mira.domain.org kernel - - [meta sequenceId="224"] <118>[4] savecore 230 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T12:27:42-05:00 mira.domain.org kernel - - [meta sequenceId="189"] <118>[4] savecore 230 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T14:43:39-05:00 mira.domain.org kernel - - [meta sequenceId="190"] <118>[4] savecore 227 - - reboot after panic: general protection fault
system_20251215.log:<13>1 2025-12-15T19:42:24-05:00 mira.domain.org kernel - - [meta sequenceId="19"] [17876] panic: general protection fault
system_20251215.log:<13>1 2025-12-15T19:42:24-05:00 mira.domain.org kernel - - [meta sequenceId="24"] [17876] vpanic() at vpanic+0x161/frame 0xfffffe00ca10f420
system_20251215.log:<13>1 2025-12-15T19:42:24-05:00 mira.domain.org kernel - - [meta sequenceId="25"] [17876] panic() at panic+0x43/frame 0xfffffe00ca10f480
system_20251215.log:<13>1 2025-12-15T19:42:24-05:00 mira.domain.org kernel - - [meta sequenceId="43"] [17876] KDB: enter: panic
system_20251215.log:<13>1 2025-12-15T19:42:24-05:00 mira.domain.org kernel - - [meta sequenceId="231"] <118>[4] savecore 243 - - reboot after panic: general protection fault
#94
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by meyergru - December 16, 2025, 01:10:51 AMThe setting alters the way the incoming packets (which are signaled via interrupts) are handled, namely directly or deferred, by putting it into a queue to handle multiple packets more effiently in one go rather than immediately. There are some more tuneables in net.isr to limit how long the queue can get and others:
See this discussion: https://github.com/opnsense/core/issues/5415 and many others about the neccessity of this setting (i.e. either deferred or hybrid) for ppp-type links.
The general recommendation for PPPoE on WAN is to use:
However, different NIC types also have different handling. Some NICs coalesce multiple packets into only one interrupt in hardware already, so a hardware switch can make things different.
Code Select
net.isr.numthreads
net.isr.maxprot
net.isr.defaultqlimit
net.isr.maxqlimit
net.isr.bindthreads
net.isr.maxthreads
net.isr.dispatch
See this discussion: https://github.com/opnsense/core/issues/5415 and many others about the neccessity of this setting (i.e. either deferred or hybrid) for ppp-type links.
The general recommendation for PPPoE on WAN is to use:
Code Select
net.isr.dispatch: deferred or hybrid
net.isr.maxthreads: -1
net.isr.bindthreads: 1
However, different NIC types also have different handling. Some NICs coalesce multiple packets into only one interrupt in hardware already, so a hardware switch can make things different.
#95
General Discussion / Re: Why I am retiring from con...
Last post by allan - December 16, 2025, 12:57:15 AM[ scratch that. I should not post out of frustration especially when I am unable to gather more info to help troubleshoot. ]
#96
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by passeri - December 16, 2025, 12:21:39 AMQuote from: lukas.liechti on December 15, 2025, 07:10:08 PMAdd another tunable. This time, we're allowing NIC drivers to use ISR queues.Code Selectnet.isr.dispatch = deferred
Lukas, I was aware of the other tunables but I did not find this particular one in the Opnsense docs, whether on the page yourreference or in a search. I did find it offered by Gemini.
Are you able to comment further on the source for this one please, and its actual effects? My reading of the referenced page is that it may be unnecessary.
#97
General Discussion / Re: Doubt about IP Scans comin...
Last post by drosophila - December 15, 2025, 11:37:49 PMYes, that's perfectly normal. And also yes, the consumer routers don't even bother to create such logs, as they're not useful to their intended audience (since the average user couldn't do anything about it, anyway) and in fact more likely to cause the effect you experienced. ;)
Skimming these screenshots, there seems to be only a single instance of an actual "port scan" in the traditional sense, which is the one coming from 185.246.128.192. All others either are "trickle scans" (which is unlikely, you only use these when you have a specific mark and know they're looking out for scans) or just misdirected connection attempts by legitimate users. These come from outdated dynamic address info, which you get literally on a daily basis with IPv4 (the entire point of using DynDNS services). Most are single connects, which could be looking for one specific service to (ab)use (probably some IoT stuff, which has a high probability of being both outdated and unprotected. Maybe a botnet trying to find peers.). But then again, the ports wouldn't differ so much (IMO). If you're curious, you could try looking up these ports to see what they might be after. Or it might just be what happens when something like bittorrent is started with a cache more than a few weeks old. And then look at the guy on 45.142.193.191, several attempts to the same port (52073). Probably someone trying to connect to their buddies self-hosted game server. Or someone about to find out that their own DynDNS had failed, as happened to me more than once. :) You'd probably see a few pings afterwards the first time they experience that. ;)
So, as has been said: make certain to only have ports open that you know about, and then make certain these services are protected as good as you can manage, and also run only when they actually need to run. The really dangerous stuff would appear in green, indicating something was allowed through. So you'd filter for unexpected connection attempts to the services you do have open and check the logs of these services. You could also try to find any suspicious activity from their pattern (if there is any), and then ponder what could possibly be done to prevent that.
For a while I was wondering about the lucky chance of someone probing a port that has been opened for replies to an outgoing request, but that's why firewalls track those (this is the "state violation" part of the message). Note that if you open some port for games or such you'll not be in immediate danger when the game isn't running: the packet will be allowed into the LAN, reach your PC and then go poof. However, your system will send an ICMP error message, so the attacker knows that a system is reachable on that port, but has nothing there. So it could be used to map you out and plan an attack based on that info, but attackers are lazy and will just move on to find easier prey. Especially with your IP address changing daily, they'd lose track of you unless they are tracking your IP. In that case, you should indeed be worried, but of course you'll never know about that until it's too late (or not even then).
So, the net sure has become busier than a decade ago, but that's a given with the number of devices and people connected. More noise, and more potential victims.
Ransomware usually arrives through email. Basically, anything with an attachment definitely is, and anything without has links to either phishing or more malware. This has always been the most successful attack, and its likelihood of working against you increases with every account you create: more places to steal information from, more information to be stolen, more context to create a believable scam. Currently, there seems to be quite the success with "Payment declined: your cloud data is in immediate risk of being deleted". Of course this works better than the "African prince inheritance fund" scam, because so many people made the mistake of using cloud storage services. Yes, I think it's a liability for businesses, too.
BTW: please correct me if any of my conclusions or reasonings are flawed!
Skimming these screenshots, there seems to be only a single instance of an actual "port scan" in the traditional sense, which is the one coming from 185.246.128.192. All others either are "trickle scans" (which is unlikely, you only use these when you have a specific mark and know they're looking out for scans) or just misdirected connection attempts by legitimate users. These come from outdated dynamic address info, which you get literally on a daily basis with IPv4 (the entire point of using DynDNS services). Most are single connects, which could be looking for one specific service to (ab)use (probably some IoT stuff, which has a high probability of being both outdated and unprotected. Maybe a botnet trying to find peers.). But then again, the ports wouldn't differ so much (IMO). If you're curious, you could try looking up these ports to see what they might be after. Or it might just be what happens when something like bittorrent is started with a cache more than a few weeks old. And then look at the guy on 45.142.193.191, several attempts to the same port (52073). Probably someone trying to connect to their buddies self-hosted game server. Or someone about to find out that their own DynDNS had failed, as happened to me more than once. :) You'd probably see a few pings afterwards the first time they experience that. ;)
So, as has been said: make certain to only have ports open that you know about, and then make certain these services are protected as good as you can manage, and also run only when they actually need to run. The really dangerous stuff would appear in green, indicating something was allowed through. So you'd filter for unexpected connection attempts to the services you do have open and check the logs of these services. You could also try to find any suspicious activity from their pattern (if there is any), and then ponder what could possibly be done to prevent that.
For a while I was wondering about the lucky chance of someone probing a port that has been opened for replies to an outgoing request, but that's why firewalls track those (this is the "state violation" part of the message). Note that if you open some port for games or such you'll not be in immediate danger when the game isn't running: the packet will be allowed into the LAN, reach your PC and then go poof. However, your system will send an ICMP error message, so the attacker knows that a system is reachable on that port, but has nothing there. So it could be used to map you out and plan an attack based on that info, but attackers are lazy and will just move on to find easier prey. Especially with your IP address changing daily, they'd lose track of you unless they are tracking your IP. In that case, you should indeed be worried, but of course you'll never know about that until it's too late (or not even then).
So, the net sure has become busier than a decade ago, but that's a given with the number of devices and people connected. More noise, and more potential victims.
Ransomware usually arrives through email. Basically, anything with an attachment definitely is, and anything without has links to either phishing or more malware. This has always been the most successful attack, and its likelihood of working against you increases with every account you create: more places to steal information from, more information to be stolen, more context to create a believable scam. Currently, there seems to be quite the success with "Payment declined: your cloud data is in immediate risk of being deleted". Of course this works better than the "African prince inheritance fund" scam, because so many people made the mistake of using cloud storage services. Yes, I think it's a liability for businesses, too.
BTW: please correct me if any of my conclusions or reasonings are flawed!
#98
Q-Feeds (Threat intelligence) / Re: Looking for testers Q-Feed...
Last post by Q-Feeds - December 15, 2025, 10:58:52 PMQuote from: Maurice on December 15, 2025, 10:40:14 PMThere no longer is a global "enable blocklists" setting in Unbound since the business implementation was merged into the community version in 25.7.8.
If you want to use the Q-Feeds blocklist exclusively, does this mean you only have to enable "register domain feeds" in the Q-Feeds settings and don't have to configure anything in Unbound?
Oh my mistake, yes on the latest version you only need to enable it in our plugin indeed.
#99
General Discussion / Re: Why I am retiring from con...
Last post by Greg_E - December 15, 2025, 10:48:00 PMCould it be from our "friends" on another project? Wouldn't be the first time, so history might repeat itself here.
#100
Q-Feeds (Threat intelligence) / Re: Looking for testers Q-Feed...
Last post by Maurice - December 15, 2025, 10:40:14 PMThere no longer is a global "enable blocklists" setting in Unbound since the business implementation was merged into the community version in 25.7.8.
If you want to use the Q-Feeds blocklist exclusively, does this mean you only have to enable "register domain feeds" in the Q-Feeds settings and don't have to configure anything in Unbound?
If you want to use the Q-Feeds blocklist exclusively, does this mean you only have to enable "register domain feeds" in the Q-Feeds settings and don't have to configure anything in Unbound?
