* conntrack, NAT and icmp echo reply @ 2012-10-11 9:41 Denys Fedoryshchenko 2012-10-11 9:57 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: Denys Fedoryshchenko @ 2012-10-11 9:41 UTC (permalink / raw) To: netdev, netfilter 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? --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack, NAT and icmp echo reply 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 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2012-10-11 9:57 UTC (permalink / raw) To: Denys Fedoryshchenko; +Cc: netdev, netfilter 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack, NAT and icmp echo reply 2012-10-11 9:57 ` Eric Dumazet @ 2012-10-11 10:02 ` Denys Fedoryshchenko 2012-10-12 5:13 ` Vigneswaran R 0 siblings, 1 reply; 6+ messages in thread From: Denys Fedoryshchenko @ 2012-10-11 10:02 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev, netfilter 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 --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack, NAT and icmp echo reply 2012-10-11 10:02 ` Denys Fedoryshchenko @ 2012-10-12 5:13 ` Vigneswaran R 2012-10-12 6:59 ` Denys Fedoryshchenko 0 siblings, 1 reply; 6+ messages in thread From: Vigneswaran R @ 2012-10-12 5:13 UTC (permalink / raw) To: Denys Fedoryshchenko; +Cc: Eric Dumazet, netdev, netfilter 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack, NAT and icmp echo reply 2012-10-12 5:13 ` Vigneswaran R @ 2012-10-12 6:59 ` Denys Fedoryshchenko 2012-10-12 12:41 ` Jozsef Kadlecsik 0 siblings, 1 reply; 6+ messages in thread From: Denys Fedoryshchenko @ 2012-10-12 6:59 UTC (permalink / raw) To: Vigneswaran R; +Cc: Eric Dumazet, netdev, netfilter 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack, NAT and icmp echo reply 2012-10-12 6:59 ` Denys Fedoryshchenko @ 2012-10-12 12:41 ` Jozsef Kadlecsik 0 siblings, 0 replies; 6+ messages in thread From: Jozsef Kadlecsik @ 2012-10-12 12:41 UTC (permalink / raw) To: Denys Fedoryshchenko; +Cc: Vigneswaran R, Eric Dumazet, netdev, netfilter On Fri, 12 Oct 2012, Denys Fedoryshchenko wrote: > 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: > > > > > > > > > > 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. > > > 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. TCP is a connection-oriented procol while ICMP isn't. There is no point in creating a connection entry from a bogus-looking ICMP reply packet. The packets you generated neither belong nor related to an existing connection, thus are marked as INVALID. INVALID packets are not NAT-ed and if not dropped explicitely, will be sent out without natted. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-12 12:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2012-10-12 6:59 ` Denys Fedoryshchenko 2012-10-12 12:41 ` Jozsef Kadlecsik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
