Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

Lots of Deny UDP reverse path check errors...

Since setting up our new Cisco ASA I have noticed the following event in the ASDM logs very frequently:

Deny UDP reverse path check from 10.0.x.x to on interface outside

10.0.x.x is always an IP on the same subnet as the inside interface of the ASA, but the IP changes all the time. We have other subnets at remote locations that are behind the ASA (10.1.x.x, etc) but these never generate the event. Also, the part is sometimes

This doesn't appear to be causing any problems, it's just an annoyance. My only guess at this point is that it's related to my routing setup on the ASA, which is:

route outside x.x.x.x 1 (x.x.x.x is boundary router)

route inside 2 (internal router)

Does anyone have any ideas what is causing this, and what I need to change to make it stop?


Re: Lots of Deny UDP reverse path check errors...

Hi .. the events are generated because the ASA is protecting your network from Ip spoofing. PLease see the below explanations about this feature which I guess it must be enabled on your outside interface.

ip verify reverse-path

To enable Unicast RPF, use the ip verify reverse-path command in global configuration mode. To

disable this feature, use the no form of this command. Unicast RPF guards against IP spoofing (a packet

uses an incorrect source IP address to obscure its true source) by ensuring that all packets have a source

IP address that matches the correct source interface according to the routing table.

ip verify reverse-path interface interface_name

I hope it helps .. plase rate if it does

Community Member

Re: Lots of Deny UDP reverse path check errors...

Thanks Fernando. I know that's what is happening but due to the high frequency of the errors I thought I may have misconfigured something. I only see that error on 10.0.x.x addresses and only on the outside interface, but I don't see how a 10.0.x.x address could even be coming into that interface because it's not a valid IP. I thought what might be happening is that I had something misconfigured, so when valid addresses were coming in from my side the ASA could not verify them - not because the address is invalid, but because there is a problem with the reverse-path.

Again, I only see it with IP addresses on my local subnet (which is a school district office). I never see it on IP addresses from the remote school sites, which is what I would expect since that's where the students are.

CreatePlease to create content