Re: Why aren't INPUT and FORWARD chains available to a locally-generated packet?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 12, 2021 at 2:39 AM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> Harry <simonsharry@xxxxxxxxx> wrote:
>
> > On Wed, Aug 11, 2021 at 7:59 PM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> > I guess, my confusion is: Even if routing happens before OUTPUT, why
> > in the Netfilter Packet Flow diagram above there is no arrow going to
> > mangle:INPUT *also* apart from the raw:OUTPUT arrow already shown in
> > the diagram?
>
> Because packets never move directly from OUTPUT to INPUT.
> > packet is out on the wire!

In the current diagrams and explanations -- obviously yes!

I guess, the gist or the spirit of my original question was (and still
is): It would've been more consistent and logical, and /more 'elegant'
to have had Netfilter make the packet go through the same chains
(either INPUT or FORWARD) once the (very first) routing decision has
been taken on it. Consider, again: the locally-generated packet
following this routing decision can only go to two places: either to
the local host or to another host... which is conceptually the same as
the fate of the packet immediately after the routing decision
happening after PREROUTING.

In other words, what is different about these two:
    1. the routing decision taken after PREROUTING, and
    2. the routing decision taken right after a packet is generated locally?

In fact, a PREROUTING-like chain 'should have' existed for a
locally-generated packet *also*.

In fact, and even better, the locally-generated packet 'should have
been' treated exactly like the packet arriving from another host. I'm
not sure why it isn't.

Hope, I'm not annoying you/others with my conceptual question about
the *why's* behind the current design. In the current design, *of
course* I can see in various diagrams that the OUTPUT path is being
treated differently from the INPUT path.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux