nftables RP filter and loopback

nftables RP filter and loopback

[Slavko]

Hi all,

i encounter strange problem with reverse path filter in nftables,
which i don't understand, thus i ask for help.

Some background -- for long time i have on my desktop (with
some bridges/veths for LXC, VirtualBox ifaces, and one dummy
iface) this prerouting chain (to shorten it i removed counter and
log parts):

    chain r_prerouting {
        type filter hook input priority raw; policy accept;
        iif "lo" notrack accept
        fib saddr type local fib daddr type { broadcast, multicast } accept
        fib saddr . iif oif missing drop
    }

That works as expected, but recently i start to play with tproxy
(not related) and in these experiments i deleted the "lo ... accept"
rule and then the last rule ("fib ... drop") starts to drop packets
to localhost, including the 127.0.0.1 -> 127.0.0.1 (the same
happens with IPv6).

The host has Debian with kernel 6.12.22 and nftables 1.1.1.

While i can imagine, that it can drop traffic to local (non loopback,
192.168.10.X in my case) IP, as it is routed through "lo" but
configured on "br0" (bridge in my case), but i din't play with
that as it drops loopback addresses too. I log these drops, thus
i see in log, that traffic is really 127.0.0.1 => 127.0.0.1, the
tcpdump shows SYN packets without response (on any iface,
to be sure) with the same addresses.

I search on Internet, and i found only one related thing -- the
iptables rpfilter module's manpage mentions, that it never
match on loopback traffic, but nothing nftables related. I
don't see the same note in nft manpage, nor on wiki.

I verified that couple of my initial assumptions was false:

+ my first idea was, that lo iface has index 0, but it has 1
  (of course)
+ my second idea was, that i mess routing table by some way,
  but "ip route get 127.0.0.1" shows that it belongs to "lo"
+ the tproxy is not related at all, the problem persists without it

Of course, when i add accept "lo" traffic before fib drop,
it works again, or when i add local to accepted fib types it
works too. Here i stop to do more assumptions and decided
to ask to i can understand what happens.

Please, is it feature of "fib saddr . iif oif" rule and "lo" traffic
or i miss something?

regards

-- 
Slavko
https://www.slavino.sk/

Re: nftables RP filter and loopback

[Florian Westphal]

Slavko <linux@slavino.sk> wrote:
> Hi all,
> 
> i encounter strange problem with reverse path filter in nftables,
> which i don't understand, thus i ask for help.
> 
> Some background -- for long time i have on my desktop (with
> some bridges/veths for LXC, VirtualBox ifaces, and one dummy
> iface) this prerouting chain (to shorten it i removed counter and
> log parts):
> 
>     chain r_prerouting {
>         type filter hook input priority raw; policy accept;
                           ~~~~~

This is an input chain.  The loopback bypass is restricted
to PRE_ROUTING before v6.15-rc1.

(This is an oversight, originally fib was rejected in input chain, and
when that restriction got lifted the lo bypass check wasn't adjusted).

Re: nftables RP filter and loopback

[Slavko]

On 22. apríla 2025 11:43:52 UTC, Florian Westphal <fw@strlen.de> wrote:
>Slavko <linux@slavino.sk> wrote:

>This is an input chain.  The loopback bypass is restricted
>to PRE_ROUTING before v6.15-rc1.

Uh, oh, ah, i checked everything except this and i have in my
notes something as "fib outside prerouting can provide not
expected results" (without explanation), now i understand what
happen and too what that note means ;-)

Thanks, i changed hook to prerounting and now it works as
expected.

>(This is an oversight, originally fib was rejected in input chain, and
>when that restriction got lifted the lo bypass check wasn't adjusted).

I didn' use nftables in that time, thus i cannot compare
behavior. Just to confirm that i understund you properly:

+ from 6.15 it will work even in input hook and lo as expected
+ before 6.15 it doesn't work (properly) outside of prerouting
  hook only with lo traffic (other ifaces works)

regards


-- 
Slavko
https://www.slavino.sk/

Re: nftables RP filter and loopback

[Florian Westphal]

Slavko <linux@slavino.sk> wrote:
> + from 6.15 it will work even in input hook and lo as expected

Yes.

> + before 6.15 it doesn't work (properly) outside of prerouting
>   hook only with lo traffic (other ifaces works)

Yes.  fib works fine but not for loopback traffic.

Re: nftables RP filter and loopback

[Slavko]

On 22. apríla 2025 12:53:51 UTC, Florian Westphal <fw@strlen.de> wrote:
>Slavko <linux@slavino.sk> wrote:
>> + from 6.15 it will work even in input hook and lo as expected
>
>Yes.
>
>> + before 6.15 it doesn't work (properly) outside of prerouting
>>   hook only with lo traffic (other ifaces works)
>
>Yes.  fib works fine but not for loopback traffic.
>

Thanks, IMO worth of (short) note in manpage, or at least
in wiki page.

refards


-- 
Slavko
https://www.slavino.sk/

Re: nftables RP filter and loopback

[Pablo Neira Ayuso]

On Tue, Apr 22, 2025 at 02:53:51PM +0200, Florian Westphal wrote:
> Slavko <linux@slavino.sk> wrote:
> > + from 6.15 it will work even in input hook and lo as expected
> 
> Yes.
> 
> > + before 6.15 it doesn't work (properly) outside of prerouting
> >   hook only with lo traffic (other ifaces works)
> 
> Yes.  fib works fine but not for loopback traffic.

Florian, is it worth to request to include this update to -stable
kernels? Or you prefer the manpage note as it has been suggested?

Thanks.

Re: nftables RP filter and loopback

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Florian, is it worth to request to include this update to -stable
> kernels? Or you prefer the manpage note as it has been suggested?

I'll send a patch to update the nft_fib selftest to cover this,
then make a backport of the change that doesn't include the the
socket optimzation.

When I changed it I did not realize that this fixes a bug; I would
have split the change in two if I had.

Re: nftables RP filter and loopback

[Pablo Neira Ayuso]

On Wed, Apr 23, 2025 at 11:10:20AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Florian, is it worth to request to include this update to -stable
> > kernels? Or you prefer the manpage note as it has been suggested?
> 
> I'll send a patch to update the nft_fib selftest to cover this,
> then make a backport of the change that doesn't include the the
> socket optimzation.
>
> When I changed it I did not realize that this fixes a bug; I would
> have split the change in two if I had.

Yes, I didn't notice either. Anyway, unless you can forecast any
issue, I'd suggest to backport the entire patch? IIRC patch is
relatively small and keeping it in sync with main could possibly help
with cherrypicking fixes.

But your way is also fine with me.

Thanks.

Re: nftables RP filter and loopback

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Yes, I didn't notice either. Anyway, unless you can forecast any
> issue, I'd suggest to backport the entire patch? IIRC patch is
> relatively small and keeping it in sync with main could possibly help
> with cherrypicking fixes.

Right, it would keep -stable "bug compatible" too.

Maybe its ok to ask to cherry-pick it as is for
6.14 and 6.12.

6.13 is EOL already, 6.12 is longterm.

This would leave 6.6 and 6.1 longterm out but from lack
of bug reports so far I would not say its a prominent bug.

The upstream patch cherry-picks for all except 6.1.y, but
AFAICS its just a simple context conflict.

Earlier longterm kernels aren't affected.

Re: nftables RP filter and loopback

[Pablo Neira Ayuso]

On Wed, Apr 23, 2025 at 02:06:05PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Yes, I didn't notice either. Anyway, unless you can forecast any
> > issue, I'd suggest to backport the entire patch? IIRC patch is
> > relatively small and keeping it in sync with main could possibly help
> > with cherrypicking fixes.
> 
> Right, it would keep -stable "bug compatible" too.
> 
> Maybe its ok to ask to cherry-pick it as is for
> 6.14 and 6.12.

OK, let's request this cherry-pick for 6.12. Thanks

> 6.13 is EOL already, 6.12 is longterm.
> 
> This would leave 6.6 and 6.1 longterm out but from lack
> of bug reports so far I would not say its a prominent bug.
> 
> The upstream patch cherry-picks for all except 6.1.y, but
> AFAICS its just a simple context conflict.
> 
> Earlier longterm kernels aren't affected.

Re: nftables RP filter and loopback

[Pablo Neira Ayuso]

On Wed, Apr 23, 2025 at 10:56:41PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Apr 23, 2025 at 02:06:05PM +0200, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > Yes, I didn't notice either. Anyway, unless you can forecast any
> > > issue, I'd suggest to backport the entire patch? IIRC patch is
> > > relatively small and keeping it in sync with main could possibly help
> > > with cherrypicking fixes.
> > 
> > Right, it would keep -stable "bug compatible" too.
> > 
> > Maybe its ok to ask to cherry-pick it as is for
> > 6.14 and 6.12.
> 
> OK, let's request this cherry-pick for 6.12. Thanks

eaaff9b6702e ("netfilter: fib: avoid lookup if socket is available")

> > 6.13 is EOL already, 6.12 is longterm.
> > 
> > This would leave 6.6 and 6.1 longterm out but from lack
> > of bug reports so far I would not say its a prominent bug.
> > 
> > The upstream patch cherry-picks for all except 6.1.y, but
> > AFAICS its just a simple context conflict.
> > 
> > Earlier longterm kernels aren't affected.

Re: nftables RP filter and loopback

[Slavko]

Ahoj,

Dňa Tue, 22 Apr 2025 13:43:52 +0200 Florian Westphal <fw@strlen.de>
napísal:

> This is an input chain.  The loopback bypass is restricted
> to PRE_ROUTING before v6.15-rc1.

That opens another question, as i have in that chain:

    chain r_prerouting { # handle 1
        type filter hook input priority raw; policy accept;
        iif "lo" notrack accept comment "no lo conntrack" # handle 15
        ...
    }

Why this notrack works? The image about packet flow on [1] left me in
impression, that input hook happens after conntrack (as conntrack
priority is shown as part of prerouting hook), thus raw priority of
input hook is not important for that (just for ordering it), and thus
setting notrack in input hook is too late, despite of chain priority...

But it is not, it works, conntrack -L doesn't shows "lo" entries (nor
-E)... Please, can someone explain it for me? Does raw priority in
input (or more generic in any) hook run it before conntrack/DNAT,
despite of hook type?

What is then difference in between prerouting and input (and forward)
hooks, in conntrack/DNAT context?

(please approximate my question, my English is far from good)

[1] https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

regards

-- 
Slavko
https://www.slavino.sk

Re: nftables RP filter and loopback

[Florian Westphal]

Slavko <linux@slavino.sk> wrote:
> > This is an input chain.  The loopback bypass is restricted
> > to PRE_ROUTING before v6.15-rc1.
> 
> That opens another question, as i have in that chain:
> 
>     chain r_prerouting { # handle 1
>         type filter hook input priority raw; policy accept;
>         iif "lo" notrack accept comment "no lo conntrack" # handle 15
>         ...
>     }
> 
> Why this notrack works?

It doesn't work.

You either have no conntrack active at all or you have another notrack rule in
output ("lo" is picked up in output, not prerouting).

Re: nftables RP filter and loopback

[Slavko]

Ahoj,

Dňa Sat, 26 Apr 2025 11:24:47 +0200 Florian Westphal <fw@strlen.de>
napísal:

> You either have no conntrack active at all or you have another
> notrack rule in output ("lo" is picked up in output, not prerouting).

yes, you are right, i have opposite lo notrack in output chain and it
seems, that for "lo" <=> "lo" traffic it is enough (tested).

thanks

-- 
Slavko
https://www.slavino.sk