netfilter buglog - Jun 2023 - [Bug 1686] New: Transparent proxy support requires transport protocol match

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

            Bug ID: 1686
           Summary: Transparent proxy support requires transport protocol
                    match
           Product: nftables
           Version: git (please specify your HEAD)
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: pablo at netfilter.org
                CC: me at black-desk.cn

black_desk says:

"""

I wrote a nft script:

? cat test.nft
table inet test {
        set protos {
                typeof meta l4proto;
                elements = { tcp, udp }
        }
        chain prerouting {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto @protos tproxy to :1088
        }
}

when I pass it to nft:

? sudo nft -f ./test.nft
./test.nft:8:38-52: Error: Transparent proxy support requires
transport protocol match
                meta l4proto @protos tproxy to :1088
                                     ^^^^^^^^^^^^^^^

But it will work when I use anonymous set:

? cat anonymous.nft
table inet test {
        chain prerouting {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto { tcp, udp } tproxy to :1088 mark set 0x1 accept
        }
}

This script works.

I check source and I found that:

https://git.netfilter.org/nftables/tree/src/expression.c#n748
> ...
> else if (right->etype == EXPR_SET) {
> ...
This `relational_expr_pctx_update` function only handle EXPR_SET, but
not EXPR_SET_REF,
which leads to fucntion `stmt_evaluate_tproxy` failing at

https://git.netfilter.org/nftables/tree/src/evaluate.c#n3859

because of `pctx->protocol[PROTO_BASE_TRANSPORT_HDR].desc` unset.
"""

-- 
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/20230602/ed273966/attachment.html>

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

--- Comment #1 from me at black-desk.cn ---
HEAD: c88494c5fb4dc275f94df27f1f68996fd3925680

-- 
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/20230602/e4f4b92e/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #2 from Phil Sutter <phil at nwl.cc> ---
The accepted rule looks fine, though. I guess tproxy is OK with either TCP or
UDP packets, no?

-- 
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/20230602/91d30390/attachment.html>

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

--- Comment #3 from Chen Linxuan <me at black-desk.cn> ---
(In reply to Phil Sutter from comment #2)
> The accepted rule looks fine, though. I guess tproxy is OK with either TCP
> or UDP packets, no?
Yes. Both of them are working.

I just want to use named set here.

-- 
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/20230602/5d3bf40f/attachment.html>