Configuring IPSec Using Manual Keys

20 Mar

Configuring IPSec Using Manual Keys
The use of IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for IPSec standards. Some network equipment may not support IKE, and in these instances, IPSec can be configured without IKE. If IKE is not used for establishing the security associations, there is no negotiation of security associations, so the configuration information in both systems must be the same in order for traffic to be processed successfully by IPSec.

IKE provides for the dynamic creation of SAs and is the preferred method to use with IPSec. This section covers manual configuration. Manual keying involves a direct exchange of keys between IPSec peers, and this method of key exchange is not a very scalable solution for IPSec. A benefit of manual keying is that it allows Cisco networking equipment to work with other vendors’ networking equipment when the services of IPSec are needed and IKE cannot be used. The process of configuring manual IPSec involves the configuration of remote keys during the initial IPSec configuration of the routers. Each crypto map requires multiple keys. For AH authentication, there is a key for both the outbound and inbound sessions. For ESP, there is a cipher and authentication key for both the outbound and inbound sessions.

To configure manual IPSec keys between IPSec peers, follow these steps:

1.To create the crypto map entry and enter the crypto map configuration mode, use the following command:

crypto map map−name seq−num ipsec−manual

The map−name defines the name that identifies the crypto map set. The seq−num parameter is the number that is assigned to this crypto map; it should not be chosen
arbitrarily because this number is used to rank multiple crypto map entries within a crypto map set, and a crypto map entry with a lower seq−num is evaluated before a map entry with a higher seq−num. The ipsec−manual parameter specifies that IKE will not be used to establish the security associations for traffic that is matched by this crypto map and the security associations will be created by a manual process. Use of this command moves you into crypto map configuration mode.

2.In crypto map configuration mode, use the following command to specify an extended access list for a crypto map entry that matches packets for which encryption should be performed:

match address <access−list number | name>

3.To specify an IPSec peer, use this command in crypto map configuration mode:

set peer <ip address | hostname>

You can specify the remote IPSec peer by its hostname if the hostname is mapped to the peer’s IP address in a domain name server (DNS) or you manually map the hostname to the IP address with the ip host command that was discussed earlier. When configuring manual IPSec to set up security associations, you can specify only one peer per crypto map.

To specify which transform sets can be used with the crypto map entry, use the following command:

set transform set <transform−set−name1> −
<transform−set−name2….transform−set−name6>

List multiple transform sets in order of priority with the highest−priority transform set listed first. When configuring manual IPSec to set up security associations, you can specify one transform set per crypto map.

5.Use one of the following commands to manually specify the session keys for AH or ESP. The ah parameter sets the session key for the Authentication Header protocol:

set session−key <inbound | outbound> ah <spi> <hex−key−string>

The esp parameter sets the session key for the Encapsulating Security Protocol:

set session−key <inbound | outbound> esp <spi> cipher −
<hex−key−string> authenticator <hex−key−string>

When defining the session key for either the AH protocol or the ESP protocol, both an inbound and outbound key must be configured for each peer. Figure 6.8 displays a network with two routers separated by a WAN that must protect data via the use of IPSec. The routers will be configured to use IPSec with manual keys.

Because the configuration of manual IPSec is different when using the Authentication Header protocol as opposed to the Encapsulating Security Payload within a transform set, each configuration will be discussed separately. Listing 6.13 and Listing 6.14 display the manual IPSec configurations of Router 1 and Router 2 in Figure 6.8 using AH transform sets.

Listing 6.13: Manual AH configuration of Router 1.

hostname Router−1
!
username ipsec privilege 15 password 0 ipsec
memory−size iomem 10
ip subnet−zero
ip tcp synwait−time 10
no ip domain−lookup
!
crypto ipsec transform−set manual ah−sha−hmac
!
crypto map toR2 10 ipsec−manual
set peer 192.168.200.2
set transform−set manual
match address 110 set session−key inbound ah 3073 −
CCCC1234567890CCCC1234567890CCCC1234567890CCCC
set session−key outbound ah 3072 −
DDDD1234567890DDDD1234567890DDDD1234567890DDD1
!
interface Ethernet1
ip address 192.168.10.1 255.255.255.128
no ip directed−broadcast
!
interface Serial1/0
ip address 192.168.200.1 255.255.255.0
no ip directed−broadcast
no ip mroute−cache
no fair−queue crypto map mesh
!
ip classless
!
access−list 110 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 –
0.0.0.255
!

Listing 6.14: Manual AH configuration of Router 2.

hostname Router−2
!
username ipsec privilege 15 password 0 ipsec
memory−size iomem 10
ip subnet−zero ip tcp synwait−time 10
no ip domain−lookup
!
crypto ipsec transform−set manual ah−sha−hmac
!
crypto map toR1 10 ipsec−manual
set peer 192.168.200.1
set transform−set manual
match address 101
set session−key inbound ah 3072 −
DDDD1234567890DDDD1234567890DDDD1234567890DDD1
set session−key outbound ah 3073 −
CCCC1234567890CCCC1234567890CCCC1234567890CCCC
!
interface Ethernet1/0
ip address 192.168.11.1 255.255.255.128
no ip directed−broadcast
!
interface Serial0/0
ip address 192.168.200.2 255.255.255.0
no ip directed−broadcast
no ip mroute−cache
no fair−queue

crypto map mesh
!
ip classless
!
access−list 101 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 −
0.0.0.255
!

Figure 6.8: Network using manual IPSec Keys

Note The configurations in Listing 6.13 and Listing 6.14 are not recommended for a production environment because each configuration provides authentication services only for the IP packet.

Access lists are read in sequential order by a router; as such, any packet in Listing 6.14 that has a source IP address that is within the 192.168.11.0 subnet with a destination IP address within the 192.168.10.0 subnet will match access list 101 (which is defined under crypto map toR1) and create a match rule for IPSec, thus allowing IPSec to provide authentication services on the packet. Any other packet that does not match the permit statement within access list 101 will not be protected by IPSec because of the implicit deny any at the end of the access list. Security associations established via the use of manual IPSec do not expire (whereas security associations
established via IKE do), and an inbound session key configured on one IPSec peer must match the  outbound session key configured on the remote IPSec peer. To view the manual security associations established on each router, you must issue the show crypto ipsec sa command. Issuing the show crypto ipsec sa command on Router 2 displays the output in Listing 6.15.

Listing 6.15: Manual security associations on Router 2.

Router−2#sh crypto ipsec sa
interface: Serial0/0
Crypto map tag: toR1, local addr. 192.168.200.2
!
local ident: (192.168.11.0/255.255.255.0/0/0)
remote ident: (192.168.10.0/255.255.255.0/0/0)
current_peer: 192.168.200.1
PERMIT, flags={origin_is_acl,}
pkts encaps: 117, pkts encrypt: 49, pkts digest 117
pkts decaps: 116, pkts decrypt: 48, pkts verify 116
pkts compressed: 0, pkts decompressed: 0
pkts not compressed: 0, pkts compr. failed: 0, −
pkts decompress failed: 0
send errors 1, recv errors 0
!
local crypto endpt.: 192.168.200.2, −

remote crypto endpt.: 192.168.200.1
path mtu 1500, media mtu 1500
current outbound spi: C01
!
inbound esp sas:
!
inbound ah sas:
spi: 0xC00(3072)
transform: ah−sha−hmac ,
in use settings ={Tunnel,}
slot: 0, conn id: 2001, flow_id: 1, crypto map: toR1
no sa timing
replay detection support: Y
!
inbound pcp sas:
!
outbound esp sas:
!
outbound ah sas:
spi: 0xC01(3073)
transform: ah−sha−hmac,
in use settings ={Tunnel,}
slot: 0, conn id: 2000, flow_id: 2, crypto map: toR1
no sa timing
replay detection support: Y
!
outbound pcp sas:
!
Router−2#
!

Notice the highlighted lines in Listing 6.15; each of these lines state that the security association for inbound and outbound traffic do not timeout, unlike security associations created using IKE. During the configuration of Router 2 in Listing 6.14, the debug crypto ipsec, debug crypto engine, and debug crypto key−exchange commands were used to verify that both routers were configured correctly. The output from those commands can be seen in Listing 6.16.

Listing 6.16: Security association process on Router 2.

Router−2#debug crypto ipsec
Crypto IPSEC debugging is on
Router−2#debug crypto engine
Crypto Engine debugging is on
Router−2#debug crypto key−exchange
Crypto Key Exchange debugging is on
!
: IPSEC(sa_request): ,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= AH, transform= ah−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×173715C3(389486019), conn_id= 0, keysize= 0,
flags= 0×4004
: IPSEC(key_engine): got a queue event…
: IPSEC(initialize_sas):,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= AH, transform= ah−sha−hmac,

lifedur= 3600s and 4608000kb,
spi= 0xC01(3073), conn_id= 2000, keysize= 0, flags= 0×4
: IPSEC(initialize_sas):,
(key eng. msg.) dest= 192.168.200.2, src= 192.168.200.1,
dest_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
src_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= AH, transform= ah−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0xC00(3072), conn_id= 2001, keysize= 0, flags= 0×4
: IPSEC(create_sa): sa created,
(sa) sa_dest= 192.168.200.1, sa_prot= 51,
sa_spi= 0xC01(3073),
sa_trans= ah−sha−hmac, sa_conn_id= 2000
: IPSEC(create_sa): sa created,
(sa) sa_dest= 192.168.200.2, sa_prot= 51,
sa_spi= 0xC00(3072),
sa_trans= ah−sha−hmac, sa_conn_id= 2001

The manual IPSec configurations of Router 1 and Router 2 in Listings 6.13 and 6.14, which used AH only to provide authentication services, do not provide the strongest form of encryption services. In fact, the configurations did not provide any encryption services; they provided only authentication. To provide the encryption services, the use of ESP is needed.

Router 1 and Router 2 in Figure 6.8 will be configured to provide the security services of both AH and ESP. The crypto map that is defined for each router will make use of a transform set that includes an ESP encryption protocol, and as such, each router will define IPSec keys for ESP encryption for both inbound and outbound traffic. The transform set will also include an ESP authentication protocol, so an IPSec key for ESP authentication for inbound and outbound traffic must be defined as well. The configuration of the AH protocol will remain the same as they are in Listing 6.13 and 6.14. The manual AH and ESP configuration of Router 1 and Router 2 are
displayed in Listing 6.17 and Listing 6.18.

Listing 6.17: Manual AH and ESP configuration of Router 1.

hostname Router−1
!
username ipsec privilege 15 password 0 ipsec
memory−size iomem 10
ip subnet−zero
ip tcp synwait−time 10
no ip domain−lookup
!
crypto ipsec transform−set manual ah−sha−hmac esp−des −
esp−sha−hmac
!
crypto map toR2 10 ipsec−manual
set peer 192.168.200.2
set transform−set manual
match address 110
set session−key inbound esp 4096 cipher −
BBBB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator −
1234567890BBBB1234567890BBBB1234567890BBBB1234
set session−key outbound esp 4098 cipher −
AAAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator −
1234567890AAAA1234567890AAAA1234567890AAAA1234
set session−key inbound ah 3073 −
CCCC1234567890CCCC1234567890CCCC1234567890CCCC

set session−key outbound ah 3072 −
DDDD1234567890DDDD1234567890DDDD1234567890DDD1
!
interface Ethernet1
ip address 192.168.10.1 255.255.255.128
no ip directed−broadcast
ip nat inside
!
interface Serial1/0
ip address 192.168.200.1 255.255.255.0
no ip directed−broadcast
ip nat outside
no ip mroute−cache
no fair−queue
crypto map mesh
!
ip nat inside source route−map donotnat interface Serial1/0 −
overload
ip classless
!
access−list 110 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 −
0.0.0.255
access−list 112 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 −
0.0.0.255
access−list 112 permit ip 192.168.10.0 0.0.0.255 any
!
route−map donotnat permit 10
match ip address 112


Listing 6.18: Manual AH and ESP configuration of Router 2.

hostname Router−2
!
username ipsec privilege 15 password 0 ipsec
memory−size iomem 10
ip subnet−zero
ip tcp synwait−time 10
no ip domain−lookup
!
crypto ipsec transform−set manual ah−sha−hmac esp−des
esp−sha−hma
!
crypto map toR1 10 ipsec−manual
set peer 192.168.200.1
set transform−set manual
match address 101
set session−key inbound esp 4098 cipher −
AAAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator −
1234567890AAAA1234567890AAAA1234567890AAAA1234
set session−key outbound esp 4096 cipher −
BB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator −
1234567890BBBB1234567890BBBB1234567890BBBB1234
set session−key inbound ah 3072 −
DDDD1234567890DDDD1234567890DDDD1234567890DDD1
set session−key outbound ah 3073 −
CCCC1234567890CCCC1234567890CCCC1234567890CCCC
!
interface Ethernet1/0
ip address 192.168.11.1 255.255.255.128
no ip directed−broadcast
ip nat inside
!

interface Serial0/0
ip address 192.168.200.2 255.255.255.0
no ip directed−broadcast
ip nat outside
no ip mroute−cache
no fair−queue
crypto map mesh
!
ip nat inside source route−map donotnat interface Serial0/0 −
overload
ip classless
!
access−list 101 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 −
0.0.0.255
access−list 102 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 −
0.0.0.255
access−list 102 permit ip 192.168.10.0 0.0.0.255 any
!
route−map donotnat permit 10
match ip address 102

Again, security associations established via the use of manual IPSec do not expire (whereas security associations established via IKE do) and an inbound session key configured on one IPSec peer must match the outbound session key configured on the remote IPSec peer. To view the manual security associations established on each router, you must issue the show crypto ipsec sa command. Issuing the show crypto ipsec sa command on Router 1 displays the output in Listing 6.19.

Listing 6.19: Manual security associations on Router 1.

Router−1#sh crypto ipsec sa
interface: Ethernet0/0
Crypto map tag: toR2, local addr. 192.168.200.1
local ident: (192.168.10.0/255.255.255.0/0/0)
remote ident: (192.168.11.0/255.255.255.0/0/0)
current_peer: 192.168.200.2
PERMIT, flags={origin_is_acl,}
pkts encaps: 705, pkts encrypt: 705, pkts digest 705
pkts decaps: 699, pkts decrypt: 699, pkts verify 699
pkts compressed: 0, pkts decompressed: 0
pkts not compressed: 0, pkts compr. failed: 0,
pkts decompress failed: 0
send errors 0, #recv errors 0
!
local crypto endpt.: 192.168.200.1,
remote crypto endpt.: 192.168.200.2
path mtu 1500, media mtu 1500
current outbound spi: 1002
!
inbound esp sas:
spi: 0×1000(4096)
transform: esp−des esp−sha−hmac,
in use settings ={Tunnel,}
slot: 0, conn id: 2003, flow_id: 1, crypto map: toR2
no sa timing
IV size: 8 bytes
replay detection support: Y
!
inbound ah sas:

spi: 0xC01(3073)
transform: ah−sha−hmac,
in use settings ={Tunnel,}
slot: 0, conn id: 2002, flow_id: 1, crypto map: toR2
no sa timing
replay detection support: Y
inbound pcp sas:
!
outbound esp sas:
spi: 0×1002(4098)
transform: esp−des esp−sha−hmac,
in use settings ={Tunnel,}
slot: 0, conn id: 2001, flow_id: 2, crypto map: toR2
no sa timing
IV size: 8 bytes
replay detection support: Y
!
outbound ah sas:
spi: 0xC00(3072)
transform: ah−sha−hmac,
in use settings ={Tunnel,}
slot: 0, conn id: 2000, flow_id: 2, crypto map: toR2
no sa timing
replay detection support: Y
!
outbound pcp sas:
Router−1#

One other useful command that can be used to verify that all security associations are configured properly and that each one is active is the show crypto engine connection active command. This command will display the current active encrypted session connections. Issuing the command on Router 2 displays the following output:

Router−2#sh crypto en conn ac
!
ID Interface IP−Address State Algorithm Enc Dec
2000 Serial0/0 192.168.200.2 set HMAC_SHA 612 0
2001 Serial0/0 192.168.200.2 set HMAC_SHA+DES_56_CB 612 0
2002 Serial0/0 192.168.200.2 set HMAC_SHA 0 612
2003 Serial0/0 192.168.200.2 set MAC_SHA+DES_56_CB 0 612

The ID field is the connection ID number, and each active encrypted session connection is identified by an ID number. The Interface field identifies the interface that is involved in the encrypted session connection. The IP−Address field identifies the IP address of the interface involved in the encrypted session. The State field identifies the state of the connection. The Algorithm field identifies the algorithm that is used to encrypt or to decrypt the packets. The Enc field displays the total number of outbound encrypted packets, and the Dec field displays the total number of inbound encrypted packets.

Although manual IPSec configurations allow a security administrator to have strict control over the implementation of IPSec VPNs, as well provide interoperability with any device that does not support the IPSec utility services of IKE, these advantages come with an added cost. The overhead associated with maintaining strict control over the IPSec VPNs can become burdensome as the number of VPNs the company has begins to grow. Security administrators should always be aware that when configuring manual IPSec, each router should contain a mirror copy IPSec configuration of its peer router. One of the problems associated with manual IPSec configurations is incorrectly configured keys between peers.

For instance, changing the keys on Router 2 in Listing 6.18 will result in encryption not taking place and error messages being displayed on Router 2. Listing 6.20 displays the new, incorrectly configured keys on Router 2.

Listing 6.20: Changing keys on Router 2.

crypto map toR1 10 ipsec−manual
no set session−key inbound esp 4098 cipher −
AAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator −
1234567890AAAA1234567890AAAA1234567890AAAA1234
no set session−key outbound esp 4096 cipher −
BBBB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator −
1234567890BBBB1234567890BBBB1234567890BBBB1234
no set session−key inbound ah 3072 −
DDD1234567890DDDD1234567890DDDD1234567890DDD1
no set session−key outbound ah 3073−
CCCC1234567890CCCC1234567890CCCC1234567890CCCC
!
set session−key inbound esp 4098 cipher −
11111111111111111111111111111111111111111111111 authenticator −
1111111111111111111111111111111111111111111111
set session−key outbound esp 4096 cipher −
2222222222222222222222222222222222222222222222 authenticator −
2222222222222222222222222222222222222222222222
set session−key inbound ah 3072 −
3333333333333333333333333333333333333333333333
set session−key outbound ah 3073 −
4444444444444444444444444444444444444444444444

First, the original keys were deleted using the no form the set session−key command, and then the new keys were added into the configuration. As the keys are being changed, Router 2 begins to delete each security association it had configured. This can be seen in Listing 6.21 by issuing the debug crypto ipsec and debug crypto engine commands.

Listing 6.21: Router 2 deleting security associations.

: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 192.168.200.1, sa_prot= 51,
sa_spi= 0xC01(3073),
sa_trans= ah−sha−hmac, sa_conn_id= 2000
: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 192.168.200.1, sa_prot= 50,
sa_spi= 0×1000(4096),
sa_trans= esp−des esp−sha−hmac, sa_conn_id= 2001
: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 192.168.200.2, sa_prot= 51,
sa_spi= 0xC00(3072),
sa_trans= ah−sha−hmac , sa_conn_id= 2002
: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 192.168.200.2, sa_prot= 50,
sa_spi= 0×1002(4098),
sa_trans=esp−des esp−sha−hmac, sa_conn_id=2003

Router 2 at this point has deleted each of the existing security associations it had configured for its peer IPSec router. After the new keys (which are incorrect) are configured on Router 2 under the crypto map and a packet that matches the encryption access list is received on the router, Router 2 should attempt to set a security association with Router 1. However, the security association attempt should fail because of incorrectly configured keys between the routers. This process can be
seen in the output in Listing 6.22.

Listing 6.22: Router 2’s failed attempt to set a security association.

: IPSEC(sa_request): ,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= AH, transform= ah−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×1028254B(271066443), conn_id= 0, keysize= 0,
flags= 0×4004
: IPSEC(sa_request):,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp−des esp−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×2360B83(37096323), conn_id= 0, keysize= 0,
flags= 0×4004
: IPSEC(manual_key_stuffing): keys missing for −
addr 192.168.200.2/prot 50/spi 0.
: IPSEC(sa_request):,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= AH, transform= ah−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0xB2C0887(187435143), conn_id= 0, keysize= 0,
flags= 0×4004
: IPSEC(sa_request):,
(key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1,
src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4),
dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp−des esp−sha−hmac,
lifedur= 3600s and 4608000kb,
spi= 0×4AD1EE4(78454500), conn_id= 0, keysize= 0,
flags= 0×4004
: IPSEC(manual_key_stuffing): keys missing for −
addr 192.168.200.2/prot 50/spi 0.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.