netdev - Re: [REGRESSION] Unable to NAT own TCP packets from another VRF with tcp_l3mdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c898f060-90f7-d6a5-4f3d-8d40428b5c83@kernel.org>
Date:   Fri, 7 Oct 2022 08:42:21 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>,
        Maximilien Cuony <maximilien.cuony@...anite.ch>
Cc:     netdev@...r.kernel.org, Phil Sutter <phil@....cc>,
        Florian Westphal <fw@...len.de>,
        Mike Manning <mvrmanning@...il.com>,
        netfilter-devel@...r.kernel.org
Subject: Re: [REGRESSION] Unable to NAT own TCP packets from another VRF with
 tcp_l3mdev_accept = 1

On 9/30/22 6:42 PM, Jakub Kicinski wrote:
> Adding netfilter and vrf experts.
> 
> On Wed, 28 Sep 2022 16:02:43 +0200 Maximilien Cuony wrote:
>> Hello,
>>
>> We're using VRF with a machine used as a router and have a specific 
>> issue where the router doesn't handle his own packets correctly during 
>> NATing if the packet is coming from a different VRF.
>>
>> We had the issue with debian buster (4.19), but the issue solved itself 
>> when we updated to debian bullseye (5.10.92).
>>
>> However, during an upgrade of debian bullseye to the latest kernel, the 
>> issue appeared again (5.10.140).
>>
>> We did a bisection and this leaded us to 
>> "b0d67ef5b43aedbb558b9def2da5b4fffeb19966 net: allow unbound socket for 
>> packets in VRF when tcp_l3mdev_accept set [ Upstream commit 
>> 944fd1aeacb627fa617f85f8e5a34f7ae8ea4d8e ]".
>>

This is the discussion that led up to that commit:

https://lore.kernel.org/netdev/940fa370-08ce-1d39-d5cc-51de8e853b47@gmail.com/

In short, users complained of the opposite problem.

Not sure how we can appease both wants.