|
|
Troubleshooting IPSec VPNsWhen troubleshooting IPSec VPNs, it is important to adopt a step-by-step approach. The first step in troubleshooting IPSec VPNs is to verify IKE phase 1 negotiation between the peer routers. Once this has been verified, the next step is to verify IKE phase 2. In the final step, you should verify that user traffic is being transported successfully over the IPSec tunnel. The flowchart in Figure 8-13 describes the troubleshooting process used with IPSec VPNs. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network. Figure 8-13. IPSec VPN Troubleshooting Flowchart
Refer to the sample topology in Figure 8-14 for the various concepts discussed in the troubleshooting sections that follow. You may also find it useful to refer back to Table 8-1 as you read command output. Figure 8-14. Sample IPSec VPN Topology In this example, the initiator of IKE negotiation is called Tokyo, and the responder is called Osaka. When troubleshooting IPSec, it is a good idea to start on the initiator, which in this scenario is Tokyo. IKE Phase 1 (Main Mode) Negotiation FailsTwo peers attempting to establish an IPSec tunnel must complete IKE negotiation. IKE negotiation is in two parts:
If IKE phase 1 negotiation fails, phase 2 cannot begin, and no IPSec SAs will be established. Figure 8-15 illustrates Phase 1 negotiation. Figure 8-15. IKE Phase 1 Negotiation Before troubleshooting IKE phase 1, it is worth examining a successful IKE negotiation sequence using the debug crypto isakmp command. Examples 8-25 to 8-28 show successful IKE main mode negotiation. Note that only the relevant portion of the output is shown. Example 8-25. Successful IKE Main Mode NegotiationTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 7 16:14:29.027 GMT: ISAKMP: received ke message (1/1) Mar 7 16:14:29.027 GMT: ISAKMP: local port 500, remote port 500 Mar 7 16:14:29.027 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM Old State = IKE_READY New State = IKE_I_MM1 Mar 7 16:14:29.027 GMT: ISAKMP (0:1): beginning Main Mode exchange Mar 7 16:14:29.027 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE In highlighted line 1, you can see the message Old State = IKE_READY New State = IKE_I_MM1. This indicates that IKE negotiation has been initiated, and the first ISAKMP message in the main mode exchange is about to be sent. Note the I in the message here. This character indicates that Tokyo is the initiator of IKE negotiation. If Tokyo were the responder, then an R would be shown. Highlighted line 2 shows that IKE main mode is about to begin. In highlighted line 3, main mode begins with Tokyo (the initiator) sending IKE SA proposals to Osaka (172.16.6.2, the responder). These proposals correspond to the policies configured on Tokyo (crypto isakmp policy policy_number). In Example 8-26, a proposal acceptance is received from Osaka. Example 8-26. Received Proposal Acceptance from Osaka (the Responder)Mar 7 16:14:29.067 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_NO_STATE Mar 7 16:14:29.067 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_I_MM1 New State = IKE_I_MM2 Mar 7 16:14:29.067 GMT: ISAKMP (0:1): processing SA payload. message ID = 0 Mar 7 16:14:29.067 GMT: ISAKMP (0:1): found peer pre-shared key matching 172.16.6.2 Mar 7 16:14:29.067 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 10 policy Mar 7 16:14:29.067 GMT: ISAKMP: encryption DES-CBC Mar 7 16:14:29.067 GMT: ISAKMP: hash MD5 Mar 7 16:14:29.067 GMT: ISAKMP: default group 1 Mar 7 16:14:29.067 GMT: ISAKMP: auth pre-share Mar 7 16:14:29.067 GMT: ISAKMP: life type in seconds Mar 7 16:14:29.067 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 Mar 7 16:14:29.067 GMT: ISAKMP (0:1): atts are acceptable. Next payload is 0 Mar 7 16:14:29.103 GMT: ISAKMP (0:1): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR Mar 7 16:14:29.103 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Old State = IKE_I_MM2 New State = IKE_I_MM2 A message is now received from Osaka (highlighted line 1). This message contains the accepted proposal (one out of those sent in Tokyo's initial message in Example 8-25, highlighted line 2). Highlighted line 2 shows that the state has moved from IKE_I_MM1 to IKE_I_MM2, indicating that this is the second message in the IKE exchange. Tokyo now begins to process the SA payload, which contains the accepted proposal, in highlighted line 3. Note the message ID here. The function of the message ID is to distinguish messages for different phase 2 exchanges (SAs) from each other, and so it remains as zero throughout main mode negotiation. In highlighted lines 4 to 9, you can see the accepted proposal. The proposal, in this case, consists of DES encryption, the MD5 hash algorithm, preshared key authentication, and an SA lifetime of 86,400 seconds (seen in hexadecimal notation in highlighted line 9). Then in highlighted line 10, Tokyo reports that these proposal attributes are acceptable. Tokyo and Osaka have now negotiated the parameters (attributes) of the IKE SA, and are now ready to exchange Diffie-Hellman public values and nonces (random numbers), as demonstrated in Example 8-27. Example 8-27. Exchange of Diffie-Hellman Public Values and Nonces (Messages Three and Four)Mar 7 16:14:29.103 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_SA_SETUP Mar 7 16:14:29.107 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE Old State = IKE_I_MM2 New State = IKE_I_MM3 Mar 7 16:14:29.147 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_SA_SETUP Mar 7 16:14:29.147 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_I_MM3 New State = IKE_I_MM4 Mar 7 16:14:29.147 GMT: ISAKMP (0:1): processing KE payload. message ID = 0 Mar 7 16:14:29.183 GMT: ISAKMP (0:1): processing NONCE payload. message ID = 0 Mar 7 16:14:29.183 GMT: ISAKMP (0:1): found peer pre-shared key matching 172.16.6.2 Mar 7 16:14:29.183 GMT: ISAKMP (0:1): SKEYID state generated Mar 7 16:14:29.183 GMT: ISAKMP (0:1): processing vendor id payload Mar 7 16:14:29.183 GMT: ISAKMP (0:1): speaking to another IOS box! Mar 7 16:14:29.187 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Old State = IKE_I_MM4 New State = IKE_I_MM4 Highlighted line 1 shows Tokyo sending its Diffie-Hellman public value and nonce value to Osaka. In highlighted line 2, the state changes to IKE_I_MM3, indicating that the third message in the IKE exchange has been sent. A response is now received from Osaka (highlighted line 3). Highlighted line 4 shows that the state has now changed to IKE_I_MM4, indicating that this response was the fourth message in the main mode exchange. Tokyo now begins to process the packet received from Osaka, beginning with the KE (Key Exchange) and NONCE payloads in highlighted lines 5 and 6. These payloads contain Osaka's Diffie-Hellman public value and nonce value. Note also the vendor ID payload shown in highlighted lines 8 and 9. As you can see, the vendor ID indicates that this message is from another Cisco IOS router. In highlighted line 7, the message SKEYID state generated is displayed. This indicates that Tokyo has generated keying material (session keys SKEYID_d, SKEYID_e, and SKEY_a) used for deriving IPSec keys, and encrypting and authenticating remaining main mode and quick mode ISAKMP messages. IKE peer authentication now begins with Tokyo and Osaka exchanging main mode messages five and six, as shown in Example 8-28. Example 8-28. Exchange of ISAKMP Messages Five and Six
Mar 7 16:14:29.187 GMT: ISAKMP (1): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
Mar 7 16:14:29.187 GMT: ISAKMP (1): Total payload length: 12
Mar 7 16:14:29.187 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH
Mar 7 16:14:29.187 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4 New State = IKE_I_MM5
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM5 New State = UNKNOWN
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): processing ID payload. message ID = 0
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): processing HASH payload. message ID = 0
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): SA has been authenticated with 172.16.6.2
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL,
IKE_PROCESS_MAIN_MODE
Old State = UNKNOWN New State = UNKNOWN
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = UNKNOWN New State = IKE_P1_COMPLETE
In highlighted line 1, Tokyo sends an ISAKMP message to Osaka. This message contains ID and HASH payloads. The ID payload is used for identification, and the HASH payload is used for authentication. Then in highlighted line 2, the state changes to IKE_I_MM5, indicating that the fifth message in the IKE exchange has been sent. The response is received from Osaka in highlighted line 3. This is the sixth and final message in the IKE main mode exchange. Contained within the message from Osaka are again ID and HASH payloads. These payloads are processed in highlighted lines 4 and 5. Osaka is then authenticated by Tokyo in highlighted line 6. In highlighted line 7, the state changes to IKE_P1_COMPLETE, indicating that main mode (phase 1) has been completed. To verify that phase 1 has been successfully negotiated, use the show crypto isakmp sa command, as demonstrated in Example 8-29. Example 8-29. Main Mode Successfully NegotiatedTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# In highlighted line 1, you can see that the IKE SA has been successfully negotiated between Tokyo (172.16.5.1) and Osaka (172.16.6.2). Note that the state QM_IDLE indicates that the IKE SA has been successfully negotiated and that quick mode is in a latent state. Table 8-4 shows the different states that you might see when using this command.
NOTE When troubleshooting IKE, it may be necessary to clear the IKE and IPSec SAs. To do this, use the clear crypto isakmp and clear crypto ipsec sa commands. IKE main mode can fail for a number of reasons. These reasons fall into one of the following five summarized categories:
These IKE phase 1 negotiation failures are discussed in the following few sections. Note that if there is a NAT device in the path between the initiator and the responder, it is also possible for this to cause IKE negotiation failure. See the section entitled "NAT Device Blocks IPSec Traffic" for more details. IKE Negotiation Is Not InitiatedIf IKE negotiation is not initiated (as indicated by a lack of appropriate output from the debug crypto isakmp commandsee Example 8-25), this can indicate a number of problems, including the following:
These issues are discussed in the sections that follow. Routing Issue Exists on the InitiatorIf packets are not being routed out of the interface to which the crypto map is applied, IKE main mode negotiation will not be triggered. Check that the router initiating the tunnel has a route to the peer router and to the destination address specified in the crypto access list. Also make sure that the route's next-hop is out of the interface with the crypto map applied to it. Use the show ip route command to verify the initiator's routing table, as shown in Example 8-30. Example 8-30. Routing Table on Tokyo
Tokyo#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, 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.16.0.0/24 is subnetted, 1 subnets
C 172.16.5.0 is directly connected, Serial4/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0/0
Tokyo#
As you can see, there is not a route to the peer (172.16.6.2) nor to the address specified in the crypto map (in this example, 10.2.2.0/24). In this example, a default route is added to provide IP reachability to both, as shown in Example 8-31. Example 8-31. Default Route Is Added for Peer ReachabilityTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#ip route 0.0.0.0 0.0.0.0 172.16.5.5 Tokyo(config)#exit Tokyo# Once the default route has been added, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command (see Example 8-32). Example 8-32. IKE Main Mode Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# As you can see, IKE main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE). Crypto Map Is Applied to the Wrong Interface or Is Not Applied at AllIf the crypto map is not applied to the correct interfaces or is not applied at all, IKE main mode negotiation will not be initiated. Crypto maps should be applied to the external (outbound) interface on the router. In Figure 8-14, the crypto map should be applied to interface serial 4/0 on Tokyo. Use the show crypto map tag crypto_map_name command to verify proper crypto map placement, as demonstrated in Example 8-33. Example 8-33. Verifying Proper Crypto Map PlacementTokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.6.2 Extended IP access list 101 access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Current peer: 172.16.6.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ mjlnet, } Interfaces using crypto map mjlnetmap: FastEthernet0/0 Tokyo# Highlighted line 1 shows that crypto map mjlnetmap is applied to interface FastEthernet 0/0. It is not going to work there. In Example 8-34, the crypto map is removed from interface FastEthernet 0/0 and applied to interface serial 4/0. In highlighted lines 1 and 2, crypto map mjlnetmap is removed from interface FastEthernet 0/0 and, in highlighted lines 3 and 4, it is applied to interface serial 4/0. Example 8-34. Removal of the Crypto Map from One Interface and Applying to Another InterfaceTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#interface fastethernet 0/0 Tokyo(config-if)#no crypto map mjlnetmap Tokyo(config-if)#exit Tokyo(config)# Tokyo(config)#interface serial 4/0 Tokyo(config-if)#crypto map mjlnetmap Tokyo(config-if)#end Tokyo# Once the crypto map has been applied to the correct interface, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-35. Example 8-35. IKE Main Mode Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# Example 8-36 shows that main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE). Crypto Access List Is MisconfiguredIf the crypto access list is misconfigured, IKE negotiation may not be initiated. To verify the crypto access list associated with a crypto map, use the show crypto map tag crypto_map_name, as shown in Example 8-36. Example 8-36. Verify the Access List Associated with the Crypto MapTokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.6.2 Extended IP access list 101 access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 Current peer: 172.16.6.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial4/0 Tokyo# Highlighted line 1 shows that extended IP access list 101 is associated with crypto map mjlnetmap. The access list itself is shown in highlighted line 2. At first glance, the access list looks fine, but on closer examination (and with reference to Figure 8-14), you will notice that the source and destination addresses are the wrong way round. The source address and mask should be 10.1.1.0 and 0.0.0.255, and the destination address and mask should be 10.2.2.0 and 0.0.0.255. The crypto access list is then reconfigured in Example 8-37. Example 8-37. Reconfiguration of the Crypto Access ListTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#no access-list 101 Tokyo(config)#access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Tokyo(config)#exit Tokyo# User traffic is now matched by the crypto access list, and the IKE main mode is successfully negotiated between Tokyo and Osaka. This is verified using the show crypto isakmp sa command, as shown in Example 8-38. Example 8-38. ISAKMP SA Has Been Successfully NegotiatedTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# The highlighted line indicates that an IKE main mode has been successfully negotiated between Tokyo (172.16.5.1) and Osaka (172.16.6.2), and quick mode is idle (QM_IDLE). Peer's IP Address Is Misconfigured or the Router Has Not Generated RSA Keys, Authenticated the CA, and Obtained a CertificateIf either the crypto isakmp key key address peer_address or the set peer peer_address commands are misconfigured then IKE phase 1 negotiation may not be initiated. Also, if certificates are being used and the router has not generated RSA keys, authenticated the CA, and obtained a certificate, IKE phase 1 negotiation may not be initiated. Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-39. Example 8-39. IPSec Peer's Address Is MisconfiguredTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 10 13:10:29.522 GMT: ISAKMP: received ke message (1/1) Mar 10 13:10:29.522 GMT: ISAKMP: local port 500, remote port 500 Mar 10 13:10:29.526 GMT: ISAKMP (0:1): No Cert or pre-shared address key. Mar 10 13:10:29.526 GMT: ISAKMP (0:1): Can not start Main mode Mar 10 13:10:29.526 GMT: ISAKMP (0:1): Can not start aggressive mode. Mar 10 13:10:29.526 GMT: ISAKMP (0:1): purging SA., sa=6327990C, delme=6327990C Mar 10 13:10:29.526 GMT: ISAKMP (0:1): purging node 1168904210 Tokyo# Highlighted line 1 shows that Tokyo is unable to find a preshared key corresponding to the crypto map-specified peer address. In highlighted lines 2 and 3, you can see that Tokyo is unable to initiate either main or aggressive mode without a corresponding preshared key. The peer address specified in the crypto map is then verified using the show crypto map tag crypto_map_name command, as demonstrated in Example 8-40. Example 8-40. Crypto Map Specified Peer AddressTokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.6.2 Extended IP access list 101 access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Current peer: 172.16.6.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial4/0 Tokyo# The highlighted line indicates that the peer address specified in crypto map mjlnetmap is 172.16.6.2. This address is correctly configured. The preshared key is then checked using the show crypto isakmp key command, as demonstrated in Example 8-41. Example 8-41. No Corresponding Preshared KeyTokyo#show crypto isakmp key Hostname/Address Preshared Key 172.16.5.2 cisco Tokyo# The highlighted line shows that there is no preshared key corresponding to peer 172.16.6.2 (the peer address specified in crypto map mjlnetmap). In fact, the address specified in Example 8-41 (172.16.5.2) is misconfiguredit should be 172.16.6.2. In Example 8-42, the misconfigured preshared key is removed, and a preshared key corresponding to peer 172.16.6.2 (Osaka) is added. Example 8-42. Adding a Preshared Key for OsakaTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#no crypto isakmp key cisco address 172.16.5.2 Tokyo(config)#crypto isakmp key cisco address 172.16.6.2 Tokyo(config)#exit Tokyo# Once the preshared key has been added for Osaka, IKE phase 1 is successfully negotiated with between Tokyo and Osaka, as shown in Example 8-43. Example 8-43. IKE Phase 1 Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# Example 8-43 shows the IKE phase 1 negotiation has completed successfully, and quick mode is in an idle state. As previously mentioned, if you are using certificates, check that the router has generated an RSA key pair, authenticated the CA, and obtained its certificate. Use the show crypto key mypubkey rsa and show crypto ca certificates commands to verify this. For more details see the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" earlier in this chapter. ISAKMP Is DisabledIf ISAKMP has been disabled on the router, then IKE negotiation will not be initiated. Note that ISAKMP is enabled by default on Cisco routers. You can use either the debug crypto isakmp or show crypto isakmp sa commands to verify whether ISAKMP is disabled. Example 8-44 shows the output of the debug crypto isakmp command when ISAKMP is disabled. Example 8-44. ISAKMP Is DisabledTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 10 11:21:28.203 GMT: ISAKMP: received ke message (1/1) Mar 10 11:21:28.203 GMT: ISAKMP: can't initiate when turned off! Mar 10 11:21:28.203 GMT: ISAKMP: local port 500, remote port 500 Mar 10 11:21:28.207 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM Old State = IKE_READY New State = IKE_I_MM1 Tokyo# The highlighted line clearly indicates that ISAKMP is disabled. To further verify this, use the show crypto isakmp sa command as demonstrated in Example 8-45. Example 8-45. ISAKMP Is Disabled on the RouterTokyo#show crypto isakmp sa ISAKMP is turned off Tokyo# As you can see, ISAKMP is disabled on the router. ISAKMP is then re-enabled in Example 8-46. Example 8-46. ISAKMP Is Re-enabled on the RouterTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto isakmp enable Tokyo(config)#exit Tokyo# The highlighted line indicates that ISAKMP is re-enabled. IKE negotiation now negotiates successfully. This is verified in Example 8-47 using the show crypto isakmp sa command. Example 8-47. IKE Negotiates SuccessfullyTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# As you can see, IKE phase 1 has successfully negotiated, and quick mode is in an idle state (QM_IDLE). Initiator Sends ISAKMP Messages, but They Are Not Received by the ResponderIf ISAKMP messages are being sent by the initiator, but are not received by the responder (as verified using the debug crypto isakmp command), this can indicate a number of problems, including the following:
These issues are detailed in the sections that follow. IP Connectivity Has Failed Between the IPSec PeersUse the ping command to verify IP connectivity between the initiator and the responder. If ping fails, you should begin to troubleshoot IP routing between the two peers. Remember, however, that ping only verifies reachability for ICMP Echo Request and Response messages. Responder's IP Address Is Incorrectly Configured on the InitiatorIf the responder's IP address is incorrectly configured on the initiator, IKE negotiation will fail. Use the show crypto isakmp key and show crypto map tag crypto_map_name to verify that the peer address is correctly configured, as demonstrated in Example 8-48. Example 8-48. Verifying the Peer's IP AddressTokyo#show crypto isakmp key Hostname/Address Preshared Key 172.16.4.2 cisco Tokyo# Tokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.4.2 Extended IP access list 101 access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Current peer: 172.16.4.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial4/0 Tokyo# Highlighted lines 1 and 2 show that the peer's IP address is configured as 172.16.4.2. Unfortunately, it should be configured as 172.16.6.2. The peer IP address is then reconfigured as shown in Example 8-49. Example 8-49. Reconfiguration of the Peer IP Address (in the Crypto Map)Tokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#no crypto isakmp key cisco address 172.16.4.2 Tokyo(config)#crypto isakmp key cisco address 172.16.6.2 Tokyo(config)# Tokyo(config)#crypto map mjlnetmap 10 Tokyo(config-crypto-map)#no set peer 172.16.4.2 Tokyo(config-crypto-map)#set peer 172.16.6.2 Tokyo(config-crypto-map)#end Tokyo# In highlighted lines 1 to 4, the peer's address is reconfigured as 172.16.6.2. Once the peer IP address has been reconfigured, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-50. Example 8-50. IKE Main Mode Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# The highlighted line indicates that IKE main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE). ISAKMP Is Blocked by an Access List or FirewallIf an access list or firewalls do not permit UDP port 500 (ISAKMP), IKE negotiation will fail. In this scenario, Tokyo is initiating IKE negotiation to Osaka. Example 8-51 shows the output of the debug crypto isakmp command when Tokyo initiates IKE negotiation with Osaka. Example 8-51. IKE Negotiation FailsTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 10 10:21:55.963 GMT: ISAKMP (0:1): purging SA., sa=62C26CC0, delme=62C26CC0 Mar 10 10:21:56.367 GMT: ISAKMP: received ke message (1/1) Mar 10 10:21:56.367 GMT: ISAKMP: local port 500, remote port 500 Mar 10 10:21:56.367 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM Old State = IKE_READY New State = IKE_I_MM1 Mar 10 10:21:56.367 GMT: ISAKMP (0:1): beginning Main Mode exchange Mar 10 10:21:56.367 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE Mar 10 10:22:06.367 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE Mar 10 10:22:06.367 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1 Mar 10 10:22:06.367 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE Mar 10 10:22:06.367 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE Tokyo# Highlighted line 1 shows that IKE main mode negotiation is about to begin, and then in highlighted line 2, Tokyo sends the first packet in the exchange. In highlighted lines 3 and 4, Tokyo retransmits the packet. Tokyo is sending ISAKMP messages to Osaka, but no response is received. This might indicate the presence of an access list in the path from Tokyo to Osaka. When Osaka is checked using the show ip interface [interface_name] command, an access list is found on its external interface (serial 2/0), as shown in Example 8-52. Note that only the relevant portion of the output is shown. Example 8-52. Access List Is Found on the External Interface of OsakaOsaka#show ip interface serial 2/0 Serial2/0 is up, line protocol is up Internet address is 172.16.6.2/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.10 Outgoing access list is not set Inbound access list is 102 Proxy ARP is enabled Security level is default Split horizon is enabled The contents of the access list are then verified using the show ip access-lists [access-list_number] command. Example 8-53 shows the output of the show ip access-lists command on Osaka. Example 8-53. Access List 102 Blocks ISAKMP
Osaka#show ip access-lists 102
Extended IP access list 102
permit icmp any any
permit eigrp any any
permit pim any any
permit esp any any
permit ahp any any
permit tcp any any
permit udp any any eq domain
permit udp any any eq ntp
permit udp any any eq snmp
permit udp any any eq snmptrap
permit udp any any eq tftp
permit udp any any eq tacacs
Osaka#
As you can see, access list 102 is not configured to specifically permit ISAKMP traffic, so it is blocked by the implicit deny any at the end of the access list. You could either add a line to the access list to permit ISAKMP traffic (access-list access-list-number permit udp source source-wildcard destination destination-wildcard eq isakmp) or remove the access list entirely, if it is not necessary. In this case, the access list is deemed unnecessary, so in Example 8-54, it is removed from the interface serial 2/0. Example 8-54. Access List Is RemovedOsaka#conf t Enter configuration commands, one per line. End with CNTL/Z. Osaka(config)#interface serial 2/0 Osaka(config-if)#no ip access-group 102 in Osaka(config-if)#end Osaka# IKE negotiation now succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-55. Example 8-55. IKE Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# As you can see, IKE phase 1 has been successfully negotiated, and quick mode is in an idle state. Responder Does Not Have a Preshared Key, Certificate, or Route to the InitiatorIf the responder does not have a preshared key for the initiator, does not have a certificate, or does not have a route back to the initiator, IKE phase 1 negotiations will fail. Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-56. Example 8-56. Responder Has No Preshared Key for the InitiatorOsaka#debug crypto isakmp Crypto ISAKMP debugging is on *May 13 16:57:07.283 GMT: ISAKMP (0:2): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_READY New State = IKE_R_MM1 *May 13 16:57:07.283 GMT: ISAKMP (0:2): processing SA payload. message ID = 0 *May 13 16:57:07.283 GMT: ISAKMP (0:2): No pre-shared key with 172.16.5.1! *May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 10 policy *May 13 16:57:07.283 GMT: ISAKMP: encryption DES-CBC *May 13 16:57:07.283 GMT: ISAKMP: hash MD5 *May 13 16:57:07.283 GMT: ISAKMP: default group 1 *May 13 16:57:07.283 GMT: ISAKMP: auth pre-share *May 13 16:57:07.283 GMT: ISAKMP: life type in seconds *May 13 16:57:07.283 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Preshared authentication offered but does not match policy! *May 13 16:57:07.283 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 65535 policy *May 13 16:57:07.283 GMT: ISAKMP: encryption DES-CBC *May 13 16:57:07.283 GMT: ISAKMP: hash MD5 *May 13 16:57:07.283 GMT: ISAKMP: default group 1 *May 13 16:57:07.283 GMT: ISAKMP: auth pre-share *May 13 16:57:07.283 GMT: ISAKMP: life type in seconds *May 13 16:57:07.283 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 *May 13 16:57:07.283 GMT: ISAKMP (0:2): Hash algorithm offered does not match policy! *May 13 16:57:07.287 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0 *May 13 16:57:07.287 GMT: ISAKMP (0:2): no offers accepted! *May 13 16:57:07.287 GMT: ISAKMP (0:2): phase 1 SA not acceptable! *May 13 16:57:07.287 GMT: ISAKMP (0:2): incrementing error counter on sa: In highlighted line 1, the IKE state changes from IKE_READY to IKE_R_MM1. Osaka has received the first message in the main mode exchange from router Tokyo. Note the R in the output hereit indicates that Osaka is the responder. Osaka then begins to process the SA payload (highlighted line 2), but in highlighted line 3, it reports that it does not have a preshared key for the initiator. Osaka continues to process the SA payload in the following lines, but in highlighted line 4, the IKE state changes back to IKE_READY, indicating that phase 1 negotiation has failed. The reason for the failure was, of course, indicated in highlighted line 3. Osaka does not have a preshared key for Tokyo. Osaka's configuration is then examined using the show running-config command as demonstrated in Example 8-57. Note that only the relevant portion of the output is shown. Example 8-57. Osaka's ConfigurationOsaka#show running-config Building configuration... ! crypto isakmp policy 10 hash md5 authentication pre-share crypto isakmp key cisco address 172.16.4.1 ! As you can see, there is only one preshared key configured, and it is configured for peer 172.16.4.1. In fact, there is no such peerit should be 172.16.5.1 (Tokyo). The preshared key is then reconfigured, as shown in Example 8-58. Example 8-58. Reconfiguration of the Preshared KeyOsaka#conf t Enter configuration commands, one per line. End with CNTL/Z. Osaka(config)#no crypto isakmp key cisco address 172.16.4.1 Osaka(config)#crypto isakmp key cisco address 172.16.5.1 Osaka(config)#exit Osaka# The highlighted lines show where the preshared key is reconfigured. Once the preshared key has been reconfigured, IKE phase 1 negotiation is successful, as shown in Example 8-59. Example 8-59. IKE Phase 1 Negotiation SucceedsOsaka#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 9 0 Osaka# As you can see, IKE phase 1 negotiation has succeeded, and quick mode is in an idle state. If you are using certificates, check that the router has generated an RSA key pair, authenticated the CA, and obtained its certificate. Use the show crypto key mypubkey rsa and show crypto ca certificates commands to verify this. See the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" on page 677. Finally, ensure that the responder has a route back to the initiator using the show ip route command. If it cannot send ISAKMP messages to the initiator, IKE phase 1 negotiation will fail. IKE Policy Mismatch ExistsIf IKE policy parameters are mismatched between IPSec peer routers, IKE phase 1 negotiation will fail. Use the debug crypto isakmp command to troubleshoot this issue. Example 8-60 shows the output of the debug crypto isakmp command when IKE phase 1 negotiation fails. Example 8-60. IKE Main Mode Negotiation FailsTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 10 21:23:18.775 GMT: ISAKMP: received ke message (1/1) Mar 10 21:23:18.775 GMT: ISAKMP: local port 500, remote port 500 Mar 10 21:23:18.775 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM Old State = IKE_READY New State = IKE_I_MM1 Mar 10 21:23:18.775 GMT: ISAKMP (0:1): beginning Main Mode exchange Mar 10 21:23:18.775 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE Mar 10 21:23:28.775 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE Mar 10 21:23:28.775 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1 Mar 10 21:23:28.775 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE Mar 10 21:23:28.775 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE Tokyo# Highlighted line 1 shows that main mode negotiation is about to begin between the Tokyo and Osaka. The first packet in the IKE main mode negotiation sequence is sent by Tokyo in highlighted line 2. Then in highlighted lines 3 and 4, Tokyo retransmits the packet. There is no response from Osaka. The debug crypto isakmp command is then used on Osaka to examine IKE negotiation from its perspective, as demonstrated in Example 8-61. Example 8-61. IKE Main Mode Negotiation Failure Seen on OsakaOsaka#debug crypto isakmp Crypto ISAKMP debugging is on Osaka# 00:08:57: ISAKMP (0:0): received packet from 172.16.5.1 (N) NEW SA 00:08:57: ISAKMP: local port 500, remote port 500 00:09:37: ISAKMP (0:3): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_READY New State = IKE_R_MM1 00:09:37: ISAKMP (0:3): processing SA payload. message ID = 0 00:09:37: ISAKMP (0:3): found peer pre-shared key matching 172.16.5.1 00:09:37: ISAKMP (0:3): Checking ISAKMP transform 1 against priority 10 policy 00:09:37: ISAKMP: encryption DES-CBC 00:09:37: ISAKMP: hash SHA 00:09:37: ISAKMP: default group 1 00:09:37: ISAKMP: auth pre-share 00:09:37: ISAKMP: life type in seconds 00:09:37: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 00:09:37: ISAKMP (0:3): Hash algorithm offered does not match policy! 00:09:37: ISAKMP (0:3): atts are not acceptable. Next payload is 0 Highlighted line 1 shows that an ISAKMP packet has been received from Tokyo (172.16.5.1). Then in highlighted line 2, Osaka reports that it is processing the ISAKMP message SA payload. Contained within the SA payload is the IKE policy proposal from router Tokyo. Osaka begins to try to find a match for the IKE proposals in highlighted line 3, when it attempts to match the first proposal from Tokyo against its own highest priority (lowest numbered) IKE policy. In this case, the highest priority IKE policy configured on Osaka is priority 10. From highlighted lines 4 to 9, the attributes of Tokyo's first proposal are listed, and then in highlighted line 10, Osaka reports that the hash algorithm offered in Tokyo's proposal (SHA) does not match its own hash algorithm. Because the hash algorithms do not match, Osaka reports that the IKE policy proposal attributes sent by Tokyo are not acceptable (highlighted line 11). Note that Osaka also reports in highlighted line 11 that Next payload is 0. This is significant because it indicates that there is no next payload, meaning that Tokyo has sent only one IKE policy proposal. Refer to Table 8-1 for more information about ISAKMP message payload types. Osaka now tries to match the proposal from Tokyo against its default policy in Example 8-62. Example 8-62. Osaka Tries to Match the Proposal from Tokyo Against Its Default Policy00:09:37: ISAKMP (0:3): Checking ISAKMP transform 1 against priority 65535 policy 00:09:37: ISAKMP: encryption DES-CBC 00:09:37: ISAKMP: hash SHA 00:09:37: ISAKMP: default group 1 00:09:37: ISAKMP: auth pre-share 00:09:37: ISAKMP: life type in seconds 00:09:37: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 00:09:37: ISAKMP (0:3): Authentication method offered does not match policy! 00:09:37: ISAKMP (0:3): atts are not acceptable. Next payload is 0 00:09:37: ISAKMP (0:3): no offers accepted! 00:09:37: ISAKMP (0:3): phase 1 SA not acceptable! 00:09:37: ISAKMP (0:3): incrementing error counter on sa: construct_fail_ag_init 00:09:37: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Old State = IKE_R_MM1 New State = IKE_R_MM1 00:09:37: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR Old State = IKE_R_MM1 New State = IKE_READY 00:09:47: ISAKMP (0:0): received packet from 172.16.5.1 (N) NEW SA 00:09:47: ISAKMP: local port 500, remote port 500 Osaka# In highlighted line 1, Osaka reports that it is trying to match this proposal against its own default policy (number 65535). Then in highlighted line 2, Osaka reports that the authentication method does not match, and in highlighted line 3, it reports that the attributes do not match its own policy and are, therefore, not acceptable. Finally, in highlighted lines 4 and 5, Osaka reports that no offers (policy proposals) have been accepted and that the phase 1 IKE SA is not acceptable. Tokyo's proposal has been rejected because its hash algorithm does not match that of the policy configured on Osaka (Example 8-62, highlighted line 11). Additionally, the authentication method does not match that of the default policy (highlighted line 2). You know that the hash algorithm proposed by Tokyo was SHA (Example 8-62, highlighted line 5), so you can probably guess the hash algorithm configured on Osaka. The ISAKMP (IKE) policies on Osaka are then examined using the show crypto isakmp policy command, as shown in Example 8-63. Example 8-63. IKE Policies on OsakaOsaka#show crypto isakmp policy Protection suite of priority 10 encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Message Digest 5 authentication method: Pre-Shared Key Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit Osaka# Highlighted line 1 shows the protection suite of IKE policy 10. As you can see, the hash algorithm configured on Osaka is MD5. This is the cause of the failureTokyo is configured to use SHA, and Osaka is configured to use MD5. Note also the default policy in highlighted line 2. The authentication method of the default policy is RSA signatures. The authentication method proposed by Tokyo was preshared keys (highlighted line 7, Example 8-62), so no match there either. The hash algorithm must be changed on either Tokyo or Osaka. In this case, it is changed on Tokyo. This is shown in Example 8-64. Example 8-64. Hash Algorithm Changed to MD5 on TokyoTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto isakmp policy 10 Tokyo(config-isakmp)#hash md5 Tokyo(config-isakmp)#end Tokyo# As the highlighted line indicates, the hash algorithm on Tokyo is changed to MD5. Once the hash algorithm has been changed, the IKE SA is successfully negotiated between Tokyo and Osaka. This is verified using the show crypto isakmp sa command, as shown in Example 8-65. Example 8-65. IKE SA Is Successfully NegotiatedTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# It is also a good idea to ensure that the ISAKMP lifetime (configured in crypto isakmp policy number) is equal on the initiator and the responder. If the lifetime is not equal then the policy may be rejected (depending on the version of IOS and whether the initiator's lifetime is greater or less than that of the responder). IKE Authentication FailsIf IKE authentication does not succeed, phase 1 negotiation will fail. Reasons for authentication failure depend on whether you are using preshared keys or digital certificates. These reasons are discussed in the two sections that follow. Authentication Fails with Preshared KeysIf preshared keys are mismatched between IPSec peers, authentication will not succeed, and IKE negotiation will fail. In IKE main mode, authentication occurs when the IPSec peers exchange the fifth and sixth messages in the IKE negotiation sequence. Use the debug crypto isakmp command to troubleshoot this issue. Example 8-66 shows the output of the debug crypto isakmp command when an authentication failure occurs. Note that only the relevant portion of the output is shown. Example 8-66. IKE Preshared Key Authentication FailureTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 11 11:17:55.555 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH Mar 11 11:17:55.555 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE Old State = IKE_I_MM4 New State = IKE_I_MM5 Mar 11 11:17:55.627 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH Mar 11 11:17:55.627 GMT: ISAKMP: reserved not zero on NOTIFY payload! Mar 11 11:17:55.627 GMT: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 172.16.6.2 failed its sanity check or is malformed Mar 11 11:17:55.627 GMT: ISAKMP (0:1): incrementing error counter on sa: reset_retransmission Mar 11 11:17:56.627 GMT: ISAKMP (0:1): retransmitting phase 1 MM_KEY_EXCH Mar 11 11:17:56.627 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1 Tokyo# In highlighted line 1, Tokyo (the initiator) sends a packet to Osaka (the responder). Highlighted line 2 shows that the state has changed from IKE_I_MM4 to IKE_I_MM5, indicating that the packet sent in highlighted line 1 was the fifth in the sequence. Then in highlighted line 3, a packet is received from Osaka (172.16.6.2). Highlighted lines 4 and 5 indicate that this packet contains an unauthenticated Notify message. Notify messages are used to send error conditions (or status data). This might mean that the shared key has been misconfigured on either Tokyo or Osaka. Osaka confirms that the shared key is properly configured as cisco. Tokyo's configuration is then examined using the show running-config command in Example 8-67. Note that only the relevant portion of the output is shown. Example 8-67. Tokyo ConfigurationTokyo#show running-config Building configuration... ! crypto isakmp policy 10 hash md5 authentication pre-share crypto isakmp key disco address 172.16.6.2 ! Highlighted line 1 shows that the preshared key is configured as disco on Tokyo. In this example, it should be cisco, of course. The preshared key is, therefore, corrected on Tokyo, as shown in Example 8-68. Example 8-68. Correction of Misconfigured Preshared Key on TokyoTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#no crypto isakmp key disco address 172.16.6.2 Tokyo(config)#crypto isakmp key cisco address 172.16.6.2 Tokyo(config)#exit Tokyo# When IKE negotiation is reinitiated by user traffic, it succeeds. This is verified using the show crypto isakmp sa command. The output of the show crypto isakmp sa command shows that IKE (phase 1) negotiation has been successful, as seen in Example 8-69. Example 8-69. IKE Phase 1 Negotiation Is SuccessfulTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# As you can see, IKE phase 1 negotiation has succeeded, and quick mode negotiation is in an idle state. Authentication Fails When Using CertificatesIf you are using digital signatures (certificates) for authentication and a certificate has expired, or the time on a router is outside of the validity dates for a certificate, then IKE authentication will fail. Use debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-70. Note that only the relevant portion of the output is shown. Example 8-70. IKE Negotiation FailsTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# 03:05:18: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH 03:05:18: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE Old State = IKE_I_MM4 New State = IKE_I_MM5 03:05:19: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH 03:05:19: ISAKMP (0:1): Notify has no hash. Rejected. 03:05:19: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY Old State = IKE_I_MM5 New State = IKE_I_MM5 Tokyo# In highlighted line 1, Tokyo sends a packet to Osaka (172.16.6.2). Highlighted line 2 shows that the state has changed to IKE_I_MM5, indicating that the message sent in highlighted line 1 was the fifth in the IKE phase 1 exchange. Remember that the fifth and sixth messages in phase 1 are used for peer authentication. Then in highlighted line 3, a packet is received from Osaka. This is a Notify message, as shown in highlighted line 4. This indicates an error condition, and IKE negotiation now terminates. An error has occurred, but there is not much information as to the cause. The next step is to examine the exchange from the point of view of Osaka. Again, use the debug crypto isakmp command to examine the IKE negotiation exchange (when it restarts) as shown in Example 8-71. Example 8-71. IKE Negotiation Failure on OsakaOsaka#debug crypto isakmp Crypto ISAKMP debugging is on Osaka# 05:13:10: ISAKMP (0:3): received packet from 172.16.5.1 (R) MM_KEY_EXCH 05:13:10: ISAKMP (0:3): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Old State = IKE_R_MM4 New State = IKE_R_MM5 05:13:10: ISAKMP (0:3): processing ID payload. message ID = 0 05:13:10: ISAKMP (0:3): processing CERT payload. message ID = 0 05:13:10: ISAKMP (0:3): processing a CT_X509_SIGNATURE cert 05:13:10: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 172.16.5.1 is bad: certificate invalid 05:13:10: ISKAMP: growing send buffer from 1024 to 3072 05:13:10: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Old State = IKE_R_MM5 New State = IKE_R_MM5 05:13:10: ISAKMP (0:3): sending packet to 172.16.5.1 (R) MM_KEY_EXCH 05:13:10: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR Old State = IKE_R_MM5 New State = IKE_R_MM4 Osaka# A packet is received from Tokyo (172.16.5.1) in highlighted line 1, and in highlighted line 2, the router reports that the new state is IKE_R_MM5. Again, this indicates that the message received in highlighted line 1 is the fifth message in the phase 1 negotiation exchange. Osaka now begins to process the payloads contained within the packet. In highlighted lines 3 and 4, Osaka processes the ID and CERT (certificate) payloads. Then in highlighted lines 5, 6, and 7, Osaka processes the X.509 certificate itself and reports that the certificate is invalid. Finally, Osaka sends a packet to Tokyo is highlighted line 7. This is the Notify message used to inform Tokyo of the error. The certificate is invalid. There are a number of possibilities, three of which are as follows:
Note that other reasons why a certificate might be invalid are listed at the end of this section. The next step is to check the clock on Osaka and the validity period of the certificate. To check the clock, use the show clock command, as shown in Example 8-72. Example 8-72. Osaka's ClockOsaka#show clock .14:18:58.579 UTC Sun Mar 14 2005 Osaka# As you can see, the clock on Osaka is set to 14 March 2005. In fact, it should be set to 14 March 2003. In Example 8-73 Tokyo's certificate is examined using the show crypto ca certificates command. Note that only the relevant portion of the output is shown. Example 8-73. Tokyo's CertificateTokyo#show crypto ca certificates Certificate Status: Available Certificate Serial Number: 614A2572000000000006 Key Usage: General Purpose Issuer: CN = markacs OU = markacs O = markacs L = london ST = london C = UK EA =<16> mark@markacs.com Subject Name Contains: Name: Tokyo.mjlnet.com IP Address: 172.16.5.1 Serial Number: 0168FEB5 CRL Distribution Point: http://markacs/CertEnroll/markacs.crl Validity Date: start date: 09:04:23 UTC Mar 13 2003 end date: 09:14:23 UTC Mar 13 2004 Associated Identity: mjlnetca As you can see, Tokyo's certificate is valid from 13 March 2003 to 13 March 2004. Osaka's clock doesn't fall within these dates, and therefore IKE authentication fails. Osaka's clock is then modified to the correct time using the clock set command (Example 8-74). If your routers do not have hardware clocks, every time they are rebooted, their clocks will be resetthis is a good reason to use NTP instead. Example 8-74. Modifying Osaka's Clock
Tokyo#clock set 21:01:00 14 march 2003
Once Osaka's clock has been modified, IKE negotiation succeeds between Tokyo and Osaka. This is verified using the show crypto isakmp sa command in Example 8-75. Example 8-75. IKE Negotiation SucceedsTokyo#show crypto isakmp sa dst src state conn-id slot 172.16.6.2 172.16.5.1 QM_IDLE 1 0 Tokyo# Example 8-76 shows that the phase 1 has been successfully negotiated, and quick mode is in an idle state. Other common issues with certificate authentication include the following:
IKE Phase 2 (Quick Mode) Negotiation FailsOnce IKE phase 1 is complete, the two peers then negotiate IPSec SAs in phase 2 (quick mode). If IKE phase 2 negotiation fails, no IPSec SAs will be established. Figure 8-16 illustrates phase 2 negotiation. Figure 8-16. IKE Phase 2 Negotiation Before beginning to troubleshoot IKE phase 2, it is worth examining a successful IKE phase 2 negotiation sequence. Examples 8-76 to 8-78 show successful IKE phase 2 (quick mode) negotiation. Note that only the relevant portion of the output is shown. Example 8-76. Quick Mode Negotiation BeginsTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 7 16:14:29.191 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of 216243713 Mar 7 16:14:29.195 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE Mar 7 16:14:29.195 GMT: ISAKMP (0:1): Node -216243713, Input = IKE_MESG_INTERNAL, IKE_INIT_QM Old State = IKE_QM_READY New State = IKE_QM_I_QM1 Highlighted line 1 shows that quick mode is about to begin. Also note the message ID (M-ID) of the first quick mode message that Tokyo is about to send. Notice that it is nonzero (in fact, random), unlike those of messages in main mode. The first message in the quick mode exchange is sent by Tokyo in highlighted line 2. This message contains, among other things, IPSec proposals. In highlighted line 3, you can see the state is now IKE_QM_I_QM1, indicating that the first message in the quick mode exchange has been sent. Osaka responds. Example 8-77. Received Second Quick Mode Message (from Responder)Mar 7 16:14:29.195 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE Mar 7 16:14:29.447 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE Mar 7 16:14:29.451 GMT: ISAKMP (0:1): processing HASH payload. message ID = -216243713 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): processing SA payload. message ID = -216243713 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): Checking IPSec proposal 1 Mar 7 16:14:29.451 GMT: ISAKMP: transform 1, ESP_DES Mar 7 16:14:29.451 GMT: ISAKMP: attributes in transform: Mar 7 16:14:29.451 GMT: ISAKMP: encaps is 1 Mar 7 16:14:29.451 GMT: ISAKMP: SA life type in seconds Mar 7 16:14:29.451 GMT: ISAKMP: SA life duration (basic) of 3600 Mar 7 16:14:29.451 GMT: ISAKMP: SA life type in kilobytes Mar 7 16:14:29.451 GMT: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 Mar 7 16:14:29.451 GMT: ISAKMP: authenticator is HMAC-MD5 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): atts are acceptable. Mar 7 16:14:29.451 GMT: ISAKMP (0:1): processing NONCE payload. message ID = -216243713 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): processing ID payload. message ID = -216243713 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): processing ID payload. message ID = -216243713 Mar 7 16:14:29.451 GMT: ISAKMP (0:1): Creating IPSec SAs Mar 7 16:14:29.451 GMT: inbound SA from 172.16.6.2 to 172.16.5.1 (proxy 10.2.2.0 to 10.1.1.0) Mar 7 16:14:29.451 GMT: has spi 0x7E5A7D6C and conn_id 2000 and flags 4 Mar 7 16:14:29.451 GMT: lifetime of 3600 seconds Mar 7 16:14:29.451 GMT: lifetime of 4608000 kilobytes Mar 7 16:14:29.451 GMT: outbound SA from 172.16.5.1 to 172.16.6.2 (proxy 10.1.1.0 to 10.2.2.0 ) Mar 7 16:14:29.455 GMT: has spi -565122577 and conn_id 2001 and flags 4 Mar 7 16:14:29.455 GMT: lifetime of 3600 seconds Mar 7 16:14:29.455 GMT: lifetime of 4608000 kilobytes A reply is then received from Osaka in highlighted line 1. This message contains a number of payloads, including a HASH payload, an SA payload, a NONCE payload, and ID payload. The HASH payload (highlighted line 2) serves to authenticate the message, as well as being a liveliness indicator. The SA payload (highlighted line 3) contains IPSec proposals. In lines 4 to 12, the SA is processed, and in line 13, it is accepted. The NONCE payload contains a random number and serves to prevent replay attacks, as well as being used to generate fresh keying material. This payload is processed by Tokyo in highlighted line 14. The ID payloads are used to carry (proxy) identities. These are also called traffic selectors and correspond to the crypto access list configured on Tokyo. The ID payloads are processed in highlighted lines 15 and 16. Once the message from Osaka has been completely processed, Tokyo begins to create the IPSec SAs (highlighted line 17). In highlighted line 18, the inbound IPSec SA is created. Note that the SA is created between IP addresses 172.16.6.2 (Osaka) and 172.16.5.1 (Tokyo) for proxy identities 10.2.2.0 (the source address in the crypto access list on Osaka) and 10.1.1.0 (the destination address in the crypto access list on Osaka). The Security Parameters Index (SPI) and lifetimes (seconds and kilobytes) of the SA are shown in highlighted lines 19 to 21. The SPI acts as a unique identifier for the SA. Then in highlighted line 22, the outbound IPSec SA is created. This SA is created between 172.16.5.1 (Tokyo) and 172.16.6.2 (Osaka), with proxy identities 10.1.1.0 (the source address in the crypto map on Tokyo) and 10.2.2.0 (the destination address in the crypto map on Tokyo). Again, the SPI and lifetimes associated with this SA are shown in highlighted lines 23 to 25. Tokyo responds in Example 8-78. Example 8-78. Sending Third and Last Message in Quick Mode ExchangeMar 7 16:14:29.455 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE Mar 7 16:14:29.455 GMT: ISAKMP (0:1): deleting node -216243713 error FALSE reason "" Mar 7 16:14:29.455 GMT: ISAKMP (0:1): Node -216243713, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE Tokyo# The last message in the quick mode exchange is sent by Tokyo to Osaka in highlighted line 1. This message again serves as an acknowledgement and as an indicator of liveliness. Finally, in highlighted line 2, the message IKE_QM_PHASE2_COMPLETE is displayed. This shows that phase 2 (quick mode) is complete. Once IKE quick mode is complete, you can verify that IPSec SAs have been successfully negotiated using the show crypto ipsec sa command. Example 8-79 shows the output of the show crypto ipsec sa command. Example 8-79. IPSec SAsTokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetmap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) current_peer: 172.16.6.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #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.: 172.16.5.1, remote crypto endpt.: 172.16.6.2 path mtu 1500, media mtu 1500 current outbound spi: 6DEA8F23 inbound esp sas: spi: 0x249582ED(613778157) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3314) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x6DEA8F23(1844088611) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3314) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Tokyo# Highlighted lines 1 and 2 show that crypto map mjlnetmap is applied to interface serial 4/0 and that the local IP address is 172.16.5.1. The local and remote (proxy) identities are shown in highlighted lines 3 and 4. These correspond to the addresses, masks, protocols, and ports specified in the crypto access list. Highlighted line 5 shows the IPSec peer address (172.16.6.2, Osaka). The local and remote endpoints (Tokyo and Osaka) are shown in highlighted line 6. The path and local media MTUs are shown in highlighted line 7. In highlighted line 8, you can see the Security Parameter Index (SPI) associated with the outbound IPSec SA. Note that an SA is uniquely identified by an SPI, an IP destination address, and a security protocol (ESP or AH) identifier. Inbound ESP SAs associated with interface serial 4/0 are shown starting from highlighted line 9 (there is only one). The transform set, tunnel mode, connection ID, flow ID, crypto map, SA lifetime, initialization vector (IV) size, and replay detection support settings associated with the SA are also shown. Note that one connection ID is associated with each SA. An initialization vector is used to initialize the first round of cipher block chaining (CBC). CBC is used in conjunction with DES or AES encryption in cipher-block chaining mode. Highlighted lines 10 and 11 show that there are currently no AH and IP Payload Compression Protocol (PCP) SAs. PCP provides network-layer compression and can be used in conjunction with IPSec. PCP requires that a SA be set up between IPSec peers. Note that the two compression algorithms that are defined for use with PCP are Lempel-Ziv-Stac (LZS) and Deflate. On Cisco routers, only LZS can be used. In highlighted line 12, you can see the outbound ESP SA associated with interface serial 4/0. IKE phase 2 (quick mode) negotiations can fail for a number of reasons, including the following:
These possible causes of IKE phase 2 negotiation failure are discussed in the following sections. It is worth noting that if there is a NAT device in the path between the initiator and the responder, it is also possible for this to cause IKE negotiation failure. See the section entitled "NAT Device Blocks IPSec Traffic" later in this chapter for more details. NOTE It might be necessary to clear the existing ISAKMP and IPSec SAs when troubleshooting issues contained in this section. Use the clear crypto isakmp command to clear existing ISAKMP SAs. Use the clear crypto sa command to clear existing IPSec SAs. IPSec Transform Set Mismatch Exists Between PeersIf IPSec transform sets are mismatched between IPSec peers, IKE phase 2 (quick mode) will fail. Use the debug crypto isakmp command to troubleshoot this issue, as demonstrated in Example 8-80. Note that only the relevant portion of the output is shown. Example 8-80. IKE Quick Mode Fails with Transform Set MismatchTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Old State = UNKNOWN New State = IKE_P1_COMPLETE Mar 11 20:31:24.094 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of 1110884980 Mar 11 20:31:24.094 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE Mar 11 20:31:24.094 GMT: ISAKMP (0:1): Node -1110884980, Input = IKE_MESG_INTERNAL, IKE_INIT_QM Old State = IKE_QM_READY New State = IKE_QM_I_QM1 Mar 11 20:31:24.094 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE Mar 11 20:31:24.194 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE Mar 11 20:31:24.194 GMT: ISAKMP (0:1): processing HASH payload. message ID = 1998102984 Mar 11 20:31:24.194 GMT: ISAKMP (0:1): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 4050089439, message ID = 1998102984, sa = 62C239EC Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting spi 4050089439 message ID = - 1110884980 Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting node -1110884980 error TRUE reason "delete_larval" Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting node 1998102984 error FALSE reason "informational (in) state 1" Mar 11 20:31:24.194 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE Tokyo# In highlighted line 1, you can see that the state has changed to IKE_P1_COMPLETE1. This indicates that IKE phase 1 negotiation has been completed successfully. Highlighted line 2 indicates that IKE quick mode is about to begin, and in highlighted line 3, Tokyo sends the first quick mode packet to Osaka (172.16.6.2). Then in highlighted line 4, the second quick mode packet is received from Osaka. Highlighted line 5 shows that this packet contains a Notify message indicating that the proposal (transform set) has been rejected. This means that the transform set on Osaka doesn't match that on Tokyo. To examine the IPSec transform set, use the show crypto ipsec transform-set command. Example 8-81 shows the output of the show crypto ipsec transform-set command on Tokyo and Osaka. Example 8-81. IPSec Transform Set on Tokyo and OsakaTokyo#show crypto ipsec transform-set Transform set mjlnet: {esp-des esp-sha-hmac } will negotiate = {Tunnel, }, Tokyo# ________________________________________________________________ Osaka#show crypto ipsec transform-set Transform set mjlnet: {esp-des esp-md5-hmac } will negotiate = {Tunnel, }, Osaka# If you compare the two transform sets, you can see that the ESP hash algorithm on Tokyo is SHA-HMAC, and on Osaka it is MD5-HMAC: clearly a mismatch. The solution is to reconfigure either Tokyo or Osaka so that they are both the same. Example 8-82 shows the reconfiguration of the hash algorithm on Tokyo. Example 8-82. Reconfiguration of the Key Hashing Algorithm on TokyoTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto ipsec transform-set mjlnet esp-des esp-md5-hmac Tokyo(config)#exit Tokyo# In Example 8-82, the transform set is modified as appropriate. Once the hash algorithm has been modified, the IPSec SAs are successfully negotiated. Successful negotiation of the IPSec SAs is verified using the show crypto ipsec sa command in Example 8-83. Example 8-83. IPSec SAs Are Successfully NegotiatedTokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetmap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) current_peer: 172.16.6.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 6, #recv errors 0 local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2 path mtu 1500, media mtu 1500 current outbound spi: 7FED973B inbound esp sas: spi: 0xF5707082(4117786754) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607998/3540) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x7FED973B(2146277179) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3540) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Tokyo# Highlighted line 1 shows the local and remote tunnel endpoints (Tokyo and Osaka, respectively). In highlighted lines 2 and 3, you can see that inbound and outbound IPSec SAs have been successfully negotiated. Note that you should also ensure that the set peer {hostname | ip_address} command is correctly configured within the crypto map on the responder. If this is incorrectly specified, then phase 2 (quick mode) negotiation will fail. Peers' Crypto Access Lists Are AsymmetricIf crypto access lists on the IPSec peers are asymmetric (not mirror images of each other), problems may ensue. One result of asymmetrical access lists is that quick mode (and IPSec SAs) will not be successfully negotiated. Another is that one peer will be able to initiate successful quick mode, but the other will not. Use the debug crypto isakmp command to troubleshoot this issue. In this scenario, Tokyo initiates IKE negotiation. In Example 8-84, Tokyo initiates quick mode negotiation. Note that only the relevant portion of the output is shown. Example 8-84. Tokyo Initiates Quick Mode NegotiationTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Mar 11 22:45:57.855 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of -324913471 Mar 11 22:45:57.855 GMT: ISAKMP. (0:1): sending packet to 172.16.6.2 (I) QM_IDLE Mar 11 22:45:57.855 GMT: ISAKMP (0:1): Node -324913471, Input = IKE_MESG_INTERNAL, IKE_INIT_QM Old State = IKE_QM_READY New State = IKE_QM_I_QM1 Mar 11 22:45:57.855 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE Mar 11 22:45:57.959 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE Mar 11 22:45:57.959 GMT: ISAKMP (0:1): processing HASH payload. message ID = 1298728624 Mar 11 22:45:57.959 GMT: ISAKMP (0:1): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 3852444734, message ID = 1298728624, sa = 632F8428 Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting spi 3852444734 message ID = -324913471 Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting node -324913471 error TRUE reason "delete_larval" Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting node 1298728624 error FALSE reason "informational (in) state 1" Mar 11 22:45:57.959 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE Tokyo# Highlighted line 1 shows that quick mode negotiation is about to begin. The first packet in the quick mode exchange is sent by Tokyo to Osaka (172.16.6.2) in highlighted line 2. This packet contains the IPSec proposal (transform set). A packet is then received from Osaka in highlighted line 3. Highlighted line 4 shows that the packet from Osaka contained a Notify message indicating that the IPSec proposal was rejected. Failure of quick mode initiated by Tokyo to negotiate IPSec SAs is verified using the show crypto ipsec sa command in Example 8-85. Highlighted line 1 in Example 8-85 shows that the local and remote endpoints are Tokyo (172.16.5.1) and Osaka (172.16.6.2), respectively. Below that you can see that no SAs have been negotiated. Example 8-85. No IPSec SAs Negotiated When Quick Mode Is Initiated by TokyoTokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetmap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0) remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0) current_peer: 172.16.6.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 10, #recv errors 0 local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2 path mtu 1500, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: Tokyo# When quick mode is initiated from Osaka, however, quick mode successfully negotiates IPSec SAs. This is verified using the show crypto ipsec sa command in Example 8-86. Example 8-86. IPSec SAs Are Negotiated When Quick Mode Is Initiated by OsakaOsaka#show crypto ipsec sa interface: Serial2/0 Crypto map tag: mjlnetmap, local addr. 172.16.6.2 local ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) current_peer: 172.16.5.1 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #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.: 172.16.6.2, remote crypto endpt.: 172.16.5.1 path mtu 1500, media mtu 1500 current outbound spi: B75DB07A inbound esp sas: spi: 0xB0FC85E9(2969339369) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3530) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xB75DB07A(3076370554) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3530) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Osaka# Highlighted line 1 shows that the local and remote endpoints are Osaka and Tokyo, respectively. In highlighted lines 2 and 3, you can see that inbound and outbound ESP SAs have been negotiated. A look at the crypto access lists on Tokyo and Osaka reveals that they are asymmetric, as indicated in Example 8-87. Example 8-87. Crypto Access Lists on Tokyo and OsakaTokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.6.2 Extended IP access list 101 access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 Current peer: 172.16.6.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial4/0 Tokyo# ________________________________________________________________ Osaka#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.5.1 Extended IP access list 101 access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 Current peer: 172.16.5.1 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial2/0 Osaka# You can see in highlighted lines 1 and 2 that the two crypto access lists are asymmetric. On Tokyo, the source address and mask are 10.1.0.0 and 0.0.255.255, and the destination address and mask are 10.2.0.0 0.0.255.255. On Osaka, the source address and mask are 10.2.2.0 and 0.0.0.255, and the destination address and mask are 10.1.1.0 and 0.0.0.255. The reason that Tokyo could not initiate successful quick mode negotiation with Osaka is that its crypto access list encompasses addresses outside the range defined by the crypto access list on Osaka. Osaka, therefore, rejected Tokyo's IPSec SA proposal. Osaka, on the other hand, was able to initiate successful quick mode negotiation because its crypto access list encompasses addresses that fall within the range specified by Tokyo's crypto access list. In Example 8-88, Tokyo's crypto access list is modified to be symmetrical (a mirror image of) Osaka's crypto access list. Example 8-88. Tokyo's Crypto Access List Is ModifiedTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#no access-list 101 Tokyo(config)#access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Tokyo(config)#exit Tokyo# Once Tokyo's crypto access list has been modified, Tokyo is able to initiate successful quick mode negotiation with Osaka. This is verified using the show crypto ipsec sa command in Example 8-89. Example 8-89. Tokyo Can Now Initiate Successful Quick Mode NegotiationTokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetmap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) current_peer: 172.16.6.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #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.: 172.16.5.1, remote crypto endpt.: 172.16.6.2 path mtu 1500, media mtu 1500 current outbound spi: 72D2164E inbound esp sas: spi: 0x91A4BE0F(2443492879) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607998/3577) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x72D2164E(1926370894) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607999/3577) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Tokyo# Highlighted line 1 shows the local and remote endpoints are Tokyo and Osaka, respectively. In highlighted lines 2 and 3, you can see that inbound and outbound ESP SAs have been negotiated with Osaka. The issue is now resolved. CAUTION It is inadvisable to use the any keyword in crypto access lists because it can cause the router to drop control protocol traffic, such as routing protocol traffic, because it is not encrypted. If you do decide to use the any keyword, make sure that you use appropriate deny keywords to specify that control protocol traffic should not be encrypted. DN-Based Crypto Map Prevents Quick Mode Negotiation with a PeerIf you are using Distinguished Name (DN) based crypto maps, you must be careful to ensure that they are correctly configured to permit the intended peers. If a peer is not permitted by the DN-based crypto map, quick mode negotiation will fail. In this example, network administrators in Osaka are complaining that they are unable to initiate an IPSec tunnel to Tokyo. Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-90. Note that only the relevant portion of the output is shown. Example 8-90. IPSec Tunnel Between Tokyo and Osaka FailsTokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE 00:43:29: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE 00:43:29: ISAKMP (0:1): processing HASH payload. message ID = 531797542 00:43:29: ISAKMP (0:1): processing SA payload. message ID = 531797542 00:43:29: ISAKMP (0:1): Checking IPSec proposal 1 00:43:29: ISAKMP: transform 1, ESP_DES 00:43:29: ISAKMP: attributes in transform: 00:43:29: ISAKMP: encaps is 1 00:43:29: ISAKMP: SA life type in seconds 00:43:29: ISAKMP: SA life duration (basic) of 3600 00:43:29: ISAKMP: SA life type in kilobytes 00:43:29: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 00:43:29: ISAKMP: authenticator is HMAC-MD5 00:43:29: %CRYPTO-4-IKE_QUICKMODE_BAD_CERT: encrypted connection attempted with a peer without the configured certificate attributes 00:43:29: ISAKMP (0:1): atts not acceptable. Next payload is 0 00:43:29: ISAKMP (0:1): phase 2 SA not acceptable! 00:43:29: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE 00:43:29: ISAKMP (0:1): purging node 1379210405 00:43:29: ISAKMP (0:1): Unknown Input for node 531797542: state = IKE_QM_I_QM1, major = In highlighted line 1, phase 1 has been completed, and quick mode is about to begin. The first quick mode packet is received from Osaka (172.16.6.2) in highlighted line 2. The payload of the packet is then processed, but in highlighted line 3, Tokyo reports encrypted connection attempted with a peer without the configured certificate attributes. Finally, in highlighted lines 4 and 5, Tokyo reports that the attributes in the packet sent by Osaka are not acceptable and that quick mode negotiation has failed. The error message in highlighted line 3 is the key to solving this issue. It indicates that the peer is not permitted by the DN-based crypto map. Use the show crypto map tag crypto_map_name command to examine the crypto map, as shown in Example 8-91. Example 8-91. Crypto Map Shows an Identity ListTokyo#show crypto map tag mjlnetmap Crypto Map "mjlnetmap" 10 ipsec-isakmp Peer = 172.16.6.2 Extended IP access list 101 access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 Current peer: 172.16.6.2 Allowed identity list = from-mjlnet Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={mjlnet, } Interfaces using crypto map mjlnetmap: Serial4/0 Tokyo# As you can see, the identity list from-mjlnet is configured in crypto map mjlnetmap. To examine the identity list, use the show crypto identity identity_list_name command as shown in Example 8-92. Example 8-92. Identity List Permits Only Niigata.mjlnet.comTokyo#show crypto identity from-mjlnet crypto identity from-mjlnet: fqdn Niigata.mjlnet.com Tokyo# The highlighted line indicates that the identity list permits only the FQDN Niigata.mjlnet.com. So only this peer will be able to establish a tunnel with Tokyo. To allow Osaka to establish an IPSec tunnel with Tokyo, the FQDN for Osaka is added to the identity list, as shown in Example 8-93. Example 8-93. Osaka Is Added to the Identity ListTokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto identity from-mjlnet Tokyo(config-crypto-identity)#fqdn Osaka.mjlnet.com Tokyo(config-crypto-identity)#end Tokyo# Once the identity list has been modified, an IPSec tunnel from Osaka is established. This is verified using the show crypto ipsec sa command, as demonstrated in Example 8-94. Example 8-94. IPSec Tunnel Is Established to OsakaTokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetmap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0) current_peer: 172.16.6.2:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 26, #pkts encrypt: 26, #pkts digest 26 #pkts decaps: 26, #pkts decrypt: 26, #pkts verify 26 #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.5.1, remote crypto endpt.: 172.16.6.2 path mtu 1500, media mtu 1500 current outbound spi: 61E5F098 inbound esp sas: spi: 0x1FE27FD5(534937557) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607992/2334) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x61E5F098(1642459288) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap sa timing: remaining key lifetime (k/sec): (4607996/2334) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Tokyo# Highlighted line 1 shows the local and remote (172.16.6.2, Osaka) tunnel endpoints. In highlighted lines 2 and 3, you can see that both inbound and outbound ESP SAs have been established. User Traffic Does Not Successfully Cross the IPSec TunnelOnce the IKE phase 1 and phase 2 have been successfully negotiated and the IPSec tunnel has been established, user traffic should be able to cross the tunnel between the IPSec peers, as illustrated in Figure 8-17. Figure 8-17. User Traffic Crosses the Tunnel Between the IPSec Peers If traffic is sent over the IPSec tunnel but does not arrive at the remote site, there are a number of possible causes, including the following:
These issues are discussed in the following two sections. Note that you should also verify that the responder has a route to the destination address specified in its crypto access list using the show ip access-lists and show ip route commands. Access List or Firewall Is Blocking AH or ESPIf an access list or firewall is blocking AH (IP protocol 51) or ESP (IP protocol 50) then IPSec tunnel traffic will be dropped. In this example, IPSec tunnel traffic sent from Tokyo is not reaching end hosts at the Osaka site. An examination of the Osaka router using the show ip interface command in Example 8-95 reveals the presence of an access list on the external (Internet) interface. Example 8-95. Access List on Interface Serial 2/0Osaka#show ip interface serial 2/0 Serial2/0 is up, line protocol is up Internet address is 172.16.6.2/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.10 Outgoing access list is not set Inbound access list is 105 Proxy ARP is enabled Security level is default Split horizon is enabled In highlighted line 1, you can see that access list 105 is configured on interface serial 2/0. Access list 105 is then examined using the show ip access-lists command, as shown in Example 8-96. Example 8-96. Access List 105Osaka#show ip access-lists 105 Extended IP access list 105 deny esp any any (20 matches) permit ip any any (134 matches) Osaka# As you can see, the (slightly contrived) access list blocks ESP traffic. Because IPSec tunnel traffic in this example is using an ESP, it is being dropped by Osaka. Access list 105 is then removed from the interface in Example 8-97. Example 8-97. Removal of Access List 105 from the InterfaceOsaka#conf t Enter configuration commands, one per line. End with CNTL/Z. Osaka(config)#interface serial 2/0 Osaka(config-if)#no ip access-group 105 in Osaka(config-if)#end Osaka# Once the access list has been removed, user traffic crosses the IPSec tunnel from Tokyo to end hosts at the Osaka site. It is also worth noting that if an access list is configured on a tunnel endpoint, such as Osaka in this example, you must be sure to allow both AH/ESP and the source and destination addresses and ports in the original IP packet. This means that if a Telnet packet is sent from host 10.1.1.1 at the Tokyo site to host 10.2.2.1 at the Osaka site, an access list on the external interface of Osaka should permit both AH/ESP (depending on the security protocol), and source/destination address 10.1.1.1/10.2.2.1, plus TCP port 23 (Telnet). This is necessary because all IPSec tunnel packets are tested against an external interface access list twicewhen they first arrive in the encapsulated form, and then after the AH/ESP headers have been removed. NAT Device Blocks IPSec TrafficIf there is NAT device in the path between the IPSec peers, it might cause IKE negotiation to fail or IPSec traffic to be dropped if the IPSec peers are not configured to support NAT. NOTE To allow IPSec traffic to successfully traverse a NAT device, you can use ESP authentication rather than AH (NAT devices modify the outer IP header, which causes the AH integrity check to fail), use tunnel mode instead of transport mode, use the IPSec NAT transparency feature, or use an IPSec-aware NAT device. A fuller discussion is beyond the scope of this chapter, but more details can be found at the following URLs: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c03.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541de.html  |
|
|
construct_fail_ag_init
*May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM1 New State = IKE_R_MM1
*May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR