Forwarding ICMP through a Cisco router

[bigmike82]

So I find myself having to forward ICMP through a Cisco router for monitoring purposes. Unfortunately, ICMP doesn't operate on a 'port', so the standard port natting won't work. For security and management, I can't NAT the IPs 1 to 1. I just need to forward ICMP requests from the public IP to the private.

I can't seem to find a way to do this.

Does anyone have any ideas?

[8 pack]

I think static nat with an access list allowing only ICMP requests (and any other desired traffic) would work and be secure enough.

[bigmike82]

That won't work because that external IP needs to map to about four other private IPs. I've two windows boxes setup that I need RD access to, a linux box that does monitoring, and SNMP/ICMP to the fourth IP, which is a router down the line.

[8 pack]

Is the Linux box monitoring the router that you want the ICMP requests forwarded to? If its local then you shouldn't need to forward the ICMP requests. I apologize if I am completely missing the mark here.

[PolishMike]

Sounds like your flux capacitor isn't configured correctly.

[bigmike82]

That linux box isn't doing the monitoring...yet. I'm using a box that's on my local network, outside that network, for monitoring right now. That's why I need to forward ICMP.

[fd15k]

If you're trying to monitor latency and/or reachability to more than 1 box behind the NAT, then I think your best option is to use some "hacking". Setup UDP port forwarding, say ports 1025 and 1026 (completely arbitrary ports) to boxes A and B, and send a UDP datagram to either of those ports with payload "Hello, world!" Because you got no service listening to those datagrams on boxes either box, those boxes will respond with ICMP unreach (destination port unreachable). So instead of having ICMP echo request -> echo reply, you will have UDP dg -> ICMP unreach

[6172crew]

Does your router have an access list already applied? Maybe your to restrictive and allowing the ping may have to be before the list that is denying your packet.

Of course I'm not the pro but if I was going to look somewhere thats where I would start. You can also download a packet tracer deal that you can upload your IOS and see what or where is stopping your traffic.

The file/tracer I have is called ISO 9660 which was had from a Cisco guy and is 69MB. The app is for testing your network before turning it up but it works..at least in the classroom.

[bigmike82]

Unfortunately, it's not that simple.

The router has *no* rule that covers where to forward the ICMP packet.

Here's how it's set up.

Public IP: 1.2.3.4
Private IPs: 10.0.0.100,101,102,103

1.2.3.4:80 is NATed to 10.0.0.100
1.2.3.4:22 is NATed to 10.0.0.101
1.2.3.4:3389 is NATed to 10.0.0.102

Note that the router can route traffic to 1.2.3.4, but *none* of the interfaces have that IP, and therefore ICMP times out. Which is fine, since I don't monitor the router on that IP anyway. I need to monitor 10.0.0.103 via ICMP, and I can only use 1.2.3.4. That's where the issue is.

[fd15k]

So if you're pinging 1.2.3.4 and getting timeouts (while there is no specific NAT rule for ICMP), it's probably just being dropped by the firewall.

[bigmike82]

Nope. The packets are being dropped, but not at the firewall. The router itself is dropping the packets, because it doesn't know where to send them.

[fd15k]

And when you telnet into 1.2.3.4, does it timeout too ? Unless there is a NAT rule for something, router is supposed to assume traffic as addressed to itself, and handle it.

[nick]

While I never had to deal with a situation like this, echo is TCP/UDP 7, so it might be possible to overload it.

Alternatively, you can just use telnet to some other port translated to some port on the system you monitor. Or you can have the monitored system ping your monitoring system instead, and have the monitoring system record this info. Or you can send SNMP traps to the monitoring system (well, not the best of ideas, since it'll obviously go through a public network).

Finally, you can establish a VPN to that router and ping through it.

Frankly, I'd figure out some other way to monitor that system than pinging with with some sort of NAT overloading. It's ***-backwards in so many ways.

[nick]

There, from the horse's mouth:

http://tools.ietf.org/html/rfc862

[DiscoBayJoe]

You will not be able to "ping" (using ICMP) 4 private devices with a single public IP address. No amount of router jockeying will allow you to break the rules (unless of course you are Chuck Norris).

Your choices:

1-to-1 NAT's

- OR -

Install a TCP based service probe on your monitoring box. That way you can test port 80, 3389, etc on each device and know not only is the box reachable but the service is up.

- OR -

Deploy a MSP-friendly management platform (Like Kaseya / LPI / N-Able), one that is designed to do service checks thru NAT. I use Kaseya. It reverses the connectivity logic..... We install a agent on each host and they check in every 30 seconds with the console. We can do a whole lot more than just checking availability of the machine/socket.