Unicast Reverse Path Forwarding-Tutorial

Unicast Reverse Path Forwarding is a small security feature

 

When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.

Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.

We’ll use this simple topology to demonstrate URFP

R1 and R2 are connected through frame-relay and an Ethernet connection.

We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.

In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24) 

and 

R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

 

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

!
interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
…..
Success rate is 0 percent (0/5)

All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input

Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:

R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 … Open

Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
…..
Success rate is 0 percent (0/5)

Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.

Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input

We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/57/80 ms
R1#telnet 2.2.2.2 80 /source-interface loopback 0
Trying 2.2.2.2, 80 … Open

R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 …
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet

Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.