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

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

[Harry S]

Hello,

I'm unable to understand why in Netfilter there are no INPUT versus
FORWARD chain choices right after the packet has traversed the OUTPUT
chain? Currently, a locally-generated packet goes straight from OUTPUT
to POSTROUTING!

Let's say a process on a router host generates a packet. This packet
goes to the OUTPUT chain, following which a routing decision is made.
Now, this packet could be destined either for the loopback interface,
or for one of the host's many ethernet interfaces. If so, why
shouldn't Netfilter bring the packet to the same INPUT / FORWARD
decision-fork in the path that exists for an incoming packet soon
after it has crossed PREROUTING?

I have consulted *many* online sources, including Linux Network
Administrator's Guide, and the ipables tutorial by Oskar Andreasson,
but none of these explain this point at all.

Would greatly appreciate it if someone could clarify.

Regards,
/HS

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

[Florian Westphal]

Harry S <simonsharry@gmail.com> wrote:
> Hello,
> 
> I'm unable to understand why in Netfilter there are no INPUT versus
> FORWARD chain choices right after the packet has traversed the OUTPUT
> chain? Currently, a locally-generated packet goes straight from OUTPUT
> to POSTROUTING!

[..]
> Let's say a process on a router host generates a packet. This packet
> goes to the OUTPUT chain, following which a routing decision is made.

No, for output, routing decision happens before output.

Else you could not filter based on output interface name in OUTPUT.

There is a rerouting check/reroute enforcement in mangle:output
to handle a change in the packet mark.

Same for NAT in output: re-route if the destination ip
changed.

> Now, this packet could be destined either for the loopback interface,
> or for one of the host's many ethernet interfaces. If so, why
> shouldn't Netfilter bring the packet to the same INPUT / FORWARD
> decision-fork in the path that exists for an incoming packet soon
> after it has crossed PREROUTING?

If its loopback, packet ends up using:

OUTPUT -> POSTROUTING -> PREROUTING -> INPUT (or FORWARD).

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

[Reindl Harald]

Am 11.08.21 um 16:12 schrieb Harry S:
> Hello,
> 
> I'm unable to understand why in Netfilter there are no INPUT versus
> FORWARD chain choices right after the packet has traversed the OUTPUT
> chain? Currently, a locally-generated packet goes straight from OUTPUT
> to POSTROUTING!
> 
> Let's say a process on a router host generates a packet. This packet
> goes to the OUTPUT chain, following which a routing decision is made.
> Now, this packet could be destined either for the loopback interface,
> or for one of the host's many ethernet interfaces. If so, why
> shouldn't Netfilter bring the packet to the same INPUT / FORWARD
> decision-fork in the path that exists for an incoming packet soon
> after it has crossed PREROUTING?

because it did not enter from the network nor is it forwarded which 
means you are a middlebox

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

[Florian Westphal]

Harry <simonsharry@gmail.com> wrote:

Please keep the ML in CC, thnaks.

> On Wed, Aug 11, 2021 at 7:59 PM Florian Westphal <fw@strlen.de> wrote:
> > Harry S <simonsharry@gmail.com> wrote:
> > [..]
> > > Let's say a process on a router host generates a packet. This packet
> > > goes to the OUTPUT chain, following which a routing decision is made.
> >
> > No, for output, routing decision happens before output.
> 
> I perhaps had this documentation source in mind; see the ASCII diagram
> and also the explanation below it for what it says when the routing
> happens:
>     https://netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO-3.html

"[..] in fact, the routing code is called first (to figure out the source IP
address and some IP options): if you want to alter the routing, you must alter
the `skb->dst' field yourself, as is done in the NAT code."

> But in this diagram,
>     https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
> as well as in Table 6-2 in the iptables-tutorial here,
>     https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES
> routing happens before OUTPUT -- just like you say.

Yes.

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

> Could you or someone confirm if the Netfilter Packet Flow Diagram is
> fully accurate *and* complete, as far as the Network and higher layers
> are concerned? (That is, ignoring the ebtables stuff.)

Its accurate.

> > There is a rerouting check/reroute enforcement in mangle:output
> > to handle a change in the packet mark.
> 
> I'm not sure if I'm following. It's shown neither in the diagram nor
> in Table 6-2. This means the diagram and the table are incomplete
> and/or inaccurate?

It says "reroute check", after filter. Its technically incorrect since
there are several reroute checks but I guess it would get too entangled
otherwise.

> > > Now, this packet could be destined either for the loopback interface,
> > > or for one of the host's many ethernet interfaces. If so, why
> > > shouldn't Netfilter bring the packet to the same INPUT / FORWARD
> > > decision-fork in the path that exists for an incoming packet soon
> > > after it has crossed PREROUTING?
> >
> > If its loopback, packet ends up using:
> >
> > OUTPUT -> POSTROUTING -> PREROUTING -> INPUT (or FORWARD).
> 
> Hmm, after POSTROUTING, all texts that I've looked at say that the
> packet is out on the wire!

It is.  Loopback driver maps each xmit to a packet receive.
Packet thus moves from postrouting to prerouting.

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

[Harry]

On Wed, Aug 11, 2021 at 8:02 PM Reindl Harald <h.reindl@thelounge.net> wrote:
>
> Am 11.08.21 um 16:12 schrieb Harry S:
> >
> > Let's say a process on a router host generates a packet. This packet
> > goes to the OUTPUT chain, following which a routing decision is made.
> > Now, this packet could be destined either for the loopback interface,
> > or for one of the host's many ethernet interfaces. If so, why
> > shouldn't Netfilter bring the packet to the same INPUT / FORWARD
> > decision-fork in the path that exists for an incoming packet soon
> > after it has crossed PREROUTING?
>
> because it did not enter from the network nor is it forwarded which
> means you are a middlebox

True, it didn't enter the network stack from the 'wire', but shouldn't
the routing and table/chain semantics apply to it equally? For, an
application running on the same host won't care where the packet came
from: from the wire, or from another local process?

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

[Harry]

On Thu, Aug 12, 2021 at 2:39 AM Florian Westphal <fw@strlen.de> wrote:
>
> Harry <simonsharry@gmail.com> wrote:
>
> > On Wed, Aug 11, 2021 at 7:59 PM Florian Westphal <fw@strlen.de> 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.

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

[Reindl Harald]

Am 12.08.21 um 03:37 schrieb Harry:
> On Thu, Aug 12, 2021 at 2:39 AM Florian Westphal <fw@strlen.de> wrote:
>>
>> Harry <simonsharry@gmail.com> wrote:
>>
>>> On Wed, Aug 11, 2021 at 7:59 PM Florian Westphal <fw@strlen.de> 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.

again: it's no INPUT when you talk to a foreign machine
again: it's no FORWARD when you are not a router

when you are talking to 127.0.0.1 *it is* INPUT on "lo" and it can be 
filtered, my webservers can't talk to samba on the same machine

when you talk to other machines with locally-generated packets it's for 
the sake of god OUTPUT