All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zoilo <zoilo@xs4all.nl>
To: zoilo@xs4all.nl, netfilter@lists.netfilter.org
Subject: NAT PREROUTING chain ignored on returning traffic ??
Date: Fri, 29 Aug 2003 20:57:08 +0200	[thread overview]
Message-ID: <3F4FA204.6010605@xs4all.nl> (raw)

I have 2 machines connected via a LAN: 192.168.192.254 and 
192.168.192.123. I will call the '254' and '123' from now on.

For the sake of it, I decided to 'rehearse' my netfilter theory, and ran 
the following script on .123:

#!/bin/bash

iptables -t filter -I INPUT -j LOG --log-prefix "filter INPUT: "
iptables -t filter -I OUTPUT -j LOG --log-prefix "filter OUTPUT: "
iptables -t filter -I FORWARD -j LOG --log-prefix "filter FORWARD: "

iptables -t nat -I PREROUTING -j LOG --log-prefix "nat PREROUTING: "
iptables -t nat -I OUTPUT -j LOG --log-prefix "nat OUTPUT: "
iptables -t nat -I POSTROUTING -j LOG --log-prefix "nat POSTROUTING: "

iptables -t mangle -I PREROUTING -j LOG --log-prefix "mangle PREROUTING: "
iptables -t mangle -I INPUT -j LOG --log-prefix "mangle INPUT: "
iptables -t mangle -I FORWARD -j LOG --log-prefix "mangle FORWARD: "
iptables -t mangle -I OUTPUT -j LOG --log-prefix "mangle OUTPUT: "
iptables -t mangle -I POSTROUTING -j LOG --log-prefix "mangle POSTROUTING: "

There is nothing else in the configuration.

Then I did a single 'ping' from one to the other, and vice versa, while 
logging at 123.

I) Here is the log on 123 in response to a 'ping -c 1 192.168.192.123' 
issued from 254:

Aug 29 20:07:04 lfs kernel: mangle PREROUTING: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP 
TYPE=8 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: nat PREROUTING: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP 
TYPE=8 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: mangle INPUT: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP 
TYPE=8 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: filter INPUT: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP 
TYPE=8 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: mangle OUTPUT: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=45404 PROTO=ICMP TYPE=0 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: filter OUTPUT: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=45404 PROTO=ICMP TYPE=0 CODE=0 ID=4615 SEQ=0
Aug 29 20:07:04 lfs kernel: mangle POSTROUTING: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=45404 PROTO=ICMP TYPE=0 CODE=0 ID=4615 SEQ=0

II) Here is the log on 123 in response to a 'ping -c 1 192.168.192.254' 
issued from 123 itself:

Aug 29 20:07:57 lfs kernel: mangle OUTPUT: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: nat OUTPUT: IN= OUT=eth0 SRC=192.168.192.123 
DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP 
TYPE=8 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: filter OUTPUT: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: mangle POSTROUTING: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: nat POSTROUTING: IN= OUT=eth0 
SRC=192.168.192.123 DST=192.168.192.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: mangle PREROUTING: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=39819 PROTO=ICMP 
TYPE=0 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: mangle INPUT: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=39819 PROTO=ICMP 
TYPE=0 CODE=0 ID=3105 SEQ=0
Aug 29 20:07:57 lfs kernel: filter INPUT: IN=eth0 OUT= 
MAC=00:40:63:ca:ee:3c:00:c0:4f:a6:7c:58:08:00 SRC=192.168.192.254 
DST=192.168.192.123 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=39819 PROTO=ICMP 
TYPE=0 CODE=0 ID=3105 SEQ=0

To my astonishment, in II) the returning ICMP packets do *not* travel 
through the NAT PREROUTING chain! In I) however, the incoming packets 
*do* travel through the NAT PREROUTING chain, as expected.

Fortunately, the behaviour is the same when the test is run on the other 
machine, so I am the problem, and not iptables (of course).

So why does a returning packet not travel through the NAT PREROUTING 
chain, whereas a new incoming ping does travel through the NAT 
PREROUTING chain? Both packets have exactly the same destination, huh?

Z.




             reply	other threads:[~2003-08-29 18:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-29 18:57 Zoilo [this message]
2003-08-31  5:31 ` NAT PREROUTING chain ignored on returning traffic ?? Jim Carter
2003-09-01 13:58   ` Zoilo
2003-09-01  7:46 ` Philip Craig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F4FA204.6010605@xs4all.nl \
    --to=zoilo@xs4all.nl \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.