nftables RP filter and loopback

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

 



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/





[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