netfilter buglog - Aug 2023 - [Bug 1700] New: Flowtable - Bug on devices deinition

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

            Bug ID: 1700
           Summary: Flowtable - Bug on devices deinition
           Product: nftables
           Version: 1.0.x
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: nicolasfort1988 at gmail.com

--- Kernel and packages ---
Kernel: 6.1.45

vyos at vyos# sudo dpkg -l | grep nft
ii  libnftables1:amd64                   1.0.8-1                          amd64
       Netfilter nftables high level userspace API library
ii  libnftnl11:amd64                     1.2.6-1                          amd64
       Netfilter nftables userspace API library
ii  miniupnpd-nftables                   2.3.1-1                          amd64
       UPnP and NAT-PMP daemon for gateway routers - nftables backend
ii  nftables                             1.0.8-1                          amd64
       Program to control packet filtering rules by Netfilter project

--- Scenario ---
* Traffic passing through the router through eth3 and eth4
* interfaces eth1 and eth2 are not in use (unplugged)
* While defining flowtable for interfaces eth1 and eth2, I would expect no
OFFLOAD flag in conntrack.
* However, I see OFFLOAD for all udp sessions (1k).
* Also, while defining no interfaces/devices in the flowtable definition, I
 still get OFFLOAD (example exposed above).

--- Interface configuration ---
* eth3 and eth4 used for routing
* eth1 and eth2 unpluged:

vyos at picopc# ip a
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
group
default qlen 1000
    link/ether 00:f0:cb:ef:dd:f8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2f0:cbff:feef:ddf8/64 scope link tentative 
       valid_lft forever preferred_lft forever
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
group
default qlen 1000
    link/ether 00:f0:cb:ef:dd:f9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2f0:cbff:feef:ddf9/64 scope link tentative 
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group
default qlen 1000
    link/ether 00:02:c9:cd:86:7c brd ff:ff:ff:ff:ff:ff
    inet 16.0.0.1/8 brd 16.255.255.255 scope global eth3
       valid_lft forever preferred_lft forever
    inet6 fe80::202:c9ff:fecd:867c/64 scope link 
       valid_lft forever preferred_lft forever
6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group
default qlen 1000
    link/ether 00:02:c9:cd:86:7d brd ff:ff:ff:ff:ff:ff
    inet 15.0.0.1/8 brd 15.255.255.255 scope global eth4
       valid_lft forever preferred_lft forever
    inet6 fe80::202:c9ff:fecd:867d/64 scope link 
       valid_lft forever preferred_lft forever

--- ip filter table ---
vyos at vyos# sudo nft list table ip vyos_filter
table ip vyos_filter {
    flowtable ft_test03 {
        hook ingress priority filter
    }

    chain VYOS_FORWARD_filter {
        type filter hook forward priority filter; policy accept;
        ip protocol udp counter packets 1385097903 bytes 2077646854500 flow add
@ft_test03
        meta l4proto { tcp, udp } counter packets 2076678808 bytes
3115018212000 accept comment "FWD-filter-10"
    }

    chain VYOS_INPUT_filter {
        type filter hook input priority filter; policy accept;
    }

    chain VYOS_OUTPUT_filter {
        type filter hook output priority filter; policy accept;
    }

    chain VYOS_FRAG_MARK {
        type filter hook prerouting priority -450; policy accept;
        ip frag-off & 16383 != 0 meta mark set 0x000ffff1 return
    }
}
[edit]

--- Contrack output while traffic passing through eth3-eth4 ---
vyos at vyos# sudo conntrack -L | grep -c OFFLOAD
conntrack v1.4.6 (conntrack-tools): 1011 flow entries have been shown.
1000
[edit]
vyos at vyos#

-- 
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/20230822/26d4b0ea/attachment.html>

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

--- Comment #1 from nicolasfort1988 at gmail.com ---
So, it seems that defining flowtable and appropriate rule in forward-filter,
it's enough to OFFLOAD all connections that goes through the router, no
matter
if *devices* are define properly, or interfaces involved are bit included in
the flowtable definition

-- 
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/20230822/14c62072/attachment.html>

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

--- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> ---
You have to narrow down this rule to what flows get into the flowtable:

 iifname { eth1, eth2 } ip protocol udp counter packets 1385097903 bytes
2077646854500 flow add @ft_test03

in case you want flowtable coming from from eth1 and eth2.

*Your ruleset determines what flows get added to the flowtable*.

This flowtable in the example below specify no devices:

 table ip vyos_filter {
    flowtable ft_test03 {
        hook ingress priority filter
    }

The devices you specify in the flowtable declaration determine from what device
the flowtable look up is done.

-- 
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/20230822/36e7b605/attachment.html>

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

--- Comment #3 from nicolasfort1988 at gmail.com ---
So there's no correlation between 'devices' definition in flowtable,
and
'iifname' in ruleset?

For example:
vyos at picopc# sudo nft list table ip vyos_filter
table ip vyos_filter {
    flowtable ft_test {
        hook ingress priority filter
        devices = { eth1, eth2 }
    }

    chain VYOS_FORWARD_filter {
        type filter hook forward priority filter; policy accept;
        iifname { "eth3", "eth4" } ip protocol udp counter
packets 34409310
bytes 51613965000 flow add @ft_test
        meta l4proto { tcp, udp } counter packets 2111088123 bytes
3166632184500 accept comment "FWD-filter-10"
    }

    chain VYOS_INPUT_filter {
        type filter hook input priority filter; policy accept;
    }

    chain VYOS_OUTPUT_filter {
        type filter hook output priority filter; policy accept;
    }

    chain VYOS_FRAG_MARK {
        type filter hook prerouting priority -450; policy accept;
        ip frag-off & 16383 != 0 meta mark set 0x000ffff1 return
    }
}
[edit]
vyos at picopc# sudo conntrack -L | grep -c OFFLOAD
conntrack v1.4.6 (conntrack-tools): 1016 flow entries have been shown.


Seems like 'device' deifnition in flowtables is unnecessary, and what
really
matters is interace mather in the rule.

-- 
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/20230822/6f222c8c/attachment.html>

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

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
1) Your ruleset determines what flows are added to the flowtable. Below your
ruleset adds entries to the flowtable for UDP packets coming in from eth1 and
eth2.
2) The devices you specify in the flowtable declaration determine where the
flowtable hooks in the pipeline for lookups, in the example below, it registers
a hook for devices eth1 and eth2 in the ingress hook at priority 0.

The ruleset should be:

table ip vyos_filter {
     flowtable ft_test {
        hook ingress priority filter
        devices = { eth1, eth2 }
    }

     chain VYOS_FORWARD_filter {
         type filter hook forward priority filter; policy accept;
         iifname { "eth1", "eth2" } ip protocol udp counter
flow add @ft_test
                meta l4proto { tcp, udp } counter accept comment
"FWD-filter-10"
     }

 }

-- 
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/20230822/f37bf494/attachment.html>

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

--- Comment #5 from nicolasfort1988 at gmail.com ---
Yes, I do agree that config should be as you remarked: consistence information
between 'devices' in flowtable declaration, and 'iifname' in
rule-set

What I'm trying to say is that in the end, for offloading, it seems it
doesn't
matter what interfaces I used in the flowtable definition. I could declare no
'devices' at al while defining the flowtable, and then in ruleset just
use
iffnames for flows I want to offload.

If that's the case, then info in
https://wiki.nftables.org/wiki-nftables/index.php/Flowtables is not clear.
Since only relevant interface configuration seems to be needed in the ruleset,
and not in the flowtable definition.

-- 
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/20230822/8613a487/attachment-0001.html>

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

--- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to nicolasfort1988 from comment #5)
> Yes, I do agree that config should be as you remarked: consistence
> information between 'devices' in flowtable declaration, and
'iifname' in
> rule-set
> 
> What I'm trying to say is that in the end, for offloading, it seems it
> doesn't matter what interfaces I used in the flowtable definition. I
could
> declare no 'devices' at al while defining the flowtable, and then
in ruleset
> just use iffnames for flows I want to offload.
No devices in the flowtable declaration mean that no flowtable lookups occur
from the ingress path, hence, fast path is exercised.

If you specify no devices in the flowtable declaration, you add entries to the
flowtable, but they are never used because no flowtable lookup ever happens.
> If that's the case, then info in
> https://wiki.nftables.org/wiki-nftables/index.php/Flowtables is not clear.
> Since only relevant interface configuration seems to be needed in the
> ruleset, and not in the flowtable definition.
Both interface configurations are relevant.

-- 
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/20230822/425f50f5/attachment.html>

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

--- Comment #7 from Pablo Neira Ayuso <pablo at netfilter.org> ---
I take this as a feature request: You would like to have a way where flowtable
devices do not need to be specified, that is, flowtable autodiscovers the
devices where it has to listen for lookups. That is something I can explore.

-- 
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/20230825/5caf410d/attachment.html>