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@xxxxxxxxxxxx
http www.cetrtapot.si
--
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
