1. Home
  2. Cisco Systems
  3. set srcIP for ICMP replies, or for locally sourced connections?

set srcIP for ICMP replies, or for locally sourced connections?

I'd like to block traffic to my routers from outside my network; but still to allow my routers to traceroute/ping to hosts outside my network; and reply to traceroutes sourced outside the network.

Is there a way to force ICMP replies to come from a particular IP address? For example, something like "ip icmp source-interface loopback2", where the ICMP messages generated by my routers would come from a source IP that I can specify? That would help to hide interface IPs from casual miscreants.

Alternatively, I could try to block all packets entering my network with destination IPs of my internal links. But that would block replies from simple outbound pings and traceroutes from router CLI sessions. If there were a way to bind locally-sourced ping and traceroute to a particular source IP on each router, then that would also be helpful.

Perhaps blocking at the network edge is not productive, and I should be using Control Plane Policing for this? Router platform is mix of VXR and 3BXL.

Reply to
Phil Begriffenfeldt
Loading thread data ...

Attach an ACL to the WAN interface (direction "in") that specifies to which IP addresses (interfaces) you will permit ICMP.

The direction is specified by the keyword "in", in the following example:

ip access-group in

For security reasons, you should actually specify the "types" of ICMP you wish to permit (e.g.: echo-reply, time-exceeded, unreachable, administratively-prohibited, packet-too-big, source-quench, parameter-problem). Some types of ICMP should definitely be denied.

Other info of interest:

Extended ping (via the CLI) permits you to specify the source IP address that will be used in the outbound ping, which then becomes the destination IP address in the reply packet.

"Inspection" applied on a LAN interface will open temporary dynamic holes in the return path ACLs to accommodate replies to pings sent from internal hosts.

Best Regards, News Reader

Phil Begriffenfeldt wrote:

Reply to
News Reader

Traceroute doesn't use ICMP, it sends udp packets on port 16667 (usually), increasing the TTL by one. The router that gets the packet with a TTL of 1 will reply with an ICMP TTL exceeded message.

Reply to
Thrill5

Beg to differ.

It's system dependent.

I just performed a traceroute from a Windows XP host through my IPSec+ GRE VPN, and captured it with Wireshark to confirm my beliefs.

A Windows XP (and probably other Windows paltforms) uses ICMP for traceroute.

Best Regards, News Reader

Thrill5 wrote:

Reply to
News Reader

He said he wants to "allow my routers to traceroute/ping to hosts". He didn't say anything about allowing Windows to TRACERT. So Windows's behavior is not relevant, only Cisco's.

Reply to
Barry Margolin

Yes, you are right.

However, he did also say "and reply to traceroutes sourced outside the network", which could be from Windows clients.

I addressed one of the two scenarios, as did other responders. ;>)

Next time I'll read his post more thoroughly.

Best Regards, News Reader

Barry Margol> >

Reply to
News Reader

To address the ICMP requirements for the return path of a traceroute or ping, see my other response.

If the traceroute is inbound from a Windows host, ICMP echo requests will be used to carry out the traceroute. See my other response.

If the traceroute is from another Cisco device, UDP will be used to carry out the traceroute (as indicated by another post responder).

When I captured a Cisco traceroute, I noticed that the initial UDP source and destination port numbers were random, and that they were incremented with each and every packet sent.

Accommodating inbound traceroute from an external Cisco device appears to require very permissive ACLs.

Don't know of a means to deviate from the default behavior.

Include layer 4 matching criteria in the ACEs (Accesses Control Entries) of your ACLs.

The extended mode of both ping and traceroute, permit you to define the source IP address.

Reply to
News Reader

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.