On 5/15/19 05:22, Reindl Harald wrote:
Am 15.05.19 um 06:29 schrieb zrm:
I added this rule:
iptables -t nat -A INPUT -p icmp -j LOG
Then when I ping localhost, nothing is logged. If I add the same rule to
nat POSTROUTING, then the packet is logged, implying that nat
POSTROUTING is being traversed for locally-destined locally-generated
packets rather than nat INPUT.
This is not what I would have expected from the documentation.
I tried the same thing with the same chains in the mangle table and in
that case POSTROUTING and INPUT are *both* traversed for local-to-local
packets.
Is this (including the inconsistency between nat and mangle) the
intended behavior for some reason or is it a bug?
why should "ping localhost" ever touch the INPUT chain of NAT?
DNAT -> PREROUTING
SNAT -> POSTROUTING
https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png
Because (pursuant to iptables(8)) the nat INPUT chain is "for altering
packets destined for local sockets" and the packet is destined for the
local machine. (We need not get into whether ICMP echo is to a "socket";
it's the same behavior for TCP.)
Moreover, the localhost packet does not use nat PREROUTING, it uses nat
OUTPUT as expected.
That diagram is neither descriptive nor normative; it's simply
inaccurate. It shows "localhost dest" skipping nat POSTROUTING even
though in practice it doesn't. It also fails to show the
localhost-localhost packet traversing mangle INPUT and filter INPUT,
even though in practice it does.
The behavior I had expected was that after the OUTPUT chains there would
be a routing decision, then for a remote destination nat POSTROUTING
would be used and for a localhost destination nat INPUT would be used,
but it appears that in practice nat POSTROUTING is used in both cases.
Which I'm increasingly suspecting is a bug, possibly a holdover from the
days before nat INPUT existed.
