Question: if a more specific policy (by source address) matches a query in Unbound, and that query is
not blocked by any filter on that policy, does the filtering end there? Or does it cascade through each of the less specific matching policies until it's either blocked or resolved by the final (i.e. 'default') policy?
I couldn't find the answer in the relevant section of the docs (https://docs.opnsense.org/manual/unbound.html#blocklists), but it says this:
QuoteThe algorithm selects the most specific subnet when domains overlap across subnet sizes.
... which I
might have interpreted as it stops on the first matched policy, going from most to least specific.
I set up a test like so:
blocklist-policies.png
(Note: the original 'default' policy is disabled and replaced with the 'clients-all' default policy.)
The idea was that local queries from OPNsense itself (source 127.0.0.1 or ::1) would resolve unimpeded so that firewall Host aliases wouldn't break. All other traffic, including dynamic IPv6 sources for which I can't statically enter into the policy, would go to the one with the block lists.
The localhost matchers both work fine. Since requests and replies are both local, ::1 works here (unlike in F/W and DNAT rules).
The "issue" is that localhost queries are still falling through to the 'clients-all' policy and getting filtered, so I think it's designed to cascade but am not certain.
(I know, I can solve this with IPv4-only addressing for DNS and specific policies per IPv4 net. Just messing around to learn. I also want localhost requests forwarded externally via DoT through Unbound, same as the others.)
If they are meant to cascade, is there a way to make the policies work like pf 'quick' rules, on first match? Alternatively, can anyone think of a creative hack to make this scheme work as intended and still support dynamic prefixes? :)
Quote from: OPNenthu on Today at 10:23:09 AMIf they are meant to cascade, is there a way to make the policies work like pf 'quick' rules, on first match? Alternatively, can anyone think of a creative hack to make this scheme work as intended and still support dynamic prefixes? :)
I am looking for the same info.... It would be great if the Blocklists rules worked like firewall, the first match wins. Also would be great if dynamic prefixes could be used as source lists.
You will need to add a subnet to your clients-all policy.
For example, 192.168.1.0/24 (and your IPv6 subnet on a separate cloned policy) ; Now that list will apply to everything on that subnet and your localhost policies will work to not block from localhost.
If you leave it as blank, it will be evaluated regardless on top of your other policies. You essentially saying this policy is for EVERYTHING by leaving it blank.
For what it is worth, I think it should work the way you assumed it would, but it does not. :)