Chapter 4: Common IPsec VPN Issues

Cisco Press

1 2 3 4 5 6 7 8 9 Page 3
Page 3 of 9

Example 4-13, line 5, confirms that ISAKMP SA negotiation is initiated with RSA Encryption for authentication. Output from Example 4-13, line 8, indicates that IKE messages cannot be decrypted, because Router_B is mistakenly using Router_A's decryption key for encrypting IKE messages to Router_A, rather than using Router_A's proper encryption key to do so. Example 4-13, lines 19-40, illustrate that the same key misconfiguration on Router_A is causing IKE SA authentication to fail on Router_B for the same reasons it failed earlier on Router_A.

Example 4-13 Troubleshooting IKE Authentication Failures with RSA Encryption

1 Router_A#debug crypto isakmp
2 Crypto ISAKMP debugging is on
3 !
4 !
5 *Feb 17 10:58:20.066: ISAKMP (0:1): SA is doing RSA encryption authentication using id type ID_IPV4_ADDR
6 !
7 !
8 *Feb 17 10:58:20.554: %CRYPTO-6-IKMP_CRYPT_FAILURE: IKE (connection id 1) unable to decrypt (w/RSA private key) packet
9 !
10 !
11 *Feb 17 10:58:41.706: ISAKMP (0:1): retransmitting phase 1 MM_SA_SETUP...
12 *Feb 17 10:58:41.706: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
13 !
14 !
15 *Feb 17 10:59:19.918: ISAKMP (0:1): deleting SA reason "gen_IPsec_isakmp_delete but doi isakmp" state (I) MM_SA_SETUP (peer 200.0.0.2) input queue 0
16 *Feb 17 10:59:19.918: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
17 *Feb 17 10:59:19.918: ISAKMP (0:1): Old State = IKE_I_MM3 New State = IKE_DEST_SA
18
19 Router_B#debug crypto isakmp
20 Crypto ISAKMP debugging is on
21 !
22 !
23 *Feb 17 10:01:10.930: ISAKMP:(0:1:SW:1):SA is doing RSA encryption authentication using id type ID_IPV4_ADDR
24 !
25 !
26 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): retransmitting phase 1 MM_KEY_EXCH
27 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): sending packet to 200.1.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
28 !
29 !
30 *Feb 17 10:01:55.466: ISAKMP: quick mode timer expired.
31 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):src 200.0.0.1 dst 200.0.0.2, SA is not authenticated
32 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives.
33 !
34 !
35 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R) MM_KEY_EXCH (peer 200.0.0.1)
36 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R) MM_KEY_EXCH (peer 200.1.1.1) 
37 *Feb 17 10:01:55.466: ISAKMP: Unlocking IKE struct 0x65C405A8 for isadb_mark_sa_deleted(), count 0
38 *Feb 17 10:01:55.466: ISAKMP: Deleting peer node by peer_reap for 200.1.1.1: 65C405A8
39 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
40 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_DEST_SA

Cisco IOS VPN endpoints can be instructed to use certain RSA public keys with certain peers, a similar functionality to standard PSK authentication. As such, it is important that each VPN endpoint is using the correct key for the correct peer. Consider once again the situation in which the administrators of Router_A choose to source the VPN tunnel endpoint from their loopback1 (201.0.0.1) interface. The administrators of Router_B have fixed the mismatching key problem in Example 4-11 through Example 4-13, and have updated their IPsec configuration to peer with Router_A's loopback address. However, they have not updated the address that ISAKMP should use when authenticating the IKE channel with Router_B's public/encryption key (see configurations listed in Figure 4-4). Therefore, Router_B cannot select the appropriate public key to authenticate the IKE channel with Router_A. Once again, this leads to an IKE Authentication error, which eventually causes ISAKMP SA negotiation to time out.

Figure 4-4

Figure 4-4

RSA Encryption and ISAKMP Peer Mismatches

Example 4-14 provides the RSA key configuration for Router_A in Figure 4-4.

Example 4-14 Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure 4-4 (Router_B Configuration Provided in Example 4-15)

1  Router_A#show crypto key mypubkey rsa
2  % Key pair was generated at: 10:56:03 UTC Feb 17 2005
3  Key name: Router_A.cisco.com
4  Usage: General Purpose Key
5  Key is not exportable.
6  Key Data:
7   305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 
8   415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 
9   4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10 % Key pair was generated at: 11:56:05 UTC Feb 17 2005
11 Key name: Router_A.cisco.com.server
12  Usage: Encryption Key
13  Key is not exportable.
14  Key Data:
15  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A233B3 3A58DDB2 
16  D578B1A4 0125E1CD 1594C9F2 24DACE5E 65A276C7 640E9A13 B8DC4EEC F332B8D8 
17  80127FD6 07A579F6 A280DF7D 2ED2CA8B 3457F5DE 53DAB835 C2845EB6 42F89BB0 
18  C7130F67 B10FD71E 30A1FB1E 812CA1A6 26F43DCA 7BDDA01D 65020301 0001
19
20 Router_A#show crypto key pubkey-chain rsa address 200.0.0.2
21 Key address:    200.0.0.2       
22  Usage: General Purpose Key
23  Source: Manually entered
24  Data:
25  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF 
26  64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE 
27  28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162 
28  C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4 
29  5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

Example 4-15 provides the RSA key configuration for Router_B in Figure 4-4. Note that, although the public and private keys have been correctly configured on Router_A and Router_B, Router_B is not configured with the correct peering information in its encryption key settings to be used with Router_A. This peer mismatch is illustrated in Example 4-15, lines 22-23.

Example 4-15 Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure 4-4 (Router_A Configuration Provided in Example 4-14)

1  Router_B#show crypto key mypubkey rsa
2  % Key pair was generated at: 09:59:17 UTC Feb 17 2005
3  Key name: Router_B.cisco.com
4  Usage: General Purpose Key
5  Key is not exportable.
6  Key Data:
7   30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF 
8   64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE 
9   28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162 
10  C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4 
11  5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
12 % Key pair was generated at: 10:59:18 UTC Feb 17 2005
13 Key name: Router_B.cisco.com.server
14  Usage: Encryption Key
15  Key is not exportable.
16  Key Data:
17  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CA138A 38268367 
18  9FB2BDA8 A5C4677B 06A0FA1C 7811BAA6 C6FA48A7 E3DE55D0 B6967E71 DF076209 
19  1F3CCA1E A7F40179 B4013CC8 ADCB15DD FFDAFAC3 9210BEA7 894DEEDA 1BF59C4B 
20  B0143E21 80559A4D 4F8A512E DB739E8B 576E61FD 650BDA6B 87020301 0001
21
22 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1
23 Key address:    200.0.0.1       
24  Usage: General Purpose Key
25  Source: Manually entered
26  Data:
27  305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 
28  415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 
29  4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001

Once the configuration on Router_B (Example 4-15, lines 22-23) has been updated to use Router_A's public key with Router_A's new peering information (lo1=201.0.0.1), then the ISAKMP SA can be negotiated successfully using RSA Encryption as confirmed in Example 4-16.

Example 4-16 Updated Peer Configuration on Router_B, and ISAKMP SA Confirmation

1 Router_B#sh run
2 Building configuration...
3 crypto key pubkey-chain rsa
4  addressed-key 201.0.0.1
5  address 201.0.0.1
6  key-string
7   305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 
8   415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 
9   4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10  quit
11
12 Router_B#ping
13 !
14 !
15 Sending 5, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds:
16 Packet sent with a source address of 202.2.2.1 
17 .!!!!
18 Success rate is 80 percent (4/5), round-trip min/avg/max = 40/43/44 ms
19 *Feb 17 11:21:41.570: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 201.0.0.1:500    Id: 201.0.0.1
20 Router_B#show crypto isakmp sa
21 dst       src       state     conn-id slot
22 201.0.0.1    200.1.1.2    QM_IDLE       1  0
23 Router_B#show crypto key pubkey-chain rsa 
24 Codes: M - Manually configured, C - Extracted from certificate
25
26 Code Usage     IP-Address/VRF     Keyring     Name
27 M  General    201.0.0.1       default

Note - In the preceding examples pertaining to RSA encryption, Router_A (512 bit-mod) and Router_B (1024-bit mod) have been using mismatched key modulus. This will not cause IKE authentication errors, but does not provide the same strength in authentication as using 1024-bit keys on both sides.


Last, it is important to note that the configurations above use IP addresses (addressed-key) selecting public keys to use with their corresponding peer. Alternately, administrators can use hostnames to identify peers, instead of IP addresses. When using hostnames, administrators must verify that the hostname can be resolved to an IP address via DNS or manually using the ip host [ip-address] [hostname] command in the local router configuration. Additionally, each peer using a hostname for ISAKMP identification must be instructed to do so using the crypto isakmp identity [hostname] command, as the default is use of the IP address associated with the physical interface where the crypto map is applied.

IKE Authentication Errors with RSA Signatures

As we'll discuss later in Chapter 11, the dynamics of authentication change dramatically when RSA signatures are used. Until now, we've discussed IKE SA authentication methods that require direct key exchange between crypto endpoints, including both IKE PSK and RSA Encrypted Nonce methods of IKE authentication. Now we will discuss the RSA Signatures method of IKE SA authentication, in which both endpoints are authenticated indirectly using a centralized trusted resource, a Certificate Authority (CA), during Phase 1 negotiation. As such, our focus will not be on endpoint-endpoint authentication and peering, but instead will explore common IKE authentication issues attributable to endpoint-CA operation:

  • Authenticating the CA and Obtaining the CA Certificate

  • Enrolling with the CA and Obtaining Public Key Certificates

We will examine debugs and diagnostics for each of these processes using the topology in Figure 4-5, as Routers A and B obtain certificates from IOS_CAROOT needed for IKE authentication using RSA Signatures. It has been confirmed that Router_A and Router_B can reach the CA.

Figure 4-5

Figure 4-5

Troubleshooting IKE Authentication Errors with RSA Signatures

Example 4-17 provides the configuration for Router_A in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Example 4-17 RSA Signatures Configuration on Router_A (Figure 4-5)

Router_A#show crypto ca certificates
Certificate
 Status: Available
 Certificate Serial Number: 03
 Certificate Usage: General Purpose
 Issuer: 
  cn=IOS_CAROOT
 Subject:
  Name: Router_A.cisco.com
  IP Address: 192.168.1.1
  Serial Number: 01C2F27F
  serialNumber=1C2F27F+ipaddress=192.168.1.1+hostname=Router_A.cisco.com
 Validity Date: 
  start date: 10:12:45 UTC Feb 24 2005
  end  date: 10:12:45 UTC Feb 24 2006
  renew date: 00:00:00 UTC Jan 1 1970
 Associated Trustpoints: IOS_CAROOT 

CA Certificate
 Status: Available
 Certificate Serial Number: 01
 Certificate Usage: Signature
 Issuer: 
  cn=IOS_CAROOT
 Subject: 
  cn=IOS_CAROOT
 Validity Date: 
  start date: 09:06:11 UTC Feb 24 2005
  end  date: 09:06:11 UTC Feb 24 2008
 Associated Trustpoints: IOS_CAROOT 

Router_A#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:30 UTC Feb 24 2005
Key name: Router_A.cisco.com
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AF2FC9 
 1919ECF1 DE24C37D 796658E2 2B186600 98EB5CE3 AE0E53FE B1F736EA CE417989 
 F3029E25 594B9BCB 30DD0A2D 799814B1 555071FE BFB081E1 80548F91 3021F997 
 0FBC0B62 4A6284A4 22175B89 4D5C00B2 4DE6F657 F6CA00DA E8629294 413487F6 
 6AB72BAF 071F4C63 CD813C3A 8925B95D F3DE265C CCFA3AA5 C38386DA 25020301 0001
% Key pair was generated at: 10:11:31 UTC Feb 24 2005
Key name: Router_A.cisco.com.server
 Usage: Encryption Key
 Key is exportable.
 Key Data:
 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C7CE18 CD11DBAE 
 6FE6999B 15E81063 998CD039 91677AAD 9E310C38 9CF10010 EE3BBD5C 574837E8 
 08098084 D1F09C7D 9143F22C 6684AAA5 9B518676 AB205A9B 2681B77A 24E69ABA 
 734AB29C 28D4A672 4C93B3B4 DE27CB77 FF0DBBF0 2A5ABF1F AF020301 0001

Router_A#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate

Code Usage     IP-Address/VRF     Keyring     Name
C  Signing               default     X.500 DN name: 
               cn=IOS_CAROOT

C  Signing   192.168.2.1/      default     Router_B.cisco.com

Example 4-18 provides the configuration for Router_B in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Related:
1 2 3 4 5 6 7 8 9 Page 3
Page 3 of 9
IT Salary Survey: The results are in