Re: Possible bug when bridging traffic we just SNATed and sent to another router

[Florian Westphal <fw@strlen.de>]

Daniel Collins <daniel.collins@smoothwall.net> 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.