PDA

View Full Version : Forwarding ICMP through a Cisco router


bigmike82
01-30-2010, 6:37 PM
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
01-30-2010, 7:07 PM
I think static nat with an access list allowing only ICMP requests (and any other desired traffic) would work and be secure enough.

bigmike82
01-30-2010, 7:18 PM
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
01-30-2010, 9:31 PM
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
01-30-2010, 9:33 PM
Sounds like your flux capacitor isn't configured correctly.

bigmike82
01-30-2010, 10:12 PM
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
01-30-2010, 10:27 PM
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 :D

6172crew
02-01-2010, 6:00 PM
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
02-01-2010, 9:06 PM
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
02-01-2010, 9:26 PM
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
02-01-2010, 9:30 PM
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
02-01-2010, 9:35 PM
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
02-01-2010, 9:48 PM
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
02-01-2010, 9:50 PM
There, from the horse's mouth:

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

DiscoBayJoe
02-01-2010, 9:52 PM
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.

nick
02-01-2010, 9:55 PM
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).


Sounds like a challenge! Now I just have to try it! Lab, here I come (well, I'm sitting in it, in a manner of speaking).

ETA: I believe, he's trying to ping one of the devices, the one without a NATed service, not all 4 of them, for he has the services he can connect to on the other three.

DiscoBayJoe
02-01-2010, 10:05 PM
Sounds like a challenge! Now I just have to try it! Lab, here I come (well, I'm sitting in it, in a manner of speaking).

ETA: I believe, he's trying to ping one of the devices, the one without a NATed service, not all 4 of them, for he has the services he can connect to on the other three.

Oh! He only needs to ping one device.

That's not too hard.

ip nat inside source static tcp 10.0.0.100 80 1.2.3.4 80
ip nat inside source static tcp 10.0.0.101 22 1.2.3.4 22
ip nat inside source static tcp 10.0.0.102 3389 1.2.3.4 3389
ip nat inside source static 10.0.0.103 1.2.3.4

Just make sure you have a good external ACL, because all ports/protocols other than 80/22/3389 will be NAT'd to .103, including ICMP

You might be able to accomplish the same thing using the 'ip nat inside source list' command with an ACL that permits ICMP to the .103 and then the services needed to the other hosts. Either way, your only going to get "ping" to work against one of the hosts, not all 4.

nick
02-01-2010, 10:30 PM
Wouldn't work, one of the conditions states that he can't do a 1-to-1 NAT (test mode).

DiscoBayJoe
02-01-2010, 10:49 PM
Wouldn't work, one of the conditions states that he can't do a 1-to-1 NAT (test mode).

Even Mr. T couldn't work under those requirements! I can understand no 1-to-1 NAT because you don't have 4 public IP's, but not because you don't trust the interface ACL.

Your problem is at layer 8 of the OSI model.

nick
02-01-2010, 11:09 PM
Would that be the fleshy layer?

bigmike82
02-01-2010, 11:27 PM
"Unless there is a NAT rule for something, router is supposed to assume traffic as addressed to itself, and handle it."
Uhm...not in my experience with Cisco routers.

"It's ***-backwards in so many ways. "
It's not backwards at all. Ping is one of the ways I'm monitoring it, but that's what Zenoss wants in order to determine if it's up, so that's what Zenoss is going to get. The entire point of static NATing is to allow this kind of functionality with the amount of IPs as a constraint.

You did just jog my memory. I'm used to working on Windows machines, so ping for me means ICMP. I completely forgot that 'nix uses TCP/UDP...so forwarding port 7 should, in fact, work. That's my next step. Thank you. :)

"You might be able to accomplish the same thing using the 'ip nat inside source list' command with an ACL that permits ICMP to the .103"
This won't work. IP Nat doesn't allow ICMP as a protocol.

"Either way, your only going to get "ping" to work against one of the hosts, not all 4. "
That's fine, and is exactly what I want. Hmm....I wasn't aware that I could nat ports, and then the entire IP, and have those two work. I'll have to give that a shot as well.

I think the port 7 thing is going to be the final config. Thanks again for reminding me of that.

bigmike82
02-03-2010, 8:48 AM
Damn it, I'm an idiot.

PING doesn't run on TCP. There's no option that I've seen, even in Linux, to ping using port 7. Ping is always ICMP. Tracert uses either ICMP or TCP, depending on the implementation.

Damn it.