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:

please avoid top-posting, thanks.

> +----+   +----+
> | R1 |   | R2 |
> +----+   +----+
>    |       |
> +-------------+
> | eth0   eth1 |
> |   \     /   |
> |    \   /    |
> |     br0     |
> +-------------+
> 
> So, the Linux box at the bottom attempts to route a packet from itself
> using R1, but R1 forwards the packet on to R2, at which point Linux
> creates a new conntrack and rewrites the port number as it passes over
> the bridge since that particular IP/port combination was already in
> use, by the first conntrack.
> 
> Does that make it clearer?

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.

I'd recommend to fix this setup... If that can't be done, can you
suppress creation of 2nd conntrack entry?

It should be possible via "-t raw -s local_address -j CT --notrack".