On 13/02/2020 12:51, Jozsef Kadlecsik wrote:
On Thu, 13 Feb 2020, ѽ҉ᶬḳ℠ wrote:
Been also wondering about potential conflicts between kernel
parameters vs. firewall rules, which takes precedence?
Another example - here purposely creating a conflict:
* net.ipv6.conf.<interface>.accept_redirects = 0
vs.
* ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137 accept;
Looked into various publications, including [1], but came up short in
discovering the hierarchy of /proc parameters vs firewall rules/chains,
i.e.
* is the kernel treating both the same or considers one or the other
weighing more/higher than the other?
* if treated equally does timing in availability of structures cancels
out the other, e.g. first available sets the rule or the last one
available cancels out the earlier one?
Check out the packet flow in netfilter and the networking stack, eg:
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
A networking subsystem proc/whatever setting have got a chance to tell
what happens with the packet if the netfilter hooks let the packet pass up
to that point. And vice versa: if a subsytem decides to drop the packet
(say routing due to reverse path filtering), then the next netfilter hook
won't/can't process it.
Best regards,
Jozsef
It was the point of asking the question here, also having perused that
graphic, to understand where the /proc/sys/net/* variables fit in the
packet flow, but now understanding (also as Florian pointed out) that
those variables are processed as part of the routing decision. That make
things clear and helps to design the network protection efficiently.
