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

	Hello,

	Adding lvs-devel@ to CC...

On Mon, 19 May 2025, Duan Jiong wrote:

> Now suppose there are two net namespaces, one is the server and
> its ip is 192.168.99.4, the other is the client and its ip
> is 192.168.99.5, and the other is configured with ipvs vip
> 192.168.99.6 in the host net namespace, configuring ipvs with
> the backend 192.168.99.5.
> 
> Also configure
> iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
> to avoid packet loss when accessing with the specified
> source port.

	May be I don't quite understand why the MASQUERADE
rule is used...

> 
> First we use curl --local-port 15280 to specify the source port
> to access the vip, after the request is completed again use
> curl --local-port 15280 to specify the source port to access
> 192.168.99.5, this time the request will always be stuck in
> the main.
> 
> The packet sent by the client arrives at the server without
> any problem, but ipvs will process the packet back from the
> server with the wrong snat for vip, and at this time, since
> the client will directly rst after receiving the packet, the
> client will be stuck until the vip ct rule on the host
> times out.
> 
> Signed-off-by: Duan Jiong <[email protected]>
> ---
>  net/netfilter/ipvs/ip_vs_core.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index c7a8a08b7308..98abe4085a11 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1260,6 +1260,8 @@ handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
>  		unsigned int hooknum)
>  {
>  	struct ip_vs_protocol *pp = pd->pp;
> +	enum ip_conntrack_info ctinfo;
> +	struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
>  
>  	if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
>  		goto after_nat;
> @@ -1270,6 +1272,12 @@ handle_response(int af, struct sk_buff *skb, struct ip_vs_proto_data *pd,
>  		goto drop;
>  
>  	/* mangle the packet */
> +	if (ct != NULL &&
> +	    hooknum == NF_INET_FORWARD &&
> +	    !ip_vs_addr_equal(af,
> +		    &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3,
> +		    &cp->vaddr))
> +		return NF_ACCEPT;

	Such check will prevent SNAT for active FTP connections
because their original direction is from real server to client.
In which case ip_vs_addr_equal will see difference? When
Netfilter creates new connection for packet from real server?
It does not look good IPVS connection to be DNAT-ed but not
SNAT-ed.

	May be you can explain better what IPs/ports are present in
the transferred packets.

>  	if (pp->snat_handler &&
>  	    !SNAT_CALL(pp->snat_handler, skb, pp, cp, iph))
>  		goto drop;
> -- 
> 2.32.1 (Apple Git-133)

Regards

--
Julian Anastasov <[email protected]>