[pbr] issue: Regression from 1.1.1-7 to 1.1.3-25 - overlaps in `src_addr` arguments among `policy` entries results in cryptic `nft` failures about source.openwrt.melmac.net HOT 6 OPEN

Overlap of 192.168.1.0/24 between two rules:

config policy
	option name 'hulu.com'
	option src_addr '192.168.1.0/24'
	option dest_addr 'hulu.com'
	option interface 'wan'

config policy
	option name 'ticketmaster.com'
	option src_addr '192.168.1.0/24'
	option dest_addr 'ticketmaster.com'
	option interface 'wan'

I can't reproduce, I've added those two policies to my test OpenWrt config and pbr started just fine in the nft_file mode.

from source.openwrt.melmac.net.

I can't reproduce, I've added those two policies to my test OpenWrt config and pbr started just fine in the nft_file mode.

Hmmm ... that's odd. I might have misunderstood when I received the error. What about with this?

config policy
	option name 'lan-to-wan'
	option src_addr '192.168.101.0/23'
	option dest_addr 'hulu.com'
	option interface 'wan'

config policy
	option name 'lan-guest-to-wan'
	option src_addr '192.168.101.0/23 192.168.102.0/23'
	option dest_addr 'espn.api.edge.bamgrid.com d2f2ekwwtg17a.cloudfront.net'
	option interface 'wan'

config policy
	option name 'to-vpn'
	option dest_addr 'espn.com'
	option interface 'vpn'  # or any VPN interface

from source.openwrt.melmac.net.

Yeah, that fails. I don't understand why nft sees a collision there. But if you split the middle policy into two, this works:

config policy
	option name 'lan-guest-to-wan'
	option src_addr '192.168.100.0/23'
	option dest_addr 'espn.api.edge.bamgrid.com d2f2ekwwtg17a.cloudfront.net'
	option interface 'wan'

config policy
	option name 'lan-guest-to-wan2'
	option src_addr '192.168.102.0/23'
	option dest_addr 'espn.api.edge.bamgrid.com d2f2ekwwtg17a.cloudfront.net'
	option interface 'wan'

from source.openwrt.melmac.net.

I can see several options here:

1. Do the requisite set manipulation in pbr to accommodate the use case (my favorite, since it preserves the ergonomics of the documented parameters);
2. Detect the failure mode in pbr, intercept it, and notify the user how to correct it (possibly with a reference to updated docs providing a more thorough explanation);
3. Enumerate known failure modes with nft in the docs, and when any nft failure occurs, detect it and direct the user there to diagnose on their own (not nearly as ergonomic as either of the above, but probably less time to implement);
4. Only update the docs (my least favorite, since it requires the user to map the cryptic error to the appropriate place in the docs, and doesn't work well for people like me, who've experienced a degradation post upgrade); or
5. Fix the problem in nft (probably not viable; that workflow looks awful to me; even submitting/searching for a bug looks unnecessarily cumbersome given that it's 2024).

By "set manipulation", I mean that pbr could read the example from my #194 (comment) and (de?)normalize it to entries without any overlap, like that in your #194 (comment).

from source.openwrt.melmac.net.

You're welcome to contribute any improvement to both pbr and pbr docs on the matter.

Additionally it may be helpful to post the example of nft ip collision on the OpenWrt forum and if the nft gurus can suggest an easy way to create the nft file from this policy which would not be rejected by nft I'm game to implement it.

from source.openwrt.melmac.net.