[Bug 1761] New: nft_fib checks only the main route table when iif is a slave of a master vrf interface

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1761

            Bug ID: 1761
           Summary: nft_fib checks only the main route table when iif is a
                    slave of a master vrf interface
           Product: nftables
           Version: 1.0.x
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: kernel
          Assignee: pablo at netfilter.org
          Reporter: tsv1991 at gmail.com

Root case: 
I want to do the NOTRACK in the PREROUTING chain for traffic that has a "daddr"
route pointing to a specific oif.

What I do: 
"nft add rule inet notracks PREROUTING fib daddr oif br999 counter notrack"

The issue: 
nftables always checks only main routing table, though the iif for traffic is
slave for master vrf interface also oif always will be slave for master vrf
interface.

Details: 
We have VRF vrf1 and interfaces br100 and br999 as slaves of interface vrf1.
Interface br100 receives traffic. We want to make a notrack in the PREROUTING
hook for this traffic on condition that it will be forwarded to interface
br999. When we add rule "nft add rule inet notracks PREROUTING fib daddr oif
br999 counter notrack" we see that nftables checks only main fib table. I think
nftables should be able to discover the VRF master interface for the incoming
interface (br100) and check the fib vrf1 routing table.

I tried to research this issue and found that:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/netfilter/nft_fib_ipv4.c#n87
I think the check should be extended and always consider is iif a slave for
master vrf interface for checking in right routing table.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240716/77ee4a3e/attachment.html>