Re: [PATCH net] ipvs: SNAT packet replies only for NATed connections

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [PATCH net] ipvs: SNAT packet replies only for NATed connections
Cc: lvs-devel@xxxxxxxxxxxxxxx, Nick Moriarty <nick.moriarty@xxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Mon, 1 May 2017 11:28:59 +0300 (EEST)

On Mon, 1 May 2017, Simon Horman wrote:

> On Sat, Apr 29, 2017 at 08:33:09PM +0300, Julian Anastasov wrote:
> > We do not check if packet from real server is for NAT
> > connection before performing SNAT. This causes problems
> > for setups that use DR/TUN and allow local clients to
> > access the real server directly, for example:
> > 
> > - local client in director creates IPVS-DR/TUN connection
> > CIP->VIP and the request packets are routed to RIP.
> > Talks are finished but IPVS connection is not expired yet.
> > 
> > - second local client creates non-IPVS connection CIP->RIP
> > with same reply tuple RIP->CIP and when replies are received
> > on LOCAL_IN we wrongly assign them for the first client
> > connection because RIP->CIP matches the reply direction.
> > As result, IPVS SNATs replies for non-IPVS connections.
> > 
> > The problem is more visible to local UDP clients but in rare
> > cases it can happen also for TCP or remote clients when the
> > real server sends the reply traffic via the director.
> > 
> > So, better to be more precise for the reply traffic.
> > As replies are not expected for DR/TUN connections, better
> > to not touch them.
> > 
> > Reported-by: Nick Moriarty <nick.moriarty@xxxxxxxxxx>
> > Tested-by: Nick Moriarty <nick.moriarty@xxxxxxxxxx>
> > Signed-off-by: Julian Anastasov <ja@xxxxxx>
> > ---
> > 
> > I know that 4.11 is to be released soon, I prefer this patch
> > to linger in the net tree during the 4.12-rc cycle.
> I have no problem with queueing this up as a fix for v4.12 as you describe
> but do you also want it to be considered for -stable?

        Yes, I'll post patches for stable kernels later today.


Julian Anastasov <ja@xxxxxx>
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>