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  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]
Date:   Fri, 7 Oct 2022 08:42:21 -0600
From:   David Ahern <>
To:     Jakub Kicinski <>,
        Maximilien Cuony <>
Cc:, Phil Sutter <>,
        Florian Westphal <>,
        Mike Manning <>,
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:

In short, users complained of the opposite problem.

Not sure how we can appease both wants.

Powered by blists - more mailing lists