On 2012-10-12 09:13, Vigneswaran R wrote:
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
Yes, they are not related to existing and it is not new connection, but
there is similar issues related to TCP, and it is handled differently.
For example if nf_conntrack_tcp_loose is set to 0 - it will not pickup
already established connections, and just they will have INVALID state.
If set to 1 (and it is default value) - it will pickup the connection,
even it is established state. I was expecting ICMP and especially RST
can be consistent with that.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
