Hello sales2161
Hmm, that’s interesting, not sure why that is happening. As Rene states in his lesson, it is possible to have an access-list added that will specify exemptions to the uRPF rule. It is these exceptions that the suppressed verification drops should count. Cisco’s documentation states that as well. I’ll ask Rene to take a look and see if he has any more insight.
Thanks!
Laz
Just to be sure, I just did this lab again.
The Cisco documentation states:
The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL. Using the drop count and suppressed drop count statistics, a network administrator can takes steps to isolate the attack at a specific interface.
Which leads to belief an ACL is required to see suppressed drops. However in loose mode, when there is no matching route, the packets are counted towards the suppressed drops. I can’t find anything in the documentation about this but that’s what happens 
Rene
Hello Rene & Lagapides. I just read your lesson on uRPF. I came across this question and i needed some help in understanding the answer that was chosen.
Based on the access list, once traffic from the 7.7.7.0/24 network gets to the router, uRPF is going to check the routing table against that network and forward the traffic if it finds a match. Since that network is allowed, how is that bypassing uRPF checks for that network. Even if that network is not in the routing table, you will still get verification drops.
Maybe i am not understanding the question. Help please.
Thanks,
Doogle
Hello Cecil
When the ip verify unicast reverse-path command is used, the feature checks to determine whether any packet received at the router interface arrives on one of the best return paths to the source of the packet. It checks this be examining the source IP address, comparing it to the routing table, and making sure that the interface it came in on matches with the interface associated with the source address in the routing table. If this is the case, the packet will be accepted and routed correctly. In such a case, the access list created in the above configuration actually does nothing.
However, if the source IP address fails this check, that is, if the source IP should not be seen on the interface the packet came in on, it will be dropped unless there is an ACL specified in the command. If there is, and the source IP address matches that in the ACL permit statement, then the check is bypassed. What this means is that the packet is successfully routed.
Note however, that regardless of whether the packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for uRPF drops, and in the interface statistics for uRPF.
I hope this has been helpful!
Laz
Thanks for your answer lagapides. I just dont see why this was the best answer to the question.
Hi Cecil
Looking at the two possible answers in your previous post, the first defines an access list and permits the 7.7.7.0/24 subnet. Then in the interface configuration, the command ip verify unicast reverse-path is issued. This configuration simply enables uRPF on that interface, and all traffic will go through the uRPF checks, including the 7.7.7.0/24 subnet. If 7.7.7.0/24 fails the check, it too will be dropped. This is because the access list that was created is not actually applied anywhere. ACL 150 has simply been defined, but not applied.
In the second case, the command includes the application of the ACL like so: ip verify unicast reverse-path list 150. This means that all the uRPF checks will still be applied except for any exception referenced in the ACL. In this case, the 7.7.7.0/24 subnet will still be forwarded even if it fails the uRPF checks, simply because ACL 150 has been applied to the reverse-path command.
I hope this has been helpful!
Laz
Hi Laz,
You said that the uRPF checks will still be applied except for any refererence in the ACL. But if the subnet is still forwarded even if it fails the uRPF checks, wont you see suppressed verification drops when you run the command, show ip interface Gig 0/0 | include drops?
Thanks,
Cecil
Hello Cecil
Yes, you will see those as drops. As Cisco’s documentation states:
Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
Let me rephrase the statement like so. uRPF checks will always take place. However, if there is a reference in a configured ACL, then even if a check fails, if it matches the permit statement in that ACL, the packet is forwarded, but a drop is recorded.
I hope this has been helpful!
Laz
Hell Laz,
Thanks for replying, I understand the point you made, but going back to the original question for a second, "you need to bypass uRPF checks for the 7.7.7.0/24 network", if you are recording packets, weather they are dropped of being forwarded, to me that means you are not bypassing uRPF checks. How is that accomplished? Maybe I am not understanding the question. I did lab the lesson and i saw the drops and the supressed verification drops that was demonstrated.
Thanks for your patience with this.
Cecil
Hi Cecil
I agree that the question is not a very fair one. It should be rephrased to more correctly reflect the functionality of the ACL option for uRPF. Is this a question from the practice tests found on Networklessons? I tried to search for it originally, but was unable to find it. If so, please let me know so I can make the appropriate changes.
Thanks for pointing this out, it’s much appreciated!
Laz
Good morning Laz,
Thanks for the update. I saw this on another source that i use for studying.
Thanks again,
Cecil
Hi,
If i have core router where there are three ISP uplinks and on soutbound/downlink have multiple CE devices (prefixes) then
a. should i just enable urpf loose mode on uplink and downlink both without fail filter (any specific IPs)
or
b. should i configure urpf loose mode on uplink without fail filter and on individual L3-VLAN interface of all CE devices (downlinks) with fail-filter with their individual source IPs?
or
c. should i configure urpf strict or loose mode only on individual L3-VLAN interfaces of all CE devices with or without fail filter with their individual source IPs?
Hello Mahesh
It all depends upon your topology and what you want to achieve. First of all, I’m not sure what you mean when you say “fail filter”, do you mean an access list filtering out specific IPs?
In any case, here are some guidelines that you should use to decide how you will configure such an edge topology.
First of all, it’s a good idea to apply filters (and any security feature) as close as possible to the ISP. In this case, these should be applied to the core router which is directly connected to the ISPs.
Secondly, uRPF is not applied in a particular direction, but it is applied to a particular interface. Thus, any unicast traffic received on that interface will go through the configured uRPF checks. In your topology then, on which interfaces should uRPF be applied? It depends upon where you perceive the threat. If you have a threat of IP address spoofing from the ISPs, then apply it to the internet-facing interfaces. If there is a threat of IP address spoofing from within your network, apply it to the internal-facing interfaces.
Thirdly, should you apply loose or strict mode? This depends upon your routing structure. Typically, strict mode should be used, since most routing scenarios, don’t involve you routing traffic out of the same interface it comes in. However, in the case of asymmetric routing, you may indeed route traffic out of the same interface it has come in.
I hope this has been helpful!
Laz
Hello, everyone!
Thank you Rene for this amazing explanation. There’s just one thing that I am wondering about.
Because the router doesn’t check the source IP address it is possible for attackers to spoof the source IP address and send packets that normally might have been dropped by the firewall or an access-list.
What really are the chances of someone connecting to our network and deciding to just… spoof their IP? 
Wouldn’t this mean that they would need to have access to our internal network somehow, be authenticated and also know the ACL/Firewall rules so they could bypass them?
Thank you in advance for your help.
David
Hello David
This is a well established technique of “getting around” simple security precautions such as ACLs. For example, if there is an ACL that filters traffic with a source address from subnet A, and I, a malicious attacker have my computer in subnet A, then I can craft a packet with a different source address, thus spoofing my source address to an address that is not filtered by that ACL. I can get past the ACL in this manner.
Now this does mean that I must learn something about the network I am attacking, and finding out what ACLs exist in a network is one of those things I must learn. But that is not too difficult, seeing as ICMP will send back very specific codes as to why packets were dropped, including being dropped due to an ACL.
It’s not that difficult to perform some reconnaissance in a network to determine its weaknesses in order to determine that spoofing the source address of a packet will successfully fool an ACL. You don’t actually have to see the ACLs, there are ways of remotely detecting and deciphering what you need to overcome them…
I hope this has been helpful!
Laz
It was very helpful, Laz!
I’ve one more question, though.
Loose mode is useful when you are connected to more than one ISP, and you use asymmetric routing
So uRPF can also be used by ISPs or the customers on the internet, correct? However, let’s say that we have an ISP or a customer that is running uRPF Loose Mode due to the reason Rene mentioned in the quote above.
What if someone spoofed their IP address so that it matches another customer’s IP? Loose mode only checks the FIB for a match and that’s all… So it would find a match in the FIB in and forward the packet on. Because of this, isn’t the Loose mode still susceptible to spoofing attacks?
David
Hello David
If you are using loose mode, then yes, you can spoof the source address to an address that you know is in the routing table of the router, thus allowing the packet to pass the test and be routed. However, you have to remember that such packets, by definition, are allowed. A router will not be able to distinguish between a legitimate packet with an acceptable source IP address and a malicious packet with an acceptable IP source address. But it will prevent the spoofing of all other possible IP addresses, and that is the purpose of this feature.
Remember, uRPF is a feature that helps to limit malicious traffic on an enterprise, not to eliminate it completely. Although uRPF is an effective tool for preventing IP spoofing and mitigating some types of DoS attacks, it is not a comprehensive security solution and should be used as part of a multi-layered security strategy that includes other measures such as firewalls, intrusion detection systems, and regular network monitoring and auditing.
I hope this has been helpful!
Laz