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: <aef5ec1d-c62f-9a1c-c6f3-c3e275494234@ssi.bg>
Date: Mon, 19 May 2025 23:11:09 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: Duan Jiong <djduanjiong@...il.com>
cc: 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


	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 <djduanjiong@...il.com>
> ---
>  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 <ja@....bg>