IT Knowledge Base

Technical Repository

HowTo: Cisco ASA – Troubleshooting Reverse Path Checks Failure (RFP)

Troubleshooting Reverse Path Failures

Unicast RPF or Reverse Path is defined in RFC 3704. This RFC stipulates that traffic from known invalid networks should not be accepted on interfaces from which they didn’t originate. The concept idea as seen in RFC 2827 which was to deny traffic on an interface if it is sourced from RFC 1918 private address.

The objective of Rerverse Path Checks or Reverse Route Lookup is to detect source IP spoofing. This functionality has been built into Firewalls whereby they detect if the packet with source address inbound on an interface is routable through that interface and if not then it results in Rerverse Path Failures.

Scenario
Lest’s assume that HOSTX with IP address of 25.25.25.10 wants to connect to SSL-VPN on 66.66.66.50 which is a firewall external interface. We will also assume tht every one is allowed to reach SSL-VPN on 66.66.66.50. When HOSTX at 25.25.25.10 tried to connect to 66.66.66.50, it was not able to connect. Firewall admin checked logs to see why HOSTX could not connect and noticed the following:

Deny TCP reverse path check from 25.25.25.10 to 66.66.66.50 on interface OUTSIDE

Since this is coming from Outside interface, routes were checked , and there is a default route present:

route OUTSIDE 0.0.0.0 0.0.0.0 66.66.66.1

This means that there is a default rout via outside interface, and traffic should be allowed to go back should there be no other matching routes.This, therefore, would not be cause of Reverse Path Errors as we have a default route. As discussed, Reverse Path is in place to ensure that source address is not spoofed. This prompted to check for more specific routes for source address and following was found:

show route INSIDE | include 25.25.25

25.25.25.0 255.255.255.0 [110/2] via 192.168.1,1, 0:27:01, INSIDE

As we can see, 25.25.25.0 network is being routed through our INSIDE interface while the source address of 25.25.25.10 is trying to come in from OUTSIDE. This results in Reverse Path Failure as Firewall tags it as a source spoofing as it expected packet to come in from INSIDE interface and not OUTSIDE

Solution
For this specific problem, a static route entry for 25.25.25.10 will be set VIA OUTSIDE, this would allow traffic to pass Reverse Path as it would expect traffic from 25.25.25.10 to originate from OUTSIDE as opposed to INSIDE.



Leave a Reply