mjhjmtu

I observed that MASQUERADE target does not match on packets in the reply direction (in terms of netfilter conntrack).

I've a single simple -t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE rule, nothing else besides of ACCEPT policies on all chains, and it seems that

case 1) SYN packets of connection initialization attempts from 10.a/16 network get NAT-ed (this is OK), while

case 2) SYN/ACK packets again from 10.a/16 network (in response to SYN from 10.b/16, ie. the initiator is 10.b/16 in this case) do not get translated, but src address is kept as-is, simply routed.

I'm not sure is it the expected behaviour or i missed something? I mean I dont want it to behave any other way, everything seems working. but the documentation did not confirm to me that this is the factory-default behaviur of the MASQUERADE target.

Could you confirm it? thanks.

The identity of a TCP connection is defined by a set of four things:

• the IP address of endpoint A


• the IP address of endpoint B


• the port number of endpoint A


• the port number of endpoint B

The TCP protocol standard says that if any of these four things are changed, the packet must not be considered part of the same connection. As a result, it makes no sense to start applying a NAT rule to a SYN/ACK packet if the initial SYN was also not NATted. You must either apply the same kind of NAT mapping for the entire connection from the start to finish, or not NAT it at all; any attempt to add or change a NAT mapping mid-connection will just cause the TCP connection to fail. This is a fundamental fact of the TCP protocol, and the Linux iptables/netfilter code is designed to take it into account.

In your case 2), the SYN/ACK is preceded by a SYN from 10.b/16. That SYN has a source of 10.b/16, so it does not match the MASQUERADE rule and gets routed with addresses kept as-is. Then, if the SYN/ACK from 10.a/16 back to 10.b/16 would be translated, the sender of the original SYN would no longer recognize it as a response to its own SYN, as the source IP + destination IP + source port + destination port combination would be different from what is expected for a valid response.

Essentially, the TCP protocol driver in the system that initiated the connection in 10.b/16 would then be thinking: "Sigh. The 10.a.connection.destination is not answering. And 10.b.NAT.system is bothering me with clearly spurious SYN/ACKs: I'm attempting to connect 10.a.connection.destination, not him. If I have time, I'll send a RST or two to 10.b.NAT.system; hopefully he realizes his mistake and stops bothering me."

MASQUERADE is just SNAT (source NAT) with the source of the outgoing interface (see man iptables-extensions.

The connection attempt (the initial SYN) is NATed, and then the connection is tracked in the kernel ("conntrack"), and all packets in this connection are NATed in the appropriate direction.

So yes, outgoing SYN/ACK answers to incoming SYNs won't get NATed by SNAT. If you want to NAT incoming SYNs, you need DNAT, not SNAT. This will then also NAT the SYN/ACK answers.

It happens, because when packet goes into oposite direction it's source is 10.b/24 and destination 10.a/24 which means, that it will not be handeled by your rule. You have to add two rules to make MASQUERADE happening:

-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE
-t nat -A POSTROUTING -s 10.b.0.0/16 -d 10.a.0.0/16 -j MASQUERADE