just for my understanding, if we do a SNAT (LAN to WAN), the internal source LAN-IP is replaced by the external WAN-IP.
On the way back, the router must reverse this operation - technically a DNAT, even though you never configure it. The reverse operation is done automatically.
But at which point in the packet flow is this done? I assume the reversed-SNAT (DNAT) is done at the prerouting chain at the DST-NAT point? Because it is technically a DNAT.
And I assume further, if a DNAT was done initally (eg. you host something internally and expose a port to the WAN), on the way back a reversed-DNAT (SNAT) is done. Is this done at at the SNAT point in the postrouting chain?
reversed SNAT “DNAT” is done at the prerouting chain DNAT-point
reversed DNAT “SNAT” is done at the postrouting chain SNAT-point
Or are these reverse operations done at the original position (from the inital connection) at the packet flow:
reversed SNAT “DNAT” is done at the postrouting chain SNAT-point
reversed DNAT “SNAT” is done at the prerouting chain DNAT-point
Yes, the “un-src-nat” is done in connection tracking in the prerouting chain. And the “un-dst-nat” is done in connection tracking in the postrouting (or output) chain.
Thanks my first assumption but in the connection tracking.
reversed SNAT “DNAT” is done at the prerouting chain connection tracking-point
reversed DNAT “SNAT” is done at the postrouting chain connection tracking-point
In the packet flow diagram I can not find a “Connection Tracking” in the postrouting chain.
Does this mean the reverse S/D-NAT is done in the adjacent DST-NAT and SRC-NAT points or there is a “hidden” Connection Tracking step in the postrouting chain?
Or are going such packets from point I to point J → Router Process and enter back at point K [Output (here is a Connection Tracking) → Portrouting] and leave through point L
Sorry, maybe my answer was confusing as it wasn’t adjusted to the simplification in the packet flow diagram.
The conntrack module is responsible for changing the source and/or destination addresses of every packet of each connection for whose initial packet the need for such changes has been ordered by the src-nat and/or dst-nat rules in the nat table. But the conntrack module also does other things, that’s probably why the connection tracking “brick” is placed separately in the diagram and is missing it the postrouting chain. So where the src-nat and dst-nat “bricks” are drawn on the packet flow diagram, the actual address changes are executed by the conntrack module, and also the nat rules are evaluated for the initial packet of each connection.
And yes, the src-nat “brick” does both the actual src-nat for the downstream packets as well as “un-dst-nat” of the upstream packets of each connection; the dst-nat “brick” does both the dst-nat for downstream packets and “un-src-nat” for upstream packets. Downstream is from the connection initiator (client) to the connection responder (server), upstream is the opposite one.
