Re: icmp forward

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hinko Kocevar wrote:
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

try:

iptables -t nat -A PREROUTING -i eth0 -d 172.31.64.121 -p icmp -j DNAT --to-destination 10.1.1.2


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

--
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

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux