[RFC PATCH] wg-quick: linux: raise priority for mangle nft chain

[Dominique Martinet]

Jason A. Donenfeld wrote on Mon, Apr 27, 2020:
> This patch is missing a Signed-off-by line.

Sorry, will add and resend without RFC after some feedback.

> On Mon, Apr 27, 2020 at 2:02 PM Dominique Martinet
> <asmadeus at codewreck.org> wrote:
> > -       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
> > +       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -160; }\n' "$nftcmd" "$pf" "$nftable"
> >         printf -v nftcmd '%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
> 
> Should this one be -160 too?

Good question, the only two chains I'm aware of conflicting are
wg-quick's premangle and ip6tables's mangle/PREROUTING rpfilter
(e.g. a rule like:
ip6tables -t mangle -A PREROUTING -m rpfilter --validmark --invert -j DROP
)

As I understand rpfilter only makes sense on prerouting or broadly
speaking input (firewalld's nft backend will move the rpfilter rule all
the way down to filter input table, but that's not possible with
ip6tables) - it checks the incoming packet came through the same
interface we would send back to.
For postrouting the kernel already picked an interface for us so there
would be little point in checking the kernel would pick the same
interface again? So no rpfilter and marks aren't used in these rules.

If someone ever comes in with an ip6tables rule that relies on mark
checking in mangle POSTROUTING then it would help to move postmangle to
-160 as well, I'm just not aware of any.
Letting you decide on this one, I'd tend not to bother until a usecase
shows up, but I guess there's no harm in moving it anyway....

-- 
Dominique | Asmadeus