Linux Netfilter discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox