Messages

Anyway I thought including FireHOL and Spamhaus by default would be a no-brainer. Reputable open sources.

When I was setting up my blocklists some time ago I was curious which FireHOL level to use and did some digging.

I noticed that quite a few source lists in there are stale. Some have changed the URL or format or are not (publicly) available anymore.

Since FireHOL keeps the last available copy of all sources in its own repo, that means (for better or worse) that it probably contains a lot of IPs that at some point were part of a source blocklist but aren't anymore.

Another interesting detail: it looks there are always multiple log entries with the same source port when this happens.
So either a single packet generates multiple log entries or it's the other way round: two packets with the same source port arriving at the same time are causing the issue.

In either case, this screams ,,race condition" if you ask me...

Might be a coincidence but I've noticed that all the timestamps end in ~55s.
Could this be caused by some scheduled job that runs every N minutes, like the table update?

Here's what I think happened:

• At one point the alias had the correct type ,,Network(s)" and correct 33 entries.
• Then you switched it to the incorrect type ,,URL Tables" for reasons unknown to me.
• Since the ,,URLs" are obviously not valid blocklist URLs, the (resolved) alias content is not updated and still contains those 33 networks.
• While the type is still ,,URL Tables" you added two networks. But still none of the values are valid blocklist URLs, so the table still contains the last valid list, i.e those 33 networks.
• Now you have changed the type back to ,,Network(s)" but since the content field hasn't changed and this is not a dynamic type, the (resolved) alias table isn't updated.

I can reproduce the behavior. I guess this wasn't considered a valid use case (understandably so).

Just make some actual changes to the contents field and the alias will be updated.

Did you actually hit the ,,Apply" button at the bottom of the Aliases page after adding the new entries?

A ,,Network(s)" alias is completely static, the contents don't change unless you change them yourself (or if the alias references other dynamic aliases).
So it's completely expected that the update date doesn't change as well.

Also, the Cron job seems completely pointless to me. Dynamic aliases (e.g. ,,URL Tables") are already updated automatically without an explicit Cron job, based on the individual update settings of that specific alias.

Something else I just noticed: in my DCHP logs I'm seeing a lot of redundant requests from the devices that I'm having trouble with, like:

Code Select Expand

2025-03-16T16:27:19-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Debug dhcpd reuse_lease: lease age 299 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:27:19-04:00 Debug dhcpd reuse_lease: lease age 299 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Debug dhcpd reuse_lease: lease age 265 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPACK on 192.168.1.115 to fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Informational dhcpd DHCPREQUEST for 192.168.1.115 from fa:4c:d1:56:48:d3 (iPhone) via bridge0
2025-03-16T16:26:45-04:00 Debug dhcpd reuse_lease: lease age 265 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.115

and that seems weird?

That might be just a TP-Link thing. My TP-Link APs (consumer grade, not Omada) are doing it as well. I suspect they are (ab)using DHCP as some kind of connectivity probe. I find it quite annoying.

I don't think it can be port forwarding.

In the screenshot of the first post you say that the source IP is the IP of the firewall itself. That means that the traffic has to come from OPNsense. Port forwarding does not change the source address of the packet, only the destination.

he's already said he's not using that feature ;)

I was just explaining why I asked that question.

Thank you very much again for your messages.

Do you have backup to git enabled?

Well, I am not using that feature for the moment. It looks great and can be very helpful, but at the same time, it is not making your configuration public, is it?

It can be a git server in your own network, it doesn't have to be a public one like GitHub.

But that's not the point. Git uses SSH to connect to the server which could explain the outgoing connections.

Do you have backup to git enabled?

Not exactly the same issue but possibly related:
Whitelisting also doesn't seem to work, whitelisted domains are still appearing in the top blocked domains (even months after whitelisting), just with the blocking icon next to them instead of the whitelisting icon.

Maybe there's a general problem with removing entries from the internal lookup table?

In my case the Thread Border Router (AppleTV) simply requests a prefix from OPNsense via PD. Isn't that how it's supposed to work with IPv6?

I'm also running OPNsense behind a FritzBox and I don't see any problems with PD.
Maybe there's something specific with your config that causes problems?

given that the v4 lease is 3600 (3 days)

Isn't that number usually in seconds, i.e. 3600 == 6 hours? (EDIT: 1 hour, math is hard...)

Every packet that goes through opnsense passes the firewall twice, once when entering the device (,,in"), once when leaving it again (,,out").

All your filter rules should usually be on the ,,in" direction and the ,,let out anything..." rule is normally the only ,,out" rule. That means that almost every packet will match that rule.
I would recommend disabling logging for that rule under ,,Firewall" -> ,,Settings" -> ,,Advanced" -> ,,Logging" -> ,,Default pass"