From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: Possible bug when bridging traffic we just SNATed and sent to another router Date: Fri, 5 Jun 2015 18:38:01 +0200 Message-ID: <20150605163801.GK11015@breakpoint.cc> References: <20150605143542.GH11015@breakpoint.cc> <20150605150827.GJ11015@breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Westphal , netfilter-devel@vger.kernel.org To: Daniel Collins Return-path: Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:38760 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422908AbbFEQiE (ORCPT ); Fri, 5 Jun 2015 12:38:04 -0400 Content-Disposition: inline In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Daniel Collins wrote: > > So just to make sure: > > > > #1 Linux send skb from (local_addr,daddr) > > #2 r1 forwards packet to r2 > > #3 Linux receives its own packet again, with (saddr local_addr, daddr) > > #4 Linux creates a new conntrack entry since lookup for old one would > > expect (local_addr is daddr) reply > > #5 new conntrack is created, with PAT applied to resolve port clash > > collision > > #6 remote_addr sends reply, to local_addr > > #7 we lookup conntrack, find the one without PAT translation applied > > #8 we possibly toss the packet since PAT undo doesn't (yet) yield > > skb with a socket. > > Yes > > > I'd recommend to fix this setup... If that can't be done, can you > > suppress creation of 2nd conntrack entry? > > This configuration has been used by a small handful of our customers, > we are probably going to get them to fix their routing tables. > > > It should be possible via "-t raw -s local_address -j CT --notrack". > > Considered this, but doesn't work for us in all cases (tproxy!). TPROXY doesn't depend on conntrack. But other than the notrack suggestion i don't have any ideas.