Daniel Collins <daniel.collins@xxxxxxxxxxxxxx> 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". -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
