As best as I can tell this must have recently changed as all sorts of stuff started acting strangely and I see a bunch of other people reporting similar odd issues.
The bogons alias includes, in addition to bogons, !10.0.0.0/8, !172.16.0.0/12, !192.16.0.0/16, etc. This is fine if you're using it alone in a rule to block as-intended, but if you've e.g. added it into an additional alias with private networks and are blocking on that...suddenly things can go haywire. E.g. a rule that *was* blocking "bogons and private IPs would now potentially be blocking bogons and NONPRIVATE IPs which is...unexpected.
Quote from: mattsteg on July 02, 2025, 07:50:04 PM[...]This is fine[...]
I'll disagree with you there. But thanks for the note - I'd done exactly as you said: created composite aliases with private and bogon networks. The composite (I have one for v4 and one for v6, but bogonsv6 is, as always, broken) preferred the negated addresses. I've split up the policies to handle the goofiness; now I just have to remember why.
Automatic configuration is like autocorrect: Don't try to be too helpful.
I think I may be having a similar problem but don't know enough to fix it. I updated to 25.1.10 and my internet connection broke immediately. I had to downgrade to an older version and restore config. Stupid me forgot to create a snapshot first.
Can someone provide the real rub-in here vs. skipping to the change that is technically correct?
At least one person was using multiple aliases in the same rule which is a recent addition which does a different thing on invert, which is documented: https://docs.opnsense.org/manual/firewall.html#basic-settings "You can only invert single sources"
We're either looking at a pf bug or a configuration issue IMO. But still it only appears to affect a fraction of people, so it points to how aliases/rules are being used in conjunction, because I don't believe a flat table that it still is will have issues out of the box.
If you are using the bogons alias to write your own aliases or rules please let us know...
Cheers,
Franco
Resurrecting this one...
Multiple aliases in a rule (particularly where the invert operator is allowed) does seem to be a bad idea. I still have some, as the capability is convenient, but I try to stick with ones that are pretty clearly defined (e.g. "__lan_network") or populated entirely by me.
I've also gone to the Cymru lists (https://www.team-cymru.com/bogon-reference-http) directly. It's a convenient way around the inversions and the bogonsv6 behavior. Any external address data (URL alias, geoip, etc.) is a risk... but automating a bogon checker doesn't seem practical (much of the source data is untrustworthy). I'll have to think about it.
In the mean time this was discussed and recorded as a future improvement. https://github.com/opnsense/core/issues/9048
IMO the bogons available for manual blocking is an unfortunate design decision, especially since the bogons list is modified and overlapping with private ranges. But that's not something we influenced in the last 10 years. The only attempt made here was to consolidate the private ranges that could be included in larger bogon subnets from the file and you can see what effect that already has on the whole system.
Cheers,
Franco
I did see that. I think the issues related to "bogons available for manual blocking" can be... solved? with docs, and perhaps with list options (alternate, preferably curated bogon lists). Given the position (evaluation sequence) of the automatic rules the exclusion of private networks is appropriate... unless you wanted to add some pretzel logic around the "block private networks" and "block bogon networks" options.
I was pondering a separate bogon list for internal use which merges the private range exclusion. The trouble only starts when that alias is used in an inversion which makes it hit rather than silently defer to the next rule.
The other idea was to add more preprocessing, but it takes away from flexibility and adds more complexity to the whole process.
Cheers,
Franco
Right... My point (that I seem to be struggling to articulate) is that a simple, generalized, switchable option should be provided, and anything else should be user-defined. Attempting to improve a solution while accommodating (legitimate) legacy concerns can tie you into knots. I'm having trouble remembering that myself.
Well you have to factor in that the bogons maintainer merge and expand ranges, especially in IPv6, which changes the bogons layout in the alias over the years. Since they consider private ranges bogon but the code design is to separate bogons and private ranges at some point in time the bogons no longer work as initially coded which makes explicit exclusions for private ranges perfectly reasonable for the included bogons blocking.
So either leave a bug or trade for another seems like what happened here. I'm also not fond of inversion handling in pf tables in this particular case. Logically it sounds like matching is avoidable, but it seems to think that the alias hit when it didn't because of the exclusion -- confusion over an implied or explicit match, but I have no interest in pf patching that is going to be rejected by FreeBSD or OpenBSD. This happened too much already.
Cheers,
Franco