From: Frank Myhr <fmyhr@fhmtech.com>
To: Simon Ruderich <simon@ruderich.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [RFC PATCH] doc: use symbolic names for chain priorities
Date: Mon, 8 Mar 2021 04:46:34 -0500 [thread overview]
Message-ID: <ced3e003-45c4-a39a-62a6-0e2f4e2abc47@fhmtech.com> (raw)
In-Reply-To: <YEW34W5oCspFnSt+@ruderich.org>
On 2021/03/08 00:36, Simon Ruderich wrote:
> On Sun, Mar 07, 2021 at 10:02:52AM -0500, Frank Myhr wrote:
>> Hi Simon,
>>
>> Priority is only relevant _within a given hook_. So comparing priorities of
>> base chains hooked to prerouting and postrouting (as in your example above)
>> does not make sense. Please see:
>>
>> https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
>> https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
>
> Hello Frank,
>
> thank you. This helped, somewhat.
I'm glad. If you have suggestions for how to make the wiki clearer I'd
love to hear them. (Probably better to use the regular netfilter list,
where developers are also present, rather than this netfilter-devel list.)
> The image https://people.netfilter.org/pablo/nf-hooks.png in the
> wiki lists netfilter hooks. Do these correspond to nftables
> hooks? So all prerouting hooks (type nat, type filter, etc.) for
> IP are applied to the green "Prerouting Hook" in the IP part of
> the diagram? And the "Netfilter Internal Priority" applies only
> within such a hook to order them?
Yes, nftables & the rest of netfilter (defrag, conntrack, nat, etc) use
the same hooks. And relative priority within a hook determines the order
in which the various processes _at that hook_ happen.
> Why is there a global order of netfilter hooks (via the priority,
> -450 to INT_MAX)? ... is it designed that way to "hint" at the packet flow
> (lower numbers first, independent of the actual hooks)?
I think such hinting is the idea, yes.
> Wouldn't it also work to set for example
> NF_IP_PRI_NAT_SRC to -400 because it only applies in postrouting
> anyway?
Just to be clear, NF_IP_PRI_NAT_SRC is a named constant in the netfilter
codebase. So not something you can change unless you edit the source
code and compile it yourself. But you could create a base chain using
"hook postrouting priority -400" and add rules with "snat to" statements
to said chain, and this will happily snat your packets as you specify.
Whether this overall config does what you want, depends on what else is
hooked to postrouting, and their relative priorities. For example:
* Conntrack is almost always used. Using -400 for snat doesn't change
its relative order to NF_IP_PRI_CONNTRACK_HELPER and
NF_IP_PRI_CONNTRACK_CONFIRM (both of which are also at postrouting hook).
* If you are also mangling packets (in ways other than snat) at
postrouting, NF_IP_PRI_MANGLE = -150. By moving your snat from usual 100
to -400, you've re-ordered the mangle and snat processes -- unless you
also use a nonstandard priority for your base chain that does mangling.
* There's also NF_IP_PRI_SECURITY, maybe important if you're using SELINUX.
General point: you should have a good reason for using priorities other
than the traditional ones.
> For type nat and hook prerouting priorities like -100, 0 and 500
> would all work because we have no other hooks in that range. > However, using priority -250 would be problematic because it puts
> it before the netfilter connection tracking?
It's pretty common to filter in prerouting. And maybe to set secmark as
well... So using priority 0 or 500 for dnat could cause trouble. Using
-250 for dnat is problematic for the reason you state. And if you're
using SELINUX you also have to consider NF_IP_PRI_SELINUX_FIRST at -225.
> What exactly is the difference between the chain types? Is it
> relevant for netfilter or is it only for nftables so it knows
> which rules to expect in the given chain?
I think you mean?:
https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families
~
Disclosure: I'm not an nftables or netfilter developer, just a user with
an interest in clear documentation.
Best Wishes,
Frank
next prev parent reply other threads:[~2021-03-08 9:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-07 14:43 [RFC PATCH] doc: use symbolic names for chain priorities Simon Ruderich
2021-03-07 15:02 ` Frank Myhr
2021-03-08 5:36 ` Simon Ruderich
2021-03-08 9:46 ` Frank Myhr [this message]
2021-03-09 10:47 ` Simon Ruderich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ced3e003-45c4-a39a-62a6-0e2f4e2abc47@fhmtech.com \
--to=fmyhr@fhmtech.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=simon@ruderich.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).