Thanks, so there lies the catch. If a rule is "breaking" an existing conntrack entry, it may then not be applied. So when the return packet comes in, the conntrack table gets inspected at the very first, if a match is found, and if there is a conflicting NAT rule that would alter the entry, thus possibly breaking the connection, this rule gets simply bypassed or ignored ? Did I understand right ? That was my missing point. There is some analysis done which explains the result of the lab. Thanks for your help On Sun, Oct 15, 2017 at 11:26:06AM -0400, zrm wrote: > On 10/15/2017 07:05 AM, LB wrote: > >Hi, > >I've been working on a setup with several SNAT/DNAT on a netfilter box recently and there is a point I cannot really understand. > >I've reproduced this behaviour in a lab (although through Debian 8 virtual machines) > > > >Setup is simple : (remember this is a test) > >VM A has 192.168.0.2 IP and default GW on 192.168.0.1 - is on network called A ("physically" wise) > >VM B has 192.168.1.2 IP and default GW on 192.168.1.1 - is on network called B > >a router VM : 192.168.0.1 & 192.168.1.1 (respectively on network A and B) > >router is simple : iptables, conntrack and ip_forward to 1. > > > >only one rule has been implemented : if flow is from B (192.168.1.2) towards A (192.168.1.2) then SNAT to 10.10.10.2 > > > >If I start a connection (let's say a SSH session) from B to A, the SNAT works, as I can see I'm connected from 10.10.10.2 (visible from tcpdump as well) and in conntrack entries. > >Now if I start a connection from A to B, no NAT rule will match. The B machine will see my originating connection from A (192.168.0.2). > >My question is there : the return flow of this connection , as per the netfilter diagrams I see, will reach conntrack first , in the PREROUTING, go into FORWARD, and then POSTROUTING. But here, in postrouting, the flow IS matching my SNAT rule, isn't it ? So why the return flow is not SNAT'ed to 10.10.10.2 (I can see in tcpdump it is not) > >I was under the feeling that once a conntrack entry is "matched" (sorry for the lack of precision), it would somehow "bypass" the SNAT (or DNAT) rewriting. > >Am I right ? > > A connection tracking entry is created from the first packet. If the > first packet doesn't match the SNAT rule then it gets created > without it. > > When the reply packet comes, then the SNAT rule matches, but by that > point the conflicting connection tracking entry already exists. > > It won't change the active connection tracking entry because that > would break the connection. 192.168.0.2 sent a packet to > 192.168.1.2. It expects a reply from 192.168.1.2, not 10.10.10.2. > > If you want symmetry then you also need a DNAT rule that matches > packets to 10.10.10.2 and DNATs them to 192.168.1.2, and A needs to > connect to B as 10.10.10.2. > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html