[nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[ѽ҉ᶬḳ℠]

Having deployed family tables:

* inet
* ip
* ip6

and to my understanding the _base chain definitions_, hook priority and 
policy, are only applicable to chains within the same family table but 
are mutually exclusive between the different family tables I am 
struggling to comprehend as to the order of packet processing among the 
aforementioned family tables:

* which family table the packet is processed trough first/last - inet or 
ip | ip6?
* if the hook priority in the base chains of each family is the same but 
different policies being applied how would such conflict, inet vs. ip | 
ip6, resolve?

As far as I comprehend jump | goto works with chains in the same family 
table but it is not possible to jump | goto from the inet table to ip | 
ip6 or vice versa, or is it?

Re: [nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[Florian Westphal]

ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> Having deployed family tables:
> 
> * inet
> * ip
> * ip6
> 
> and to my understanding the _base chain definitions_, hook priority and
> policy, are only applicable to chains within the same family table but are
> mutually exclusive between the different family tables I am struggling to
> comprehend as to the order of packet processing among the aforementioned
> family tables:
> 
> * which family table the packet is processed trough first/last - inet or ip
> | ip6?

None.  Ordering is by prio, not by family.

In ip vs ip6 case its even irrelevant because an ipv4 packet will never
travel any of the ip6 base chains, ever (and vice versa).

> * if the hook priority in the base chains of each family is the same but
> different policies being applied how would such conflict, inet vs. ip | ip6,
> resolve?

Implementation defined, right now its 'last added'.
But result is the same, if verdict is "drop", packet is discarded and
evaluation ends.

Just like with iptables: if you drop in mangle input, filter table won't
even get a chance to see the packet.

> As far as I comprehend jump | goto works with chains in the same family
> table but it is not possible to jump | goto from the inet table to ip | ip6
> or vice versa, or is it?

Its not, each table is a distinct entity.

Re: [nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[ѽ҉ᶬḳ℠]

On 05/02/2020 11:21, Florian Westphal wrote:
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> Having deployed family tables:
>>
>> * inet
>> * ip
>> * ip6
>>
>> and to my understanding the _base chain definitions_, hook priority and
>> policy, are only applicable to chains within the same family table but are
>> mutually exclusive between the different family tables I am struggling to
>> comprehend as to the order of packet processing among the aforementioned
>> family tables:
>>
>> * which family table the packet is processed trough first/last - inet or ip
>> | ip6?
> None.  Ordering is by prio, not by family.
>
> In ip vs ip6 case its even irrelevant because an ipv4 packet will never
> travel any of the ip6 base chains, ever (and vice versa).

That was clear, it was meant inet <> ip or inet <> ip6

>
>> * if the hook priority in the base chains of each family is the same but
>> different policies being applied how would such conflict, inet vs. ip | ip6,
>> resolve?
> Implementation defined, right now its 'last added'.

Does that pertain to table handle value?
Does a lower handle value mean that the packet is first seen by that table?
Noticed from the WIKI that rules can be positioned - does that work for 
table as well, e.g.

* table inet filter position X
* table inet filter { position X

throwing an error.

> But result is the same, if verdict is "drop", packet is discarded and
> evaluation ends.
>
> Just like with iptables: if you drop in mangle input, filter table won't
> even get a chance to see the packet.
>
>> As far as I comprehend jump | goto works with chains in the same family
>> table but it is not possible to jump | goto from the inet table to ip | ip6
>> or vice versa, or is it?
> Its not, each table is a distinct entity.

The question was with same chain/hook priority in inet versus ip | ipv6 
but a different verdict and how would such conclict resolve, e.g.

* inet chain input prio 0  policy drop
* ip chain input prio 0 policy drop
* ip6 chain input prio 0 policy continue

?

Re: [nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[Florian Westphal]

ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> > > * which family table the packet is processed trough first/last - inet or ip
> > > | ip6?
> > None.  Ordering is by prio, not by family.
> > 
> > In ip vs ip6 case its even irrelevant because an ipv4 packet will never
> > travel any of the ip6 base chains, ever (and vice versa).
> 
> That was clear, it was meant inet <> ip or inet <> ip6

Priority, lower is evaluated first.

> > > * if the hook priority in the base chains of each family is the same but
> > > different policies being applied how would such conflict, inet vs. ip | ip6,
> > > resolve?
> > Implementation defined, right now its 'last added'.
> 
> Does that pertain to table handle value?

Only indirectly in the sense that you can guess which one is the newer.

> Does a lower handle value mean that the packet is first seen by that table?
> Noticed from the WIKI that rules can be positioned - does that work for
> table as well, e.g.

No.  Only base chains matter, these already have a priority.

> > But result is the same, if verdict is "drop", packet is discarded and
> > evaluation ends.
> > 
> > Just like with iptables: if you drop in mangle input, filter table won't
> > even get a chance to see the packet.
> > 
> > > As far as I comprehend jump | goto works with chains in the same family
> > > table but it is not possible to jump | goto from the inet table to ip | ip6
> > > or vice versa, or is it?
> > Its not, each table is a distinct entity.
> 
> The question was with same chain/hook priority in inet versus ip | ipv6 but
> a different verdict and how would such conclict resolve, e.g.
> 
> * inet chain input prio 0  policy drop
> * ip chain input prio 0 policy drop
> * ip6 chain input prio 0 policy continue
> 
> ?

I tried to answer this above.

> * inet chain input prio 0  policy drop
> * ip chain input prio 0 policy drop
> * ip6 chain input prio 0 policy continue

If its an ipv4 packet, its dropped.  Ordering possibilities:

> * inet chain input prio 0  policy drop # drop is here
> * ip chain input prio 0 policy drop

or:

> * ip chain input prio 0 policy drop # drop is here
> * inet chain input prio 0  policy drop

If its ipv6, possibilities are:

> * inet chain input prio 0  policy drop  # drop is here
> * ip6 chain input prio 0 policy continue

or:

> * ip6 chain input prio 0 policy continue
> * inet chain input prio 0  policy drop  # drop is here

so in all cases the packet is dropped.
In the last case, ip6 input chain is still evaluated, but
nothing can override the drop in the inet chain.

Re: [nftables v0.9.2] inet <> ip | ip6 family tables processing order?

[Gordon Fisher]

On 2/5/2020 3:21 AM, Florian Westphal wrote:
> In ip vs ip6 case its even irrelevant because an ipv4 packet will never
> travel any of the ip6 base chains, ever (and vice versa).
Out of curiosity, does still hold true for ipv4 over ipv6 set-ups?

-- 
gordonfish