ip verify reverse-path clarification

[raza555]

Hi,

I am auditing the network and bit worried to configure the “ip verify reverse-path interface outside & ip verify reverse-path interface inside”, so thought to take further advice from experts.

My understanding of RPF is that suppose for incoming packet, if the packet is not part of the existing connection then RPF will check the source IP Address of the packet and consult routing table to find if the network to which the source IP address belongs is reachable or not, if that packet is reachable then packet will be allowed, otherwise it will be dropped.

Questions:

1) As RPF is heavily depends on routing table, in below sample routing table if we apply the “ip verify reverse-path interface outside” as per below routing table everything is allowed on OUTSIDE interface, so it’s not worth applying it.

   If we apply it to the INSIDE then only the subnets with subnets 10.30.0.0, 10.40.0.0 will be allowed, so it worth applying the command “ip verify reverse-path interface inside”

2) Suppose if the spoofed IP Address 10.40.0.10 igress on OUTSIDE interface to egress on INSIDE network, as per below routing how the RPF will recognize that it’s a spoofed IP Address and drop it. I think that packet will pass the RPF checks.

3) RPF will only drop the packet on particular interface, if the source IP Address is not expected from the interface as per routing table. BUT if the packet is not in routing table, it will be dropped anyway, so what’s the purpose of RPF.

route outside 0.0.0.0 0.0.0.0 10.10.10.1 1

route inside 10.30.0.0 255.255.0.0 10.10.20.1 1

route inside 10.40.0.0 255.255.0.0 10.10.20.1 1

route outside 10.180.10.0 255.255.255.192 10.10.10.1 1

route outside 10.183.20.48 255.255.255.224 10.10.10.1 1

Thanks

[Jouni Forss · Accepted solution]

Hi,

Let me start by saying that I have not used this command that often as I have usually configure ACL rules so that I have clearly specified the source addresses/networks for even the destination "any" rules. So something that is not supposed to enter from a specific interface will be handled by the interface ACL.

With regards to your first question it would seem to me that the benefit for applying this to the "outside" interface is that the ASA would make sure that it doesnt allow any traffic from behind "outside" interface from the source addresses that would be actually located behind your different local interfaces. (inside in this case) Though I would imagine that this is not something that you would be seeing. Also if you for some reason had an overlapping network for VPN Client use then to my understanding as soon as you connect with the VPN Client the ASA will add a host route for this VPN Client user to its routing table so I would imagine this would satisfy the requirements of the RPF.

With regards to the second question I think the situation is as described above. The ASA would see the source address 10.40.0.10 having a route towards "inside" interface and would therefore drop the traffic incoming from "outside" with that source IP address.

With regards to your third question it seems to me that the ASA does not drop connections that are coming from an unknown source IP address (without RPF) from your LAN for example. Though I think there are certain source address that are blocked even if RPF isnt configured. I think atleast using source address that belong to a directly connected ASA interface from behind another ASA interface will always be dropped.

Just as an example I configure loopback999 interface on my home LAN router with IP address 2.2.2.2 and initiated ICMP to the external network and passes from the firewall just fine (Since I have permitted all traffic )

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 2.2.2.2

.....

Success rate is 0 percent (0/5)

ASA# sh conn | inc ICMP

ICMP LAN 2.2.2.2:121 WAN 8.8.8.8:0, idle 0:00:01, bytes 144

Enabling the RPF on the LAN interface and trying the ICMP again will result in the following message on the ASA

Feb 10 2014 13:40:20 ASA : %ASA-1-106021: Deny ICMP reverse path check from 2.2.2.2 to 8.8.8.8 on interface LAN

Feb 10 2014 13:40:22 ASA : %ASA-1-106021: Deny ICMP reverse path check from 2.2.2.2 to 8.8.8.8 on interface LAN

So as I said, I have not really configured this much as I have set production environments to stricly allow only the required source networks.

Have you read the Cisco ASA documentation about this setting?

Heres link to the Command Reference section of this command

http://www.cisco.com/en/US/docs/security/asa/command-reference/i3.html#wp1915749

Hope this helps

- Jouni

[Marius Gunnerud · Accepted solution]

1) As RPF is heavily depends on routing table, in below sample  routing table if we apply the “ip verify reverse-path interface outside”  as per below routing table everything is allowed on OUTSIDE interface,  so it’s not worth applying it.
   If we apply it to the INSIDE  then only the subnets with subnets 10.30.0.0, 10.40.0.0 will be allowed,  so it worth applying the command “ip verify reverse-path interface  inside”

In most cases you will have RPF configured on the outside interface.  What RPF does is check the source address of the packets and match that against the routing table.  In the routing table you should have a route (or be directly connected) to each available subnet on your inside network.  The ASA then will then check the packet against the routing table.

So lets say that there is a spoofed packet ingress on the outside interface with source IP 10.30.0.10.  Your ASA has a route to 10.30.0.10 through the inside interface.  Even if you have a default route, the more specific route will match and the ASA will see that 10.30.0.0.10 is not located on the outside interface, but instead located through the inside interface, and the packet will be dropped as a spoofed packet.

2) Suppose if the spoofed IP Address 10.40.0.10 igress on OUTSIDE  interface to egress on INSIDE network, as per below routing how the RPF  will recognize that it’s a spoofed IP Address and drop it. I think that  packet will pass the RPF checks.

So, now lets say that the 10.30.0.10 network is not located on the inside network, and you have RPF configured for the outside interface which in turn has a default route.  In this case you would rely on the iinterface ACL to drop this packet.  As you should be very restrictive as to what traffic you allow in.  By no means should you have a permit any any on the outside interface.

3) RPF will only drop the packet on particular interface, if the source  IP Address is not expected from the interface as per routing table. BUT  if the packet is not in routing table, it will be dropped anyway, so  what’s the purpose of RPF.

The purpose is that you (and the ASA) should know of all the subnets on the inside of your network.  and the ASA should have a route to each of those networks.  This way the ASA can decipher what is a spoofed packet and what is not.

--
Please remember to rate and select a correct answer

[raza555]

Thanks to both you, great explanation that has clarified me the topic and I am sure will help others as well.