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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 12 Oct 2022 14:24:11 +0200
From:   Maximilien Cuony <maximilien.cuony@...anite.ch>
To:     Mike Manning <mvrmanning@...il.com>
Cc:     netdev@...r.kernel.org, Phil Sutter <phil@....cc>,
        Florian Westphal <fw@...len.de>,
        David Ahern <dsahern@...nel.org>,
        netfilter-devel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>
Subject: Re: [REGRESSION] Unable to NAT own TCP packets from another VRF with
 tcp_l3mdev_accept = 1

On 10/7/22 18:47, Mike Manning wrote:
> Hi Maximilien,
>
> Apologies that you have now hit this issue. Further to David's reply
> with the link for the rationale behind the change, the bisected commit
> you found restores backwards compatibility with the 4.19 kernel to allow
> a match on an unbound socket when in a VRF if tcp_l3mdev_accept=1, the
> absence of this causing issues for others. Isolation between default and
> other VRFs as introduced by the team I worked for back in 2018 and
> introduced in 5.x kernels remains guaranteed if tcp_l3mdev_accept=0.
>
> There is no appetite so far to introduce yet another kernel parameter to
> control this specific behavior, see e.g.
> https://lore.kernel.org/netdev/f174108c-67c5-3bb6-d558-7e02de701ee2@gmail.com/
Ok, I do understand it's tricky to satisfy both side and adding a 
parameter for each cases is probably not sustainable ^^'
> Is there any possibility that you could use tcp_l3mdev_accept=0 by
> running any services needed in the VRF with 'ip vrf exec <vrf> <cmd>'?
Yes, we will try to do that, there was some complication but it's 
probably easier and better for the future.
> Is the problem specific to using NAT for eth2 in the VRF, i.e. have you
> tried on another interface in that VRF, or on eth2 without NAT config?
If we try to NAT on another interface in the VRF it doesn't work. 
Without NAT it does work.
> No doubt you are doing this, but can I also check that your VRF config
> is correct according to
> https://www.kernel.org/doc/Documentation/networking/vrf.txt , so
> reducing the local lookup preference, etc., e.g.

Yes, rules/preferences are correct - I think by ifupdown2 during 
interface activation.

So we will try to not to have to use tcp_l3mdev_accept=1 to make it 
working as expected.

Thanks for you help and have a nice day :)

-- 
Maximilien Cuony