netdev - Re: [PATCH] ipvs: skip ipvs snat processing when packet dst is not vip

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] [day] [month] [year] [list]

Message-ID: <CALttK1SaxBT-iuRDixBd-2o8SF25DXujV+dfZEoR7bNOFFuPbA@mail.gmail.com>
Date: Wed, 21 May 2025 10:04:43 +0800
From: Duan Jiong <djduanjiong@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Julian Anastasov <ja@....bg>, pablo@...filter.org, netdev@...r.kernel.org, 
	lvs-devel@...r.kernel.org
Subject: Re: [PATCH] ipvs: skip ipvs snat processing when packet dst is not vip

On Tue, May 20, 2025 at 9:45 PM Florian Westphal <fw@...len.de> wrote:
>
> Julian Anastasov <ja@....bg> wrote:
> >       But the following packet is different from your
> > initial posting. Why client connects directly to the real server?
> > Is it allowed to have two conntracks with equal reply tuple
> > 192.168.99.4:8080 -> 192.168.99.6:15280 and should we support
> > such kind of setups?
>
> I don't even see how it would work, if you allow
>
> C1 -> S
> C2 -> S
>
> ... in conntrack and you receive packet from S, does that need to
> go to C1 or C2?
>
> Such duplicate CT entries are free'd (refused) at nf_confirm (
> conntrack table insertion) time.

iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE

Indeed, there is nothing wrong with this logic, but after I added the MASQUERADE
rule, it seems that I did snat before confirm causing the source port to change