conntrack and NAT rules behaviour on return path

conntrack and NAT rules behaviour on return path

[LB]

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 ?

I think I'm missing one big picture here (false positive somewhere) and I wanted to try on a very simple setup..
Thanks for your guidance

Re: conntrack and NAT rules behaviour on return path

[zrm]

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.

Re: conntrack and NAT rules behaviour on return path

[modano]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conntrack and NAT rules behaviour on return path

[Pascal Hambourg]

Le 15/10/2017 à 13:05, LB a écrit :
> 
> 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.

Sort of.

The nat table is special. Only the first packet of a NEW connection goes 
through the chains and rules of the nat table. All subsequent packets 
belonging or related to the same connection are processed according to 
which rules were applied to the first packet.