From: Vigneswaran R <vignesh@atc.tcs.com>
To: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
netdev@vger.kernel.org, netfilter@vger.kernel.org
Subject: Re: conntrack, NAT and icmp echo reply
Date: Fri, 12 Oct 2012 10:43:43 +0530 [thread overview]
Message-ID: <5077A707.1030709@atc.tcs.com> (raw)
In-Reply-To: <10293136eb284457b47cbffd6c91d1ef@visp.net.lb>
On Thursday 11 October 2012 03:32 PM, Denys Fedoryshchenko wrote:
> On 2012-10-11 12:57, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:41 +0300, Denys Fedoryshchenko wrote:
>>> Hi all
>>>
>>> I have NAT box, with very simple rule
>>> iptables -t nat -I POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
>>> It can be SNAT also, and it works fine, as NAT.
>>>
>>> When i generate icmp _reply_ packet, to some host
>>> hping -I ppp0 -1 --icmptype 0 8.8.8.8
>>>
>>> It will pass the box, and will exit it without NAT, e.g. with original
>>> IP 10.x.x.x
>>> on outgoing interface, which is not expected behavior IMHO.
>>> Is it a bug or feature?
>>>
>>
>> It depends, -s 10.0.0.0/8 wont match the rule if the source address
>> should be 198.23.44.55 I guess ?
>>
>> I would try the more obvious
>>
>> iptables -t nat -I POSTROUTING -o device -j MASQUERADE
> Source is correct, it is 10.0.0.0/8 range. I tested also ICMP code 3,
> it wont be NATed also.
> But ICMP echo passing OK.
> Also TCP RST generated same way, (i guess that don't have any match in
> conntrack table), won't be NATed too.
> hping -I ppp0 -R 8.8.8.8
> 13:01:07.074134 IP 10.0.0.142.2106 > 8.8.8.8.0: Flags [R], seq
> 510333079, win 512, length 0
> 13:01:08.074239 IP 10.0.0.142.2107 > 8.8.8.8.0: Flags [R], seq
> 1169580528, win 512, length 0
> 13:01:09.074253 IP 10.0.0.142.2108 > 8.8.8.8.0: Flags [R], seq
> 186548661, win 512, length 0
> 13:01:10.074376 IP 10.0.0.142.2109 > 8.8.8.8.0: Flags [R], seq
> 2135508128, win 512, length 0
> 13:01:11.074553 IP 10.0.0.142.2110 > 8.8.8.8.0: Flags [R], seq
> 1507433100, win 512, length 0
>
> And ICMP here you can see correct behavior with icmp echo request:
>
> 12:58:22.917458 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 0, length 8
> 12:58:23.917543 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 256, length 8
> 12:58:24.917657 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 512, length 8
> 12:58:31.047475 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:32.047562 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:33.047734 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:54.014601 IP X.146.153.X > 8.8.8.8: ICMP echo request, id 10462,
> seq 0, length 8
> 12:58:54.081897 IP 8.8.8.8 > X.146.153.X: ICMP echo reply, id 10462,
> seq 0, length 8
I think, the following may be the reason for the behaviour you observed.
(I may be wrong, I am not an expert in iptables.)
"nat" table only consulted for "NEW" connections. ref:
<http://inai.de/images/nf-packet-flow.svg>
The ICMP echo _reply_ may not be considered as part of a "NEW"
connection, as it must be a _reply_ to some already received _request_.
So _request_ is new and _reply_ is not.
Regards,
Vignesh
next prev parent reply other threads:[~2012-10-12 5:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 9:41 conntrack, NAT and icmp echo reply Denys Fedoryshchenko
2012-10-11 9:57 ` Eric Dumazet
2012-10-11 10:02 ` Denys Fedoryshchenko
2012-10-12 5:13 ` Vigneswaran R [this message]
2012-10-12 6:59 ` Denys Fedoryshchenko
2012-10-12 12:41 ` Jozsef Kadlecsik
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=5077A707.1030709@atc.tcs.com \
--to=vignesh@atc.tcs.com \
--cc=denys@visp.net.lb \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter@vger.kernel.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