Messages

Since 26.7.8 you can paste your API Token at the end of the Download Section.

Please see the release notes of 26.7.8:

intrusion detection: add abuse.ch API token input

Please be aware that abuse.ch has at the moment some throttling issues. Some Rulesets are not loaded on my 4x Daily schedule. Not a big deal for most of us.

Regards,
Wrigleys

Hi devl_ish

I assume you can use "pass" instead of "match" like documented under Rule normalization:

Select the Match action to apply normalization without deciding whether traffic is passed or blocked. A Pass rule can apply the same options while also allowing traffic. Match rules follow the normal firewall rule ordering; they are usually not quick so evaluation can continue after their options have been applied.

Stay safe,
Wrigleys

Hi and thanks for your follow-up. The reason why I'm asking is to make sure to cover relevant alternative subdomain URL combinations like www.baddomain[.]com, www2.baddomain[.]com or just baddomain[.]com

If I was an attacker I would change the subdomain more often to get rid of any static blocklist entries. A wildcard entry would block it in any way possible, but the chances to block false positive is a valid argument.

either way, many thanks for your feedback.

Many thanks and stay safe
Wrigleys

You have to make your browser window smaller like it is on mobile devices to reproduce this scrolling issue. I had it also in Safari on my Mac but only when the browser window is small enough. I've experienced it at least for the new firewall rules list.

Yes, scrolling isn't possible anymore for example in the new rules section. It always jumps back to first rules.

iOS27 with Safari.

Good to know that full screen mode works.

Except from this small bug, another absolutely nice release. Thanks to every contributor!

All the best,
Wrigleys

I'm using the community feeds. I would like to have those records in another format so that unbound will block those records in the wildcard format instead of host/domain format.

for exampe:

• *.google.com will block google.com and all other subdomains like www.google.com
• google.com will only block request for google.com and will allow any other request like www.google.com

I'm not using the official Plugin. Because you can also feed those two community lists by URL. And my feeds are synchronizing every 6h.

Hi all

I would like to ask, if your malware_domain feed is planned to support other formats like Domain Wildcard (Asterisk)?

In OPNsense Unbound, this malware_domain feed isn't parsing in the wildcard format and therefore only exact matches will gets blocked.

Export from Log File:

Code Select Expand

blocklist: https://api.qfeeds.com/api?feed_type=malware_domains&api_token=xxxxxxx (block: 121164 wildcard: 0)
Thanks for your awesome service.

Take care and all the best,
Wrigleys

Yes so according to https://github.com/opnsense/ports/blob/master/opnsense/filterlog/files/description.txt

rulenr = empty
subrulenr = empty
anchorname = empty
label = 0

Which basically means this isn't a rule coming from our generated rules or pf doesn't know where this log entry comes from at all.



Cheers,
Franco

Thanks franco for this clarification. Makes sense to me. Therefore we have to wait and see if upstream FreeBSD will fix it in upcoming patches/releases.

@Ampfinger: as far as I understood, as long as the Packetfilter System returning Logs starting with 0, there are no options to configure inside OPNsense to prevent those logs from listing/spamming.

[Output from ChatGPT:]

Sure, here you go:

2026-07-15T21:54:03    Informational    filterlog    ,,,0,wg0,ip-option,block,out,6,0x00,0x00000,1,ip,0,76,::,ff02::16,INVALIDOPT
2026-07-15T21:54:00    Informational    filterlog    ,,,0,wg0,ip-option,block,out,6,0x00,0x00000,1,ip,0,76,::,ff02::16,INVALIDOPT
2026-07-15T21:53:53    Informational    filterlog    ,,,0,igb1,ip-option,block,out,6,0x00,0x00000,1,ip,0,36,::,ff02::16,INVALIDOPT
␀␀␀
Thanks for your help!

Output from ChatGPT:
The sequence fits well with the following startup behavior:

• OPNsense boots up.
• IPv6 is initialized on the interfaces (igb1, wg0).
• The kernel or network services generate initial IPv6 multicast/MLD packets.
• At that moment, the interface may not yet have a fully configured IPv6 address, which is why the source address appears as ::.
• PF (the packet filter) classifies the packet as INVALIDOPT and drops it.
• A few seconds later, interface initialization is complete and IPv6 operates normally.

The fact that the packets are sent to ff02::16 (the MLDv2 multicast address) and appear only during startup strongly suggests an IPv6 initialization/timing issue rather than a configuration error.

I'm still seeing those Label-less blocked filter rules even after installing 26.7 from scratch.

For testing purposes, I've enabled all logs under Firewall - Advanced but those few Label-less blocked filter rules are still there after a reboot.

It looks like a backend kernel-/pf-internal filter rules, which we unfortunately can't handle.

[Response from ChatGPT:]

In my case all rules have descriptions. For automatic generated rules and for my manually added rules. I think that those label-less rules are proceeded in the background. Could it be from kernel-/pf-internal filter rules?

Response from ChatGPT:
If the entries:

• only occur during boot,
• appear only once or twice per restart,
• have the destination ff02::16,
• and never reappear until the next reboot,

then they are most likely related to the initialization of the IPv6 networking stack. During startup, FreeBSD/OPNsense registers multicast group memberships on active interfaces using MLDv2 (Multicast Listener Discovery v2). The IPv6 multicast address ff02::16 is specifically reserved for all MLDv2-capable routers.

The fact that the source address is shown as :: (the IPv6 unspecified address) also fits the startup phase of an interface, before a normal IPv6 address has been fully configured. IPv6 control protocols can legitimately use special addresses during initialization.

The upgrade to OPNsense 26.7 (which is based on FreeBSD 15.1) likely changed how these packets are logged or made them visible in the firewall log. The underlying behavior itself is probably not new.

Conclusion
Based on the symptoms you described, these log entries look like normal IPv6/MLDv2 startup traffic generated during interface initialization. The upgrade likely made the packets visible in the logs, but there is no indication of an actual networking or security problem.

Labels are off due to a kernel error but we found the problem already, see https://github.com/opnsense/src/issues/295

Hi Franco,
Sorry for this follow-up. I assume that this issue has deen fixed and implemented in the new 26.7 kernel but unfortunate, I'm still seeing FW-Logs without Label after every reboot. I've upgraded my appliance from RC2 to 26.7 this morning.

Thanks and regards,
Wrigleys

Labels are off due to a kernel error but we found the problem already, see https://github.com/opnsense/src/issues/295

Great, thanks for that!

In addition to I've noticed a scroll bar in single column mode even if I dragged the table down completely.

I've upgraded my system to OPNsense 26.7.r2_3-amd64 and noticed the following Blocked Firewall Logs without any Label after every reboot:

WG Out 2026-07-12T09:25:39 IP :: ff02:16 block
WG Out 2026-07-12T09:25:38 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:29 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:28 IP :: ff02::16 block

Is that normal or is this a leftover which needs to be hidden or corrected?

Thanks for your hard work. 26.7 is really nice so far!

All the best,
Wrigleys