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