All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hinko Kocevar <hinko.kocevar@cetrtapot.si>
To: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Cc: netfilter@vger.kernel.org
Subject: Re: icmp forward
Date: Fri, 30 Jan 2009 12:24:19 +0100	[thread overview]
Message-ID: <4982E363.6070005@cetrtapot.si> (raw)
In-Reply-To: <4982DC10.6020903@plouf.fr.eu.org>

Pascal Hambourg wrote:
> Hello,
> 
> Hinko Kocevar a écrit :
>> Christoph Paasch wrote:
>>>
>>> On Fri January 30 2009, Hinko Kocevar wrote:
>>>>
>>>> Is it possible to 'port forward' ICMP requests?
>>>
>>> You can match the protocol on ICMP packets with -p icmp and let the
>>> port-
>>> specific stuff out of it, as ICMP doesn't uses portnumbers. But the
>>> problem will be, that your external machine won't be reachable for
>>> icmp packets. (as every icmp packets will get forwarded) It may be
>>> ennoying if MTU or ping packets doesn't reach anymore your machine.
>>> That depends on the usage of your gateway.
>>
>> Yes, that is what I was afraid of. I think that gateway should still
>> remain
>> available for ICMP echo-reply from external network.
> 
> You must not be afraid of redirecting incoming ICMP replies or error
> messages originally destined to the gateway to the mobile device. These
> messages have the state ESTABLISHED or RELATED, while NAT rules see only
> packets creating a new "connection", which have the state NEW. Even
> though, you could have your DNAT rule match only the echo-request type
> with the --icmp-type option. However, if you redirect ICMP echo request
> to the device, indeed you cannot ping the gateway any more on the same
> external address. You need a separate address.

Not quite sure what it is all about, but is it doing something like:
# ifconfig eth0:1 172.31.64.121 netmask 255.255.254.0 up

And later..
# iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT
# iptables -t nat -A PREROUTING -i eth0 -p icmp -j DNAT --to-destination 10.1.1.2


.. looking at the ping replies on both external gateway IPs the results seem
to indicate that ICMP on both IPs is reaching mobile device, instead of gateway
on interface eth0:1 (172.31.64.121):
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:F9:12:33:33  
          inet addr:172.31.64.126  Bcast:172.31.65.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:20407 errors:0 dropped:0 overruns:35 frame:0
          TX packets:5630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1991148 (1.8 MiB)  TX bytes:554003 (541.0 KiB)
          Interrupt:17 DMA chan:1 

# ifconfig eth0:1
eth0:1    Link encap:Ethernet  HWaddr 00:16:F9:12:33:33  
          inet addr:172.31.64.121  Bcast:172.31.65.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:17 DMA chan:1 

pinging both IP addresses from another LAN host produces:

64 bytes from 172.31.64.121: icmp_seq=54 ttl=64 time=1.24 ms
64 bytes from 172.31.64.121: icmp_seq=55 ttl=64 time=1.38 ms
64 bytes from 172.31.64.121: icmp_seq=56 ttl=64 time=1.29 ms
64 bytes from 172.31.64.121: icmp_seq=57 ttl=64 time=1.27 ms
^^^ here iptables rule for ICMP kick in ^^^
64 bytes from 172.31.64.121: icmp_seq=58 ttl=127 time=51.8 ms
64 bytes from 172.31.64.121: icmp_seq=59 ttl=127 time=21.4 ms
64 bytes from 172.31.64.121: icmp_seq=60 ttl=127 time=50.5 ms
64 bytes from 172.31.64.121: icmp_seq=61 ttl=127 time=20.6 ms

64 bytes from 172.31.64.126: icmp_seq=5318 ttl=64 time=1.30 ms
64 bytes from 172.31.64.126: icmp_seq=5319 ttl=64 time=1.35 ms
64 bytes from 172.31.64.126: icmp_seq=5320 ttl=64 time=1.30 ms
64 bytes from 172.31.64.126: icmp_seq=5321 ttl=64 time=1.41 ms
64 bytes from 172.31.64.126: icmp_seq=5322 ttl=64 time=1.31 ms
^^^ here iptables rule for ICMP kick in ^^^
64 bytes from 172.31.64.126: icmp_seq=5323 ttl=127 time=37.2 ms
64 bytes from 172.31.64.126: icmp_seq=5324 ttl=127 time=63.4 ms
64 bytes from 172.31.64.126: icmp_seq=5325 ttl=127 time=28.7 ms
64 bytes from 172.31.64.126: icmp_seq=5326 ttl=127 time=61.4 ms
64 bytes from 172.31.64.126: icmp_seq=5327 ttl=127 time=35.0 ms

This is not what I expected - shouldn't the request destined for eth0:1 be
answered by the gateway device?

Thank you,
Hinko

-- 
Hinko Kočevar, OSS developer
ČETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel     ++386 (0) 4 280 66 03
e-mail  hinko.kocevar@cetrtapot.si
http    www.cetrtapot.si


  reply	other threads:[~2009-01-30 11:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30  8:18 icmp forward Hinko Kocevar
2009-01-30  8:33 ` Michele Petrazzo - Unipex srl
2009-01-30  8:53   ` Payam Chychi
2009-01-30  9:19   ` Hinko Kocevar
2009-01-30  8:49 ` Christoph Paasch
2009-01-30  9:12   ` Hinko Kocevar
2009-01-30 10:53     ` Pascal Hambourg
2009-01-30 11:24       ` Hinko Kocevar [this message]
2009-01-30 11:35         ` Hinko Kocevar
2009-01-30 11:42           ` Pascal Hambourg
2009-01-30 11:36         ` Mart Frauenlob
2009-01-30  9:20 ` Mart Frauenlob
2009-01-30 11:36   ` Hinko Kocevar

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=4982E363.6070005@cetrtapot.si \
    --to=hinko.kocevar@cetrtapot.si \
    --cc=netfilter@vger.kernel.org \
    --cc=pascal.mail@plouf.fr.eu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.