ipvs: SNAT packet replies only for NATed connections
authorJulian Anastasov <ja@ssi.bg>
Sat, 29 Apr 2017 17:33:09 +0000 (20:33 +0300)
committerSimon Horman <horms@verge.net.au>
Mon, 8 May 2017 09:38:35 +0000 (11:38 +0200)
commit3c5ab3f395d66a9e4e937fcfdf6ebc63894f028b
tree6cc9ef95b9131629b3e3d4d610d3d4020b11b9cc
parentf411af6822182f84834c4881b825dd40534e7fe8
ipvs: SNAT packet replies only for NATed connections

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@york.ac.uk>
Tested-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
net/netfilter/ipvs/ip_vs_core.c