netfilter buglog - Jan 2020 - [Bug 1398] New: tproxy rule is not matched for ip6

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

            Bug ID: 1398
           Summary: tproxy rule is not matched for ip6
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Ubuntu
            Status: NEW
          Severity: normal
          Priority: P5
         Component: kernel
          Assignee: pablo at netfilter.org
          Reporter: m1588m at gmail.com

All rules were created at the same time, however the rule with tproxy verdict
is not matched for some reason:

nft list table inet nat
table inet nat {
    chain divert {
        type filter hook prerouting priority mangle; policy accept;
        ip6 version 6 udp dport 53 counter packets 5 bytes 470
        ip6 version 6 udp dport 53 tproxy ip6 to :5304 counter packets 0 bytes
0
        ip6 version 6 udp dport 53 counter packets 5 bytes 470 accept
    }
}

Tested on ubuntu linux kernel 4.20.17-042017-generic and nft 20190515 snapshot.

Please, advice, what are the next steps to narrow down the root cause.

-- 
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/20200116/5ad2de80/attachment.html>

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

Balazs Scheidler <bazsi77 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bazsi77 at gmail.com

--- Comment #1 from Balazs Scheidler <bazsi77 at gmail.com> ---
tproxy is not doing NAT, so it would only match in case there's an open
socket
with IP_TRANSPARENT setsockopt set:

       IP_TRANSPARENT (since Linux 2.6.24)
              Setting  this  boolean  option enables transparent proxying on
this socket.  This socket option allows the calling application to bind to a
nonlocal IP address and operate
              both as a client and a server with the foreign address as the
local endpoint.  NOTE: this requires that routing be set up in a  way  that 
packets  going  to  the  foreign
              address  are  routed through the TProxy box (i.e., the system
hosting the application that employs the IP_TRANSPARENT socket option). 
Enabling this socket option requires
              superuser privileges (the CAP_NET_ADMIN capability).

              TProxy redirection with the iptables TPROXY target also requires
that this option be set on the redirected socket.


If either the socket is not found or the flag is not set, it will just break
out
from the evaluation, thus the counters will not be processed.


quoting net/netfilter/nft_tproxy.c:

        if (sk && nf_tproxy_sk_is_transparent(sk))
                nf_tproxy_assign_sock(skb, sk);
        else
                regs->verdict.code = NFT_BREAK;

This might be a bit unintuitive as this is actually an "error"
condition which
is not reported in any way:
the rule to be processed successfully needs the userspace daemon to be running.

-- 
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/20200801/f42d6928/attachment.html>

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

Balazs Scheidler <bazsi77 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #2 from Balazs Scheidler <bazsi77 at gmail.com> ---
I think this is working as intended, setting the resolution accordingly. Please
REOPEN if you disagree.

-- 
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/20200801/58cc1409/attachment-0001.html>