Reverse Path Check Error

bretcollins · ‎08-09-2005

Every day we get at least two of the following syslog message.

Alert 10.x.x.x %PIX-1-106021: Deny udp reverse path check from 192.168.100.2(unresolved) to 207.46.130.100(time.windows.com) on interface inside

We are not using the 192.x.x.x address range at all. We have an active directory domain so our clients should be getting time from the domain controllers. Does anyone have any ideas how to track this down?

If the computer has an addres of 192.168.110.2 - I don't even understand how it is getting to our firewall. Any help or suggestions is appreciated. Thanks.

pkapoor · ‎08-23-2005

Looks like something is spoofing an IP of 192.168.100.2 and sending the time request. If I was you, I'd debug the inside interface or better, sniff the traffic coming to the PIX inside.

Then I'd grab the MAC off the packet and back-check it with the switching fabric to see which segment the packet is coming from.

Here's more:

106021

Error Message %PIX-1-106021: Deny protocol reverse path check from source_address to

dest_address on interface interface_name

Explanation Someone is attempting to spoof an IP address on an inbound connection. Unicast Reverse Path Forwarding (Unicast RPF), also known as reverse route lookup, detected a packet that does not have a source address represented by a route and assumes that it is part of an attack on your firewall.

Recommended Action This message appears when you have enabled Unicast Reverse Path Forwarding with the ip verify reverse-path command. This feature works on packets input to an interface; if it is configured on the outside, then the firewall checks packets arriving from the outside.

The firewall looks up a route based on the source_address. If an entry is not found and a route is not defined, then this syslog message appears and the connection is dropped.

If there is a route, the firewall checks which interface it corresponds to. If the packet arrived on another interface, it is either a spoof or there is an asymmetric routing environment that has more than one path to a destination. The firewall does not support asymmetric routing.

If configured on an internal interface, the firewall checks static route command statements or RIP and if the source_address is not found, then an internal user is spoofing their address.

An attack is in progress. With this feature enabled, no user action is required. The firewall repels the attack.

bretcollins · ‎08-24-2005

I put a sniffer on the inside interface but the mac address belongs to one of our layer 3 routing modules. I am trying to figure out the best way to sniff the traffic on the module. We have several VLANs and redundancy which is complicating the process. Thanks.

pkapoor · ‎08-24-2005

If the MAC is that of a routing module, then it is proxy-arping for something that routes through it or lies behind it. To find out where the packet is coming from, you could do the following.

Put an ACL on each interface that first denies all IP from 192.168.100.2 to any. At the end of this ACE, do not forget to put the "log" argument. This will send anything that hits this ACL (any IP traffic from 192.168.100.2) to the syslogs (assuming that you are syslogging that routing module). Also, do not forget to put a second ACE in the access list that permits all IP (so that other legitimate traffic is not blocked).

Depending on which interface you're getting the hits for the deny on 192.168.100.2, you will pick a trail ("back-trailing" as I like to call it). Then you work your way downstream.

dopenfield · ‎08-26-2005

We started seeing this same issue yesterday and even more today. Something spewing so bad the syslogs went HUGE and crashed the syslog server.

We've suppressed the message from being logged for now after getting 4Mb worth of just this message in 10 minutes when we re-started the syslog server.

Our problem is that the message is showing the Source as being Loopback address 127.0.0.1.

Looking for any other suggestions on how to track down the MAC associated with that loopback address. I've opened a TAC case looking for Cisco input.

mostiguy · ‎08-26-2005

do you have managed switches? they should be able to show your the mac address/ switch port table

dopenfield · ‎08-26-2005

That is what we are attempting.

Looking for the most efficient way to identify the actual source or sources.

We are a University and the students started moving back in yesterday. We are hoping it is one of their devices, but which one or ones?

dwalsh · ‎09-01-2005

The way I ususally do this is to do an ARP lookup for the IP address to match it with a MAC address. When I get that, I do a CAM lookup at the core switch. This tells me what trunk it sees it on. I then just follow it out until I get to the edge switch and eventually I know the physical port.

Seems to work well in my environment.

Regards,

Dave