From: Simon Ruderich <simon@ruderich.org>
To: Frank Myhr <fmyhr@fhmtech.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [RFC PATCH] doc: use symbolic names for chain priorities
Date: Tue, 9 Mar 2021 11:47:39 +0100 [thread overview]
Message-ID: <YEdSS3PRMF7WURDl@ruderich.org> (raw)
In-Reply-To: <ced3e003-45c4-a39a-62a6-0e2f4e2abc47@fhmtech.com>
[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]
On Mon, Mar 08, 2021 at 04:46:34AM -0500, Frank Myhr wrote:
> 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.)
Hello Frank,
I'm not sure what exactly tripped me up (or is still confusing
me). I think it's mainly that the concepts of hooks (prerouting,
postrouting, etc.), chain types (filter, nat, etc.) and netfilter
hook priority was never really spelled out in a way that all the
pieces fit together (for me). The fact that the order of
priorities is not directly related to hooks made it worse (I
didn't realize that the priorities only order entries for a
single hook).
>> 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.
Thank you. That made it clearer for me.
> General point: you should have a good reason for using priorities other than
> the traditional ones.
Of course.
>> 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
No. I was talking about the chain types:
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
And I'm curious what's the difference in regard to netfilter
between these types. They are all added to the same netfilter
hook (e.g. prerouting can use filter, nat, etc. chains). Does
netfilter see any difference or is this just relevant to
nftables?
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2021-03-09 10:48 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
2021-03-09 10:47 ` Simon Ruderich [this message]
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=YEdSS3PRMF7WURDl@ruderich.org \
--to=simon@ruderich.org \
--cc=fmyhr@fhmtech.com \
--cc=netfilter-devel@vger.kernel.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).