Policy-Based vs Route-Based VPNs: Part 1

This is the first part of a two-part post that will compare and contrast policy-based VPNs and route-based VPNs. Policy-based VPNs encrypt and encapsulate a subset of traffic flowing through an interface according to a defined policy (an access list). The policy may dictate that only some or all of the traffic being evaluated is placed into the VPN. This type of VPN is often referred to as LAN-to-LAN when implemented on Cisco ASAs, and I have covered the ASA implementation before. This article examines the configuration of a policy-based VPN on Cisco IOS.

In contrast to a policy-based VPN, a route-based VPN employs routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are formed to direct the desired traffic through the VPN tunnel interface. IPsec quick and dirty provides a decent primer if you're not familiar with route-based VPNs on IOS.

The lab topology employed in this article is easily replicated using Dynamips or the community lab, and I encourage readers to play along in a lab of their own while reading. If you do, be sure to bookmark this VPN troubleshooting guide from Cisco before you begin. It can be a real time-saver should you run into a wall.

Topology

Our goal is to form two VPNs across the "public" network represented by the 172.16.0.0/15 space. (And before anyone brings up my New Year's pledge, I am planning to replicate both VPNs configurations using IPv6 in the future. I just wanted to keep the IP architecture as simple as possible for now since we're already dealing with two fairly complex topics.)

The first part of this article covers setting up a policy-based VPN between R1 and R3. The second part will cover the configuration of a route-based VPN tunnel between R1 and R5, and discuss some pros and cons to both approaches.

Step 1: Define an access list to match interesting traffic

This is the policy part of policy-based VPNs. We need to define an access list to match all the traffic we want to send through the VPN between the two routers. Every line in the access list will result in a bidirectional pair of IPsec security associations (SAs) between the VPN endpoints, so it's beneficial to be as succinct as possible when creating a policy.

For our purposes, we only need to match traffic between the two LANs attached to R1 and R3. Specifically, we need to match traffic from 10.0.1.0/24 to 10.0.3.0/24 on R1, and from 10.0.3.0/24 to 10.0.1.0/24 on R3. This results in two ACLs which mirror each other, one on either router.

R1

ip access-list extended R1_to_R3
 permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255

R3

ip access-list extended R3_to_R1
 permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255

Note that these ACLs must mirror each other exactly in order for the IPsec SAs to form correctly. This is easy when we only have one permit statement, but can become burdensome when dealing with numerous policy entries.

Step 2: Create a pre-shared key

To keep things simple, we'll configure the routers to authenticate one another (via ISAKMP) using a pre-shared key. In the real world, public key authentication provides much better security.

We'll create a keyring to hold our pre-shared keys, which are mapped by peer (public) IP address. R1 maps the key string MySecretKey to R3, and vice versa.

R1

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

R3

crypto keyring VPN 
  pre-shared-key address 172.16.0.1 key MySecretKey

Step 3: Create an ISAKMP policy

Next we'll create an ISAKMP policy. This sets the parameters which will be used by the routers during IKE phase one, when the initial asymmetrically-encrypted ISAKMP SA is negotiated. The policy below employs 256-bit AES using pre-shared key authentication (from step two) and Diffie-Hellman group five.

This policy is applied identically to both routers.

R1 and R3:

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

Step 4: Create an ISAKMP profile

An ISAKMP profile is used to establish parameters for a particular ISAKMP peer by matching its outside IP address. We specify the keyring to be used for this peer so that the router knows how to locate the correct pre-shared key.

R1

crypto isakmp profile R1_to_R3
   keyring VPN
   match identity address 172.16.0.3 255.255.255.255

R3

crypto isakmp profile R3_to_R1
   keyring VPN
   match identity address 172.16.0.1 255.255.255.255

Step 5: Define an IPsec transform-set

Now that ISAKMP is out of the way, we move on to IPsec configuration, which is much less involved: We simply need to define an IPsec transform-set. A transform-set tells the router what protocol, encryption, and hashing algorithms to use when forming the IPsec SAs, as well as in which mode to operate (tunnel or transport) and a few other details. The line below defines a transform-set employing ESP with 256-bit AES and SHA-1 hashing (similar to our ISAKMP policy) in tunnel mode. Create the same transform-set on both routers.

R1 and R3

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

Step 6: Create and apply the crypto map

Finally, we tie together all of these pieces by creating a crypto map, which does a few things. In order of the config snippets presented below, these are:

• Matches "interesting" traffic based on the access list we created in step one
• Sets the remote peer to the outside IP address of the remote router
• Sets the transform-set we defined in step five
• Sets the ISAKMP profile we defined in step four
• Enables static reverse-route injection, which creates static routes for the remote networks specified by the matched access list
• Sets the administrative distance of the injected static routes to ten (optional)

After creating the crypto map, apply it to the appropriate interface on each router.

R1

crypto map Policy_VPN 10 ipsec-isakmp
 match address R1_to_R3
 set peer 172.16.0.3
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R1_to_R3
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN

R3

crypto map Policy_VPN 10 ipsec-isakmp
 match address R3_to_R1
 set peer 172.16.0.1
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R3_to_R1
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN

Our policy VPN configuration is complete! We can verify that the crypto map has injected a static route on R1 for the 10.0.3.0/24 network on R3. (Note that the static parameter of the reverse-route command causes the route to be injected even when the VPN tunnel is not established.)

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

Testing

Policy VPNs by nature are created on-demand when traffic which matches the associated policy (access list) is detected egressing an interface to which the crypto map is applied. Currently, there are no existing ISAKMP SAs:

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status

IPv6 Crypto ISAKMP SA

We can generate some traffic to trigger the creation of the VPN by performing a simple ping whose source and destination addresses are matched by the VPN policy:

R1# ping 10.0.3.1 source 10.0.1.1

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

Notice that the first packet was dropped while the VPN was established. The next four pings succeeded, and we can verify that an ISAKMP SA was established. We can also verify the creation of IPsec SAs with the command show crypto ipsec sa.

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

IPv6 Crypto ISAKMP SA

Successive pings will all succeed so long as the VPN tunnel doesn't time-out.

R1# ping 10.0.3.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.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

That about wraps it up for simple policy-based VPNs. In part two, we'll look at the configuration of a comparable route-based VPN and examine the pros and cons of each approach.