Policy-Based vs Route-Based VPNs: Part 2

This article is a continuation of our discussion regarding policy-based versus route-based VPNs. Make sure to read through part one before continuing if you haven't already. In this second part, we'll look at configuring a route-based VPN on IOS and then examine some important differences between the two approaches.

Step 1: Create a pre-shared key

Route-based VPNs don't rely on an explicit policy (access list) to match traffic, so we can skip that step and start by creating a pre-shared key. On R1, we can re-use the keyring we defined in part one and simply add a new key for R5. On R5, create a new keyring and key for R1. (Use the same key on both routers.)

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey
  pre-shared-key address 172.17.0.5 key AnotherSecretKey

R5

crypto keyring VPN
  pre-shared-key address 172.17.0.1 key AnotherSecretKey

Step 2: Create an ISAKMP policy

We can also re-use the ISAKMP policy we created on R1 in part one; just remember to apply it to R5.

R1 and R5

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

Step 3: Create an ISAKMP profile

This step should also look familiar. Create a new ISAKMP profile on both R1 and R5 to match the peer IP address to the pre-shared key keyring. (R1 will now have two ISAKMP profiles, R1_to_R3 and R1_to_R5.)

R1

crypto isakmp profile R1_to_R5
   keyring VPN
   match identity address 172.17.0.5 255.255.255.255 

R5

crypto isakmp profile R5_to_R1
   keyring VPN
   match identity address 172.17.0.1 255.255.255.255 

Step 4: Define an IPsec transform-set

We can also re-use the IPsec transform-set defined on R1. Be sure to define it on R5 as well.

R1 and R5

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

Step 5: Create an IPsec profile

At this point we start doing things a bit differently. We need to create an IPsec profile, which serves as a wrapper around one or more transform-sets and other parameters to be used in the construction of IPsec SAs. (For our purposes, we only need to reference a single transform-set, so it probably appears redundant.) Create the IPsec profile on both R1 and R5.

R1 and R5

crypto ipsec profile Routed_VPN
 set transform-set ESP-AES256-SHA1 

Step 6: Create a VPN tunnel interface

Now we get into the meat of the VPN configuration. We need to create a routed tunnel interface on both routers to act as the logical VPN edge. Tunnel interfaces serve to encapsulate/encrypt egressing traffic and decapsulate/decrypt ingressing traffic. (Here's a way to visualize this concept if it's a bit fuzzy.)

We'll use the 192.168.0.0/30 network for our VPN tunnel. The tunnel source and destination addresses are defined as the local and remote outside router IP addresses, respectively. The last two lines of the configs below apply IPsec to the tunnel interface using the IPsec profile we defined in the previous step.

R1

interface Tunnel0
 ip address 192.168.0.1 255.255.255.252
 tunnel source 172.17.0.1
 tunnel destination 172.17.0.5
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN

R5

interface Tunnel0
 ip address 192.168.0.2 255.255.255.252
 tunnel source 172.17.0.5
 tunnel destination 172.17.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN

Notice that, unlike our policy VPN configuration, the peer LAN (10.0.5.0/24) is not automatically injected by the VPN because there is no policy to tell the router what exists on the other side of the tunnel:

R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.0.3.0 [10/0] via 172.16.0.3
C       10.0.1.0 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0

Also unlike policy-based VPNs, the SAs for a route-based VPN are constructed automatically and maintained indefinitely whether or not traffic is passing across the VPN.

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.5      172.17.0.1      QM_IDLE           4004 ACTIVE
172.16.0.3      172.16.0.1      QM_IDLE           4003 ACTIVE

Step 7: Enable dynamic routing

As just mentioned, route-based VPNs have no mechanism to automatically discover the remote networks which are reachable over the VPN. So how do we communicate this information among peers? With a routing protocol, of course! Just about any routing protocol will do; we'll use single-area OSPF for this lab.

OSPF must be enabled for both the internal LAN interface (which in this case is actually just a loopback pretending to be a /24 network) and the tunnel interface. An OSPF adjacency should form between R1 and R5 over the 192.168.0.0/30 network, inside the VPN. There is no need to enable OSPF on the outside network (172.17.0.0/16), which we're pretending is publicly routed space outside of the VPN (e.g. the Internet).

R1 and R5

router ospf 1
!
interface Loopback1
 ip ospf 1 area 0
!
interface Tunnel0
 ip ospf 1 area 0

Testing

R1 and R5 should learn of each other's LAN prefixes via OSPF, and both networks should be immediately reachable via through the VPN tunnel:

R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.0.3.0/24 [10/0] via 172.16.0.3
C       10.0.1.0/24 is directly connected, Loopback1
O       10.0.5.1/32 [110/1001] via 192.168.0.2, 00:01:29, Tunnel0
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0
R1# ping 10.0.5.1 source 10.0.1.1

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

Pros and Cons

If you've been paying close attention throughout these last two articles, you'll have noticed a number of subtle but important differences between policy-based and route-based VPNs.

Policy-based VPNs require administrative policy maintenance

This is probably the biggest drawback of using policy-based VPNs as configured in part one. If we wanted to add a second internal network to R3, for example, we would have to manually update the policy ACL on both R1 and R3 to match traffic for the new network. This isn't a big deal if you're only ever going to manage a handful of networks, but the burden can quickly grow tiring when managing several dozen VPN sites.

Policy-based VPNs result in excessive IPsec SA creation

On the heels of the first observation, we realize that every ACL entry in a VPN policy results in a distinct pair of IPsec SAs (which we can examine in detail with the command show crypto ipsec sa). This isn't a problem if you can efficiently summarize routes, but results in substantial overhead if you have to define a number of distinct routes at either end of the VPN.

Some devices only support policy-based VPNs

I'm looking at you, ASAs. Some devices simply don't support tunnel interfaces or route-based VPNs, making the choice to adopt policy-based VPNs rather easy.

Route-based VPNs require a routed subnet

While route-based VPNs require only a single pair of IPsec SAs, they accomplish this because the VPN tunnel is constructed as an independently routed link (192.168.0.0/30 in our example). Rather than having to match all possible source and destination addresses in the private networks, a pair of IPSec SAs is built only to match traffic between the tunnel source and destination outside IPs. The trade-off, of course, is that we need to assign additional IP address space to the tunnel links.

Route-based VPNs are always on

The SAs for a route-based VPN are always maintained, so long as the corresponding tunnel interface is up. This is in contrast to a policy-based VPN, which forms SAs in response to detecting traffic which matches the policy (and will eventually tear down the SAs in the absence of such traffic). This can be seen as a benefit of policy-based VPNs if your VPN experiences infrequent traffic load, but personally I prefer to have my crypto tunnels up all the time to avoid IKE negotiation delay.

Route-based VPNs require a routing protocol

We saw in part one that reverse route injection can be used in a policy-based VPN to automatically inject static routes for destinations reachable via the VPN tunnel. Route-based VPNs require the introduction of a separate dynamic routing protocol (or static routes) to distribute VPN routing information among peers.

Overall, I think it's fair to say that route-based VPNs offer a much more robust and versatile VPN solution than the policy-based VPN configuration we examined in part one. (And that's not even taking into consideration more scalable route-based VPN solutions like DMVPN.) But I'm curious to hear what readers prefer: policy-based or route-based? Leave a comment and let everyone know!

The configuration files from all three routers used in both parts of this article are available here.