Showing results for 
Search instead for 
Did you mean: 


source ip address for icmp messages not what is expected

We have a router that has interfaces in multiple VRFs.  One interface sits on an interface that is routed on the Internet.  Other interface sits on a VRF that is in a private address space and is used for WAN connectivity.  The strange behavior that I'm seeing is related to icmp messages coming off the router.  It appears that scanners hitting the Internet-facing interface cause the router to generate icmp messages (type 3) that are source using the IP address of the WAN-facing interface and they are routed across the WAN, into our data center and dropped by our firewall due to anti-spoofing rules.  Is this normal behavior?  Doesn't seem normal to me. Is this behavior something that can be changed via configuration?

Everyone's tags (1)
Cisco Employee

Hey David,First thing I would

Hey David,

First thing I would be interested in is, do you have any configuration on this device; may be IP SLA or something like that, which is testing the reachability of other link because I have not see anything like that unless configured.




Can you confirm ... your

Can you confirm ... your Internet-facing interface and your WAN-facing interface ... are they in different VRFs?  If so, what connects them - is it some kind of firewall?

My first reaction would be that if the ICMP is being sourced from the WAN-facing interface, then that is where the scanners are hitting.  (Actually, they may be hitting the Internet-facing, but are then finding their way onto your internal network and then reflected back to the WAN-facing.)

If your WAN-facing VRF has a default route towards data centre, then anything that hits it that will provoke an ICMP-3 towards your  data centre.

The question is, how did these packets get from the Internet to the WAN-facing interface?  It sounds like you have a routing loop for certain addresses between your Internet VRF and your data centre.

Kevin Dorrell



Frequent Contributor

you need inbound access-list

probabaly some body attacking you

you need inbound access-list in Internet-facing interface.

and you need to filtr private source addresses classes  A, B, C 


ip access-list extended InWorld
 deny   ip any
 deny   ip any
 deny   ip any
 permit ip any any

interface FastEthernet0
Internet-facing interface
 ip address
 ip access-group InWorld in


later you will see hit counts

sh access-lis



here is detailed explanation

they using more complicated acces-list

In a typical IP address spoofing attempt, the attacker fakes the source of packets in order to appear as part of an internal network. David Davis tells you three ways you can make an attacker's life more difficult—and prevent IP address spoofing. 
As you know, the Internet is rife with security threats, and one such threat is IP address spoofing. During a typical IP address spoofing attempt, the attacker simply fakes the source of packets in order to appear as part of an internal network. Let's discuss three ways you can protect your organization from this type of attack.

Block IP addresses
The first step in preventing spoofing is blocking IP addresses that pose a risk. While there can be a reason that an attacker might spoof any IP address, the most commonly spoofed IP addresses are private IP addresses (RFC 1918) and other types of shared/special IP addresses.

Here's a list of IP addresses—and their subnet masks—that I would block from coming into my network from the Internet:
All of the above are either private IP addresses that aren't routable on the Internet or used for other purposes and shouldn't be on the Internet at all. If traffic comes in with one of these IP addresses from the Internet, it must be fraudulent traffic.

In addition, other commonly spoofed IP addresses are whatever internal IP addresses your organization uses. If you're using all private IP addresses, your range should already fall into those listed above. However, if you're using your own range of public IP addresses, you need to add them to the list.

Implement ACLs
The easiest way to prevent spoofing is using an ingress filter on all Internet traffic. The filter drops any traffic with a source falling into the range of one of the IP networks listed above. In other words, create an access control list (ACL) to drop all inbound traffic with a source IP in the ranges above.

Here's a configuration example:

Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip access-list ext ingress-antispoof
Router(config-ext-nacl)# deny ip any
Router(config-ext-nacl)# deny ip any 
Router(config-ext-nacl)# deny ip any 
Router(config-ext-nacl)# deny ip any
Router(config-ext-nacl)# deny ip any
Router(config-ext-nacl)# deny ip any     
Router(config-ext-nacl)# permit ip any any     
Router(config-ext-nacl)# exit

Router(config)#int s0/0
Router(config-if)#ip access-group ingress-antispoof in
Internet service providers (ISPs) must use filtering like this on their networks, as defined in RFC 2267. Notice how this ACL includes permit ip any any at the end. In the "real world," you would probably have a stateful firewall inside this router that protects your internal LAN.

Of course, you could take this to the extreme and filter all inbound traffic from other subnets in your internal network to make sure that someone isn't on one subnet and spoofing traffic to another network. You could also implement egress ACLs to prevent users on your network from spoofing IP addresses from other networks. Keep in mind that this should be just one part of your overall network security strategy.

Use reverse path forwarding (ip verify)
Another way to protect your network from IP address spoofing is reverse path forwarding (RPF)—or ip verify. In the Cisco IOS, the commands for reverse path forwarding begin with ip verify.

RPF works much like part of an anti-spam solution. That part receives inbound e-mail messages, takes the source e-mail address, and performs a recipient lookup on the sending server to determine if the sender really exists on the server the message came from. If the sender doesn't exist, the server drops the e-mail message because there's no way to reply to the message—and it's very likely spam.

RPF does something similar with packets. It takes the source IP address of a packet received from the Internet and looks up to see if the router has a route in its routing table to reply to that packet. If there's no route in the routing table for a response to return to the source IP, then someone likely spoofed the packet, and the router drops the packet.

Here's how to configure RPF on your router:

Router(config)# ip cef
Router(config)# int serial0/0
Router(config-if)# ip verify unicast reverse-path
Note that this won't work on a multi-homed network.

It's important to protect your private network from attackers on the Internet. These three methods can go a long way toward protecting against IP address spoofing. For more information on IP address spoofing, read "IP Address Spoofing: An Introduction."

Is IP address spoofing a major concern for your organization? What steps have you taken to protect the company? Have you used RPF? Share your experiences in this article's discussion.




and dont forget to rate post