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

Duan Jiong <[email protected]> Wed, 21 May 2025 10:04:43 +0800
Newsgroups org.kernel.vger.lvs-devel,org.kernel.vger.netdev
Message-ID <CALttK1SaxBT-iuRDixBd-2o8SF25DXujV+dfZEoR7bNOFFuPbA@mail.gmail.com>
On Tue, May 20, 2025 at 9:45 PM Florian Westphal <[email protected]> wrote:
>
> Julian Anastasov <[email protected]> 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