netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).