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

Message-ID: <aCyHRcHJOhU9Ieih@strlen.de>
Date: Tue, 20 May 2025 15:44:37 +0200
From: Florian Westphal <fw@...len.de>
To: Julian Anastasov <ja@....bg>
Cc: Duan Jiong <djduanjiong@...il.com>, 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

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.