[Bug 1773] New: tproxy with nftables collides with nat entries

[bugzilla-daemon at netfilter.org]

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

            Bug ID: 1773
           Summary: tproxy with nftables collides with nat entries
           Product: netfilter/iptables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: netfilter hooks
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: antonio.ojea.garcia at gmail.com

It took me a while to figure out the problem when working with nftables tproxy
for UDP in a kubernetes environment, until I found the explanation on
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20180628164258.25646-1-ecklm94@gmail.com/


>  - tproxy statement is not terminal here

When trying to implement a transparent proxy for a DNS server, I could observe
that only the first connection was redirected, subsequent connections with the
same tuple were sent to the actual DNAT destination.

Assume a Pod/Namespace client with IP 100.96.1.14
A virtual IP for the DNS service 100.64.0.10 that forwards traffic to 100.96.1.
and 10.96.1.12 
An UDP transparent proxy server listening on port 12345
Rules to intercept the DNS traffic (fwmark rule and anyip route are ok)

table inet kindnet-dnscache {
        comment "rules for kindnet dnscache"
        chain prerouting {
                type filter hook prerouting priority dstnat - 10; policy
accept;
                meta mark 0x0000000c return
                ip saddr 100.96.1.0/24 ip daddr 100.64.0.10 udp dport 53 tproxy
ip to 127.0.0.1:12345 accept comment "DNS IPv4 pod originated traffic"
        }
}


When connecting from 100.96.1.14:8888 to 100.64.0.10:53, the tproxy rule
redirect the connection to localhost:12345

When tracing the nftables rules with "nft monitor" I could observe that the
tproxy statement verdict was accepted, but the subsequent rules were matched
and the corresponding conntrack entries for NAT were added


    [NEW] udp      17 30 src=100.96.1.14 dst=100.64.0.10 sport=42345 dport=53
[UNREPLIED] src=100.96.1.12 dst=100.96.1.14 s
port=53 dport=42345
    [NEW] udp      17 30 src=100.64.0.10 dst=100.96.1.14 sport=53 dport=42345
[UNREPLIED] src=100.96.1.14 dst=100.64.0.10 sport=42345 dport=81
[DESTROY] udp      17 src=100.64.0.10 dst=100.64.0.10 sport=34943 dport=53
src=100.96.1.12 dst=100.96.1.1 sport=53 dport=58102



A workaround that seems to work fine is to no track the tproxy traffic

table inet kindnet-dnscache {
        comment "rules for kindnet dnscache"
        chain prerouting {
                type filter hook prerouting priority raw - 10; policy accept;
                meta mark 0x0000000c return
                ip saddr 100.96.1.0/24 ip daddr 100.64.0.10 udp dport 53 tproxy
ip to 127.0.0.1:54136 meta mark set 0x0000000b notrack accept comment "DNS IPv4
pod originated traffic"
        }
}



I personally found surprising the tproxy action is not terminal, as it is
actually the intent of the user to steal the traffic and redirect to the port.

I don't know at this point if is feasible to break this behavior, as it sounds
strange that somebody relies on  it, although I'm sure we have seen worse :)
https://imgs.xkcd.com/comics/workflow.png

It will be desirable for this tproxy action to be terminal, if not by default,
at least give the user some knob to opt-in to making it terminal

-- 
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/20240911/49d8ef3c/attachment.html>