I have got a problem, posted in the forum as “Problematic destination NAT”. Thanks to sebastia and mkx, I successfully resolve the issue.
Shortly I configure:
dstnat, to rewrite external MK IP address, to PLC (PLC stands for Programmable Logic Controller) host IP address
srcnat, to rewrite reader IP address, to MK internal IP address, in order PLC to respond to the routers internal IP address, without using gateway.
The response to the reader is done by Connection tracking.
Now it is working as charm.
The reason, I am writing this post, is because I do not understand the “magic”, which allows MK receiving a packet from PLC with
src address: PLC address
dst address: MK internal IP address
,to sent TCP packet back to original sender (called reader)?
Gentlemen sebastia and mkx, told me that this is because the Connection Tracking. I can not find any detailed information how it is working.
Is there any one, who can provide more information and details, how MK, which receives packet with “local” IP address, will know to whom it must send the packet? Because in this packet, the src and dst IP addresses must be rewritten again as:
dst address: the IP address of reader
src address: the external MK IP address
On my test bench I am using three readers (each of them talk to unique MK external IP address), and everyone gets it packets.
Router watches all packets as they come and go and remembers stuff about them, source and destination addresses and ports, both original and changed (if there’s srcnat or dstnat involved).
For example, packet comes from 1.1.1.1:111 and wants to go to 2.2.2.2:222. There’s dstnat rule for it and changes destination to 3.3.3.3:333 and later srcnat rule changes source to 4.4.4.4:444. Router (connection tracking) remembers all this. When a reply comes back, it will be packet from 3.3.3.3:333 to 4.4.4.4:444. At first sigh, it has nothing to do with original addresses (with 1s and 2s). But conntrack looks in its records and will know that it belongs to known connection. So it reverses previous NAT changes and sends the reply to original client (i.e. it will be packet from 2.2.2.2:222 to 1.1.1.1:111).
It’s a little more complex, e.g. with tcp, which has defined behaviour how to establish connections, conntrack also checks if everything is correct. If not and it sees some “random” packet that doesn’t belong to anything, it marks its connection state as invalid.
Next level are special modules for some traffic, e.g. for ftp, where conntrack is even more active, inspects control connection (looks inside packets) and it changes even other connections based on the info it gets from there.