IPsec quick and dirty

A reader of last week's post Visualizing tunnels asked for an IPsec example, so here's a rundown continuing from the previous setup. Note that the VTI configuration demonstrated here is different from the older crypto map method used as an example in the IPsec cheat sheet.

The tunnel between R1 and R3 is currently running GRE, the default encapsulation:

R1# show int tun0 | include protocol
Tunnel0 is up, line protocol is up
  Tunnel protocol/transport GRE/IP

A ping from one end of the tunnel's 10.0.0.0/30 subnet to the other verifies end-to-end connectivity.

IKE Configuration

Our first task in converting to an IPsec tunnel is specifying an Internet Key Exchange (IKE) policy. IKE relies on ISAKMP to establish an initial secure channel over which the IPsec tunnel can be negotiated. An IKE policy determines the attributes of the ISAKMP session, including the encryption type and hashing methods.

An empty IKE/ISAKMP policy provides default selections for all attributes. The only attribute we need to manually define in this case is the authentication method, which we'll change from the default of RSA signatures to pre-shared keys (more on this in a bit). We can inspect the completed policy with show crypto isakmp policy:

R1(config)# crypto isakmp policy 10
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# ^Z
R1# sh crypto isakmp policy

Global IKE policy
Protection suite of priority 10
    encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
    hash algorithm:         Secure Hash Standard
    authentication method:  Pre-Shared Key
    Diffie-Hellman group:   #1 (768 bit)
    lifetime:               86400 seconds, no volume limit
...

Our default policy implements DES encryption with SHA-1 hashing and Diffie-Hellman group 1. Don't worry if these terms are foreign to you. There's quite a bit more detail to this whole process, but for now just remember that encryption is used to scramble and unscramble data, whereas hashing uses a small fixed-length checksum (or HMAC) to provide data integrity. The default tunnel lifetime is 86400 seconds (24 hours).

As mentioned, we'll need to define a pre-shared key (versus implementing stronger but more complex public keying). The key is a string of text used to initialize the IKE tunnel, configured identically on both routers. In our example, the string FooB4r is used; in practice, I would obviously suggest a much stronger key. The IP address which follows the key definition specifies the host for which the key should be used.

R1(config)# crypto isakmp key 0 FooB4r address 172.16.0.6

Make sure to reflect this configuration on the opposite end of the tunnel at R3 (use 172.16.0.1 instead of .6). For a full account of IKE policy and authentication configuration, check the official documentation.

IPsec Configuration

Once our IKE policy has been setup we can move on to defining an IPsec transform set. The transform set defines the parameters of the IPsec security associations which will carry the actual data. Note that although we have defined a single tunnel (interface Tunnel0), there will be two unidirectional IPsec security associations, one in either direction.

Unlike defining an IKE policy, which provides a default for all attributes, we must explicitly state the encryption and hash type we want to use with our transform set. Our example will implement ESP encapsulation with 3DES encryption and SHA-1 authentication. Within transform set configuration, we have the option to select tunnel or transport mode; tunnel mode is the default, and suits our scenario. We can inspect our newly created transform set with show crypto ipsec transform-set:

R1(config)# crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac
R1(cfg-crypto-trans)# ^Z
R1# show crypto ipsec transform-set
Transform set MyTransformSet: { esp-3des esp-sha-hmac  }
   will negotiate = { Tunnel,  },

For more information on configuring IPsec transform sets, consult the IOS documentation.

Now that we have our IPsec transform set created, we can reference it from an IPsec profile to be applied to a tunnel interface:

R1(config)# crypto ipsec profile MyProfile
R1(ipsec-profile)# set transform-set MyTransformSet
R1(ipsec-profile)# ^Z
R1# show crypto ipsec profile
IPSEC profile MyProfile
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={
            MyTransformSet,
    }

This step admittedly seems superfluous; why can't we simply reference the transform set directly? In more real-world scenarios, the IPsec profile can serve as a wrapper which points to multiple transform sets, and grants the ability to set additional options beyond the scope of this article.

Tunnel Configuration

Our last step is to convert the tunnel interfaces on routers 1 and 3 to IPsec operation. First we change the tunnel mode from GRE to IPsec for IPv4, then apply our IPsec profile:

R1(config)# interface tun0
R1(config-if)# tunnel mode ipsec ipv4
R1(config-if)# tunnel protection ipsec profile MyProfile

If all goes well, we should now have an ISAKMP security association and two unidirectional IPsec security associations between the tunnel endpoints:

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.16.0.6      172.16.0.1      QM_IDLE           1002    0 ACTIVE

R1# show crypto ipsec sa

interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.16.0.1

protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.16.0.6 port 500
 PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.16.0.1, remote crypto endpt.: 172.16.0.6
 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
 current outbound spi: 0xB1677585(2976347525)

inbound esp sas:
  spi: 0x5351D51E(1397871902)
    transform: esp-3des esp-sha-hmac ,
    in use settings ={Tunnel, }
    conn id: 3, flow_id: SW:3, crypto map: Tunnel0-head-0
    sa timing: remaining key lifetime (k/sec): (4540862/3379)
    IV size: 8 bytes
    replay detection support: Y
    Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
  spi: 0xB1677585(2976347525)
    transform: esp-3des esp-sha-hmac ,
    in use settings ={Tunnel, }
    conn id: 4, flow_id: SW:4, crypto map: Tunnel0-head-0
    sa timing: remaining key lifetime (k/sec): (4540862/3378)
    IV size: 8 bytes
    replay detection support: Y
    Status: ACTIVE

outbound ah sas:

outbound pcp sas:

More information on configuring IPsec across Virtual Tunnel Interfaces (VTIs) is available in the IOS documentation.

Traffic flowing through the tunnel is now encapsulated, encrypted, and authenticated with IPsec. For an example of what the encrypted traffic looks like on the wire, check out this packet capture.

Final Configurations

R1

crypto isakmp policy 10
 authentication pre-share
crypto isakmp key FooB4r address 172.16.0.6
!
crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac 
!
crypto ipsec profile MyProfile
 set transform-set MyTransformSet 
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source 172.16.0.1
 tunnel destination 172.16.0.6
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile MyProfile
!
interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.252

R3

crypto isakmp policy 10
 authentication pre-share
crypto isakmp key FooB4r address 172.16.0.1
!
crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac 
!
crypto ipsec profile MyProfile
 set transform-set MyTransformSet 
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.252
 tunnel source 172.16.0.6
 tunnel destination 172.16.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile MyProfile
!         
interface FastEthernet0/0
 ip address 172.16.0.6 255.255.255.252