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.)
crypto keyring VPN pre-shared-key address 172.16.0.3 key MySecretKey pre-shared-key address 172.17.0.5 key AnotherSecretKey
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.)
crypto isakmp profile R1_to_R5 keyring VPN match identity address 172.17.0.5 255.255.255.255
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.
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
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
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.