* NAT PREROUTING chain ignored on returning traffic ??
@ 2003-08-29 18:57 Zoilo
2003-08-31 5:31 ` Jim Carter
2003-09-01 7:46 ` Philip Craig
0 siblings, 2 replies; 4+ messages in thread
From: Zoilo @ 2003-08-29 18:57 UTC (permalink / raw)
To: zoilo, netfilter
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NAT PREROUTING chain ignored on returning traffic ??
2003-08-29 18:57 NAT PREROUTING chain ignored on returning traffic ?? Zoilo
@ 2003-08-31 5:31 ` Jim Carter
2003-09-01 13:58 ` Zoilo
2003-09-01 7:46 ` Philip Craig
1 sibling, 1 reply; 4+ messages in thread
From: Jim Carter @ 2003-08-31 5:31 UTC (permalink / raw)
To: Zoilo; +Cc: netfilter
On Fri, 29 Aug 2003, Zoilo wrote:
> 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.
--- snip ---
> Then I did a single 'ping' from one to the other, and vice versa, while
> logging at 123.
--- snip ---
> 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.
The NAT PREROUTING chain is for packets from outside the machine that
initiate a connection (whether thru traffic, or destined for the machine
itself). ICMP echo exchanges are tracked by conntrack and count as a
connection. So when on 254 you do "ping 123", 123 will log the packet in
the NAT table, whereas on 123 you do "ping 254", but the answer is part of
the established connection. The only NATting that will happen, happens on
254 when it gets the echo query packet.
Hope this helps!
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NAT PREROUTING chain ignored on returning traffic ??
2003-08-31 5:31 ` Jim Carter
@ 2003-09-01 13:58 ` Zoilo
0 siblings, 0 replies; 4+ messages in thread
From: Zoilo @ 2003-09-01 13:58 UTC (permalink / raw)
To: Jim Carter, Philip Craig; +Cc: netfilter
Thank you for this refresh cycle on my memory!
Z.
Jim Carter wrote:
>On Fri, 29 Aug 2003, Zoilo wrote:
>
>
>>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.
>>
>>
>--- snip ---
>
>
>>Then I did a single 'ping' from one to the other, and vice versa, while
>>logging at 123.
>>
>>
>--- snip ---
>
>
>>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.
>>
>>
>
>The NAT PREROUTING chain is for packets from outside the machine that
>initiate a connection (whether thru traffic, or destined for the machine
>itself). ICMP echo exchanges are tracked by conntrack and count as a
>connection. So when on 254 you do "ping 123", 123 will log the packet in
>the NAT table, whereas on 123 you do "ping 254", but the answer is part of
>the established connection. The only NATting that will happen, happens on
>254 when it gets the echo query packet.
>
>Hope this helps!
>
>James F. Carter Voice 310 825 2897 FAX 310 206 6673
>UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
>Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
>
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NAT PREROUTING chain ignored on returning traffic ??
2003-08-29 18:57 NAT PREROUTING chain ignored on returning traffic ?? Zoilo
2003-08-31 5:31 ` Jim Carter
@ 2003-09-01 7:46 ` Philip Craig
1 sibling, 0 replies; 4+ messages in thread
From: Philip Craig @ 2003-09-01 7:46 UTC (permalink / raw)
To: Zoilo; +Cc: netfilter
Zoilo wrote:
> 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?
The nat table is used to set up the nat mappings for a connection.
Since the nat mappings do not change throughout the life of the
connection, this is only done for the first packet in the connection.
Therefore, the nat table will only see packets that have a state
of NEW or RELATED.
For further evidence of this, notice that the outgoing packet in II)
goes through the nat OUTPUT and POSTROUTING chains, but the outgoing
packet in I) does not.
--
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-09-01 13:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-08-29 18:57 NAT PREROUTING chain ignored on returning traffic ?? Zoilo
2003-08-31 5:31 ` Jim Carter
2003-09-01 13:58 ` Zoilo
2003-09-01 7:46 ` Philip Craig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox