IPsec Crypto Profile

1. Introduction

Previously we’ve looked at how you deploy IPsec VPNs using the old school crypto maps with, and without, GRE tunnels (1,2,3). In this post we’ll look at a way to simplify the configuration by using the crypto profile feature.

2. Defining the Problem

We’ll continue using the network that we’ve configured in the previous three posts. Currently we have a hub (site 1) and two spokes (site 2, site 3) with GRE over IPsec from the hub to the spokes.

A problem that we’re having with the current network is that the relevant configuration is already quite long and complicated. This is the hub’s current crypto related configuration:

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key CISCO address 65.0.0.1
crypto isakmp key CISCO address 92.0.0.1
!
crypto ipsec transform-set OPTIMUS esp-aes 192 esp-sha-hmac
mode transport
!
crypto map MAP_NAME 10 ipsec-isakmp
set peer 65.0.0.1
set transform-set OPTIMUS
match address MATCH_GRE_R1_R3
crypto map MAP_NAME 20 ipsec-isakmp
set peer 92.0.0.1
set transform-set OPTIMUS
match address MATCH_GRE_R1_R4
!
interface Tunnel3
ip address 192.168.13.1 255.255.255.0
ip ospf 1 area 0
tunnel source 83.0.0.1
tunnel destination 65.0.0.1
!
interface Tunnel4
ip address 192.168.14.1 255.255.255.0
ip ospf 1 area 0
tunnel source 83.0.0.1
tunnel destination 92.0.0.1
!
interface Serial1/0
ip address 83.0.0.1 255.255.255.0
crypto map MAP_NAME
!
ip access-list extended MATCH_GRE_R1_R3
permit gre host 83.0.0.1 host 65.0.0.1
ip access-list extended MATCH_GRE_R1_R4
permit gre host 83.0.0.1 host 92.0.0.1

As you can see, that’s quite a few lines. The crypto profile feature exploits the fact that much of this is redundant. The peers in the crypto map are the same as the tunnel destinations and the ACLs contain the source and destinations of the tunnels. The crypto map is configured on the physical interface, but it only applies to traffic that uses the tunnel interfaces. The crypto maps themselves require one entry per peer to set the peer address and the ACL, but use the same transform set.

3. Configuring A Crypto Profile

To create a crypto profile you simply reference a particular transform set:

!
crypto ipsec profile SITE1_PROFILE
set transform-set OPTIMUS
!

(I apologize for the Transformers reference)

It completely replaces the previous crypto map, which can be removed, including the ACLs. To use the crypto profile, you apply it directly to the tunnel interface:

!
interface Tunnel3
tunnel protection ipsec profile SITE1_PROFILE
!

By applying it to the tunnel interface, you are are implicitly saying that the crypto peer is the tunnel destination and that the traffic that should be encrypted is any traffic that uses the tunnel. The same profile can be applied to multiple tunnels as long as you want them to use the same transform set. By making this change we’ve reduced the complexity of the configuration while still maintaining the same functionality. The full configuration now looks like this:

!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key CISCO address 65.0.0.1
crypto isakmp key CISCO address 92.0.0.1
!
crypto ipsec transform-set OPTIMUS esp-aes 192 esp-sha-hmac
mode transport
!
crypto ipsec profile SITE1_PROFILE
set transform-set OPTIMUS
!
interface Tunnel3
tunnel protection ipsec profile SITE1_PROFILE
!
interface Tunnel4
tunnel protection ipsec profile SITE1_PROFILE
!

It’s not hard to imagine that this style of configuration is much easier to maintain. Note that this new method is fully compatible with GRE over IPsec with crypto maps in the sense that the peer doesn’t necessarily need to change; in my lab, the spokes are still running crypto maps. A router that has multiple tunnels obviously benefits more from crypto profiles since maintaining multiple crypto map entries and ACLs gives you opportunities to make mistakes.

In the next post we’ll continue to build on this configuration by looking at further optimization called Virtual Tunnel Interface (VTI).