uRPF – lesson learned (again!)

I am a huge fan of securing user facing interfaces. With a few knobs some attacks and mis-configurations are avoided. I like configuring an SVI like this:

interface Vlan12
 description Users
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip verify unicast source reachable-via rx

ICMP Redirects

I like to disable sending ICMP redirects. This might cause a sub-optimal forwarding of packets, but I like the idea that my router which is the clients default gateway does the forwarding.

Proxy ARP

The IP Proxy ARP feature, when disabled, does not help clients with a mis-configured subnet mask. When enabled (the default), the router will respond to ARP requests if it has a route to the address the client is trying to resolve the MAC address to. The client would only try to ARP for something other than its local subnet, if the subnet mask is configured incorrectly, meaning that the client thinks the destination IP address is on the same subnet as itself.

Unicast Reverse Path Forwarding

uRPF is a nice security feature that prevents spoofing of IP addresses. When a packet is received on an interface where uRPF is configured, the router checks to see if the source IP is reachable out that same interface. If the check passes, meaning that we did have a route, the packet is allowed in and forwarded. If the check fails, meaning we did not have a route for the source out the interface on which the packet arrived, the packet is dropped and an interface counter is incremented. This is the function when configured in strict mode, which is the only way to configure uRPF to be secure. Other options exists, but these provide less secure checks (loose, allow-default, allow-self-ping, ACL).

Let’s say you like this feature so much, that you make it part of a template configuration. And let’s say you have a topology similar to this:

When R2 tries to reach R1’s 10.0.0.1, the packet is routed to ASA1. The ASA firewall has a route to 10.0.0.0/24 through R1 and forwards the packet to R1. Because R1 has uRPF configured in strict mode on its interface towards the ASA, the source IP of R2 is checked against the routing table. Since R1 does not have a specific route back to R2, the packet is dropped. This is the expected behaviour, but it is very easy to get caught by this nifty little security feature if you’re not careful when configuring infrastructure interfaces between your network devices. The uRPF feature can only safely be configured on stub interfaces.

And that is a lesson I (re-)learned today! Hopefully this was the last time I had to learn about the effects of uRPF.

You can see if packets are being dropped due to uRPF by looking a the IP interface:

R2# show ip interface Vlan12 | be verify
 IP verify source reachable-via RX
    12 verification drops
    0 suppressed verification drops
    0 verification drop-rate