WTF, over

WTF, over

[Stephen Satchell]

This statement works with --check, but this is what I get when I try to 
insert the rule:

> [root@fiber-fw Desktop]# nft add rule inet filter output meta oif enp1s0 jump wan_output
> Error: Could not process rule: Operation not supported
> add rule inet filter output meta oif enp1s0 jump wan_output
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Doing a "list ruleset", I find this present in inet filter:

> 	chain wan_output {
> 		fib saddr . iif type broadcast counter packets 0 bytes 0 drop
> 		fib saddr . iif type multicast counter packets 0 bytes 0 drop
> 		fib saddr . iif type blackhole counter packets 0 bytes 0 drop
> 		fib saddr . iif type unreachable counter packets 0 bytes 0 drop
> 		fib saddr . iif type prohibit counter packets 0 bytes 0 drop
> 	}

Interestingly, a similar expression works just file in the input context:

> 	chain input {
> 		type filter hook input priority 0; policy drop;
> 		iif "enp1s0" jump wan_input
> 		iif "enp2s0" jump lan_input


Documentation provides NO clue as to what is wrong with the first 
statement statement.

Can anyone tell me what is going on?

Re: WTF, over

[Pablo Neira Ayuso]

On Sat, May 23, 2020 at 03:02:14PM -0700, Stephen Satchell wrote:
> This statement works with --check, but this is what I get when I try to
> insert the rule:
> 
> > [root@fiber-fw Desktop]# nft add rule inet filter output meta oif enp1s0 jump wan_output
> > Error: Could not process rule: Operation not supported
> > add rule inet filter output meta oif enp1s0 jump wan_output
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Doing a "list ruleset", I find this present in inet filter:
> 
> > 	chain wan_output {
> > 		fib saddr . iif type broadcast counter packets 0 bytes 0 drop
> > 		fib saddr . iif type multicast counter packets 0 bytes 0 drop
> > 		fib saddr . iif type blackhole counter packets 0 bytes 0 drop
> > 		fib saddr . iif type unreachable counter packets 0 bytes 0 drop
> > 		fib saddr . iif type prohibit counter packets 0 bytes 0 drop
> > 	}
> 
> Interestingly, a similar expression works just file in the input context:
> 
> > 	chain input {
> > 		type filter hook input priority 0; policy drop;
> > 		iif "enp1s0" jump wan_input
> > 		iif "enp2s0" jump lan_input
> 
> 
> Documentation provides NO clue as to what is wrong with the first statement
> statement.
> 
> Can anyone tell me what is going on?

fib address type with...

* iff can only be used in prerouting, input and forward.
* oif can only be used in output, postrouting and forward.

I assume your 'output' chain is something like:

        type filter hook output priority 0; policy drop;

Anyway, I agree error reporting and documentation can do better there.

Re: WTF, over

[Stephen Satchell]

On 5/24/20 4:09 AM, Pablo Neira Ayuso wrote:
> fib address type with...
> 
> * iff can only be used in prerouting, input and forward.
> * oif can only be used in output, postrouting and forward.
> 
> I assume your 'output' chain is something like:
> 
>          type filter hook output priority 0; policy drop;
> 
> Anyway, I agree error reporting and documentation can do better there.

Interesting.  Here is the complete fragment, as tested on a virtual machine:

> table inet filter {
>     chain wan_output {
>         fib saddr . iif type broadcast   counter drop # no non-unicast
>        #fib saddr . iif type anycast     counter drop (unicast)
>         fib saddr . iif type multicast   counter drop 
>         fib saddr . iif type blackhole   counter drop 
>         fib saddr . iif type unreachable counter drop 
>         fib saddr . iif type prohibit    counter drop
>         }
>     chain output {
>         type filter hook output priority 0; policy accept;
>         meta oif "lo" accept
>         meta oif "ens3" goto wan_output
>         }
>     }

The output when I try to load this is:
> [root@localhost Desktop]# nft  -f x.nft
> x.nft:13:9-39: Error: Could not process rule: Operation not supported
>         meta oif "ens3" goto wan_output
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*  meta oif is being used in the output chain
*  replace 'goto wan_output' with drop generates no message
*  "nft ruleset" echos the rules properly with "drop"

What is so special about the jump action?


So it appears there is a disconnect when the jump target is specified.

Re: WTF, over

[Pablo Neira Ayuso]

On Sun, May 24, 2020 at 08:03:00AM -0700, Stephen Satchell wrote:
> On 5/24/20 4:09 AM, Pablo Neira Ayuso wrote:
> > fib address type with...
> > 
> > * iff can only be used in prerouting, input and forward.
> > * oif can only be used in output, postrouting and forward.
> > 
> > I assume your 'output' chain is something like:
> > 
> >          type filter hook output priority 0; policy drop;
> 
[...]
> > table inet filter {
> >     chain wan_output {
> >         fib saddr . iif type broadcast   counter drop # no non-unicast
> >        #fib saddr . iif type anycast     counter drop (unicast)
> >         fib saddr . iif type multicast   counter drop         fib saddr
> > . iif type blackhole   counter drop         fib saddr . iif type
> > unreachable counter drop         fib saddr . iif type prohibit
> > counter drop
> >         }
> >     chain output {
> >         type filter hook output priority 0; policy accept;
> >         meta oif "lo" accept
> >         meta oif "ens3" goto wan_output
> >         }
> >     }
> 
> The output when I try to load this is:
> > [root@localhost Desktop]# nft  -f x.nft
> > x.nft:13:9-39: Error: Could not process rule: Operation not supported
> >         meta oif "ens3" goto wan_output
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This happens because you cannot use 'fib saddr . iif type' from your
wan_output chain.

The error is reported, later on, when you add this rule:

        meta oif "ens3" goto wan_output

because the jump/goto validates your 'wan_output'. This validation
fails because your 'wan_output' chain contains rules with:

        fib saddr . iif type

which is not supported in the output path.

You can only use 'fib saddr . iif type' from prerouting, input and
forward.

Re: WTF, over (reformatted)

[Stephen Satchell]

On 5/24/20 4:09 AM, Pablo Neira Ayuso wrote:
> fib address type with...
> 
> * iff can only be used in prerouting, input and forward.
> * oif can only be used in output, postrouting and forward.
> 
> I assume your 'output' chain is something like:
> 
>          type filter hook output priority 0; policy drop;
> 
> Anyway, I agree error reporting and documentation can do better there.

Interesting.  Here is the complete fragment, as tested on a virtual machine:

> table inet filter {
>     chain wan_output {
>         fib saddr . iif type broadcast   counter drop # no non-unicast
>        #fib saddr . iif type anycast     counter drop (unicast)
>         fib saddr . iif type multicast   counter drop
>         fib saddr . iif type blackhole   counter drop
>         fib saddr . iif type unreachable counter drop
>         fib saddr . iif type prohibit    counter drop
>         }
>     chain output {
>         type filter hook output priority 0; policy accept;
>         meta oif "lo" accept
>         meta oif "ens3" goto wan_output
>         }
>     }

The output when I try to load this is:
> [root@localhost Desktop]# nft  -f x.nft
> x.nft:13:9-39: Error: Could not process rule: Operation not supported
>         meta oif "ens3" goto wan_output
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*  meta oif is being used in the output chain
*  replace 'goto wan_output' with drop generates no message
*  "nft ruleset" echos the rules properly with "drop"

What is so special about the jump action?


So it appears there is a disconnect when the jump target is specified.