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.
Lest’s assume that HOSTX with IP address of 184.108.40.206 wants to connect to SSL-VPN on 220.127.116.11 which is a firewall external interface. We will also assume tht every one is allowed to reach SSL-VPN on 18.104.22.168. When HOSTX at 22.214.171.124 tried to connect to 126.96.36.199, 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 188.8.131.52 to 184.108.40.206 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 220.127.116.11
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
18.104.22.168 255.255.255.0 [110/2] via 192.168.1,1, 0:27:01, INSIDE
As we can see, 22.214.171.124 network is being routed through our INSIDE interface while the source address of 126.96.36.199 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
For this specific problem, a static route entry for 188.8.131.52 will be set VIA OUTSIDE, this would allow traffic to pass Reverse Path as it would expect traffic from 184.108.40.206 to originate from OUTSIDE as opposed to INSIDE.