"Recent posts
#21
25.7, 25.10 Series / Re: Issue with Kea DHCP server
Last post by coatmaker618 - Today at 05:21:42 AMA much belated update after much stress & chaos -- but a solution! You were correct Passeri, this is NOT a Kea related issue at all.
There were a few problems, but I believe the two big ones were:
1. VLAN #1 being treated differently by different systems. Some have it as a default, some have it as a normal VLAN. The equipment I started on treated it normal so I made the mistake of relying on it. Won't do that again!
2. It turns out that the MS-01 uses vPro -- an IPMI that uses a shared network port (unlike iDrac). Further, a subset of vPro (conveniently including the MS-01) does not turn off entirely even when you specifically tell it to turn off, and continues to have certain parts running which happen to include some sort of network management which interferes with certain packets (such as DHCP packets) before the OS has a chance to see them.
So the packets were being sent to the hardware just fine, but the OS never saw them. As soon as I swapped to ports outside of vPro's scope it all worked fine!
Hopefully others will find this information useful, it sure wasn't easy to find or diagnose (until I knew exactly what to look for).
There were a few problems, but I believe the two big ones were:
1. VLAN #1 being treated differently by different systems. Some have it as a default, some have it as a normal VLAN. The equipment I started on treated it normal so I made the mistake of relying on it. Won't do that again!
2. It turns out that the MS-01 uses vPro -- an IPMI that uses a shared network port (unlike iDrac). Further, a subset of vPro (conveniently including the MS-01) does not turn off entirely even when you specifically tell it to turn off, and continues to have certain parts running which happen to include some sort of network management which interferes with certain packets (such as DHCP packets) before the OS has a chance to see them.
So the packets were being sent to the hardware just fine, but the OS never saw them. As soon as I swapped to ports outside of vPro's scope it all worked fine!
Hopefully others will find this information useful, it sure wasn't easy to find or diagnose (until I knew exactly what to look for).
#22
25.1, 25.4 Series / Re: unable to update and openV...
Last post by aniki - Today at 04:01:21 AMIt comes back to why the ntp is not working
#23
Intrusion Detection and Prevention / Please updating the Default DN...
Last post by Armani - Today at 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.
#24
25.7, 25.10 Series / Memory protection faults
Last post by teb - Today at 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
#25
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by meyergru - Today at 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.
#26
General Discussion / Re: Why I am retiring from con...
Last post by allan - Today at 12:57:15 AMAs someone who was affected by the original (280701) bug, I think there is a deeper issue with their networking stack they are not addressing. I just got done with a 4-hour troubleshooting session on my network. I noticed that HAProxy was sending duplicate packets to my backend web server. Both are on the same subnet and the network is not saturated so there is no reason for these retransmissions. I first thought it was LAGG but it persistent after I disabled it. Retransmissions only stopped after I disabled VLAN tagging. I am thinking it is something with their igc driver. This all happened today.
#27
Hardware and Performance / Re: DEC697 vs virtual build / ...
Last post by passeri - Today at 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.
#28
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!
#29
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.
#30
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.
