I have surfaced again after a busy few weeks - and I can finally continue my description of IPsec VPN troubleshooting (sorry about the delay). This time I'll take a closer look at IKE Phase 1 (main mode) troubleshooting.
Before getting into an analysis of specific problems that can occur with IKE Phase 1, it's a good idea to use the debug crypto isakmp command to examine an example of successful IKE Phase 1 negotiation. This negotiation takes place between two IPsec VPN gateways called Tokyo and Osaka:
Crypto ISAKMP debugging is on
Tokyo#
Old State = IKE_READY New State = IKE_I_MM1 (LINE 1)
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) (LINE 2) MM_NO_STATE
Line 1 shows the message Old State = IKE_READY New State = IKE_I_MM1, which indicates that IKE negotiation has begun, and that the first ISAKMP message in the main mode exchange is about to be sent.
In line 2, main mode begins with Tokyo sending IKE SA proposals to Osaka (172.16.6.2, the responder). These proposals are configured on Tokyo using the crypto isakmp policy command.
Next, proposal acceptance is received from Osaka:
Mar 7 16:14:29.067 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) (LINE 1)
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 (LINE 2)
Mar 7 16:14:29.067 GMT: ISAKMP (0:1): processing SA payload. message ID = 0 (LINE 3)
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 (LINE 4)
Mar 7 16:14:29.067 GMT: ISAKMP: hash MD5 (LINE 5)
Mar 7 16:14:29.067 GMT: ISAKMP: default group 1 (LINE 6)
Mar 7 16:14:29.067 GMT: ISAKMP: auth pre-share (LINE 7)
Mar 7 16:14:29.067 GMT: ISAKMP: life type in seconds (LINE 8)
Mar 7 16:14:29.067 GMT: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 (LINE 9)
Mar 7 16:14:29.067 GMT: ISAKMP (0:1): atts are acceptable. Next payload is 0 (LINE 10)
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
Line 1 shows the message received from Osaka. This contains the accepted proposal (one out of those sent in Tokyo's initial message).
In line 2, you can see that the state has moved from IKE_I_MM1 to IKE_I_MM2, which indicates that this is the second message in the IKE exchange.
Tokyo begins to process the SA payload, which contains the accepted proposal, in line 3. Lines 4 to 9, you can see the accepted proposal itself. The proposal consists of DES encryption, the MD5 hash algorithm, preshared key authentication, and an SA lifetime.
Tokyo reports that these proposal attributes are acceptable (highlighted line 10).
Tokyo and Osaka are now ready to exchange Diffie-Hellman public values and nonces:
Mar 7 16:14:29.103 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) (LINE 1) 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 (LINE 2)
Mar 7 16:14:29.147 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) (LINE 3)
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 (LINE 4)
Mar 7 16:14:29.147 GMT: ISAKMP (0:1): processing KE payload. message ID = 0 (LINE 5)
Mar 7 16:14:29.183 GMT: ISAKMP (0:1): processing NONCE payload. message ID = 0 (LINE 6)
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 (LINE 7)
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
In line 1, Tokyo sends its Diffie-Hellman public value and nonce value to Osaka. In line 2, the state changes to IKE_I_MM3, indicating that the third message in the IKE exchange has been sent.
Then a response is received from Osaka as shown in line 3. Line 4 shows that the state has now changed to IKE_I_MM4, which indicates that this response was the fourth message in the main mode exchange.
Tokyo processes the packet received from Osaka, starting with the KE (Key Exchange) and NONCE payloads shown in lines 5 and 6. These payloads contain Osaka's Diffie-Hellman public value and nonce value.
In line 7, you can see the message ‘SKEYID state generated'. 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.
The final part of Main Mode negotiation now begins. This consists of IKE peer authentication (main mode messages 5 and 6):
Mar 7 16:14:29.187 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) (LINE 1) 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 (LINE 2)
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) (LINE 3)
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 (LINE 4)
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): processing HASH payload. message ID = 0 (LINE 5)
Mar 7 16:14:29.191 GMT: ISAKMP (0:1): SA has been authenticated with 172.16.6.2 (LINE 6)
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 (LINE 7)
Old State = UNKNOWN New State = IKE_P1_COMPLETE
Tokyo sends an ISAKMP message containing ID and HASH payloads to Osaka (highlighted line 1). The ID payload is used for identification, and the HASH payload is used for authentication.
Next, in highlighted line 2, the state changes to IKE_I_MM5, which indicates that the fifth message in the IKE main mode exchange has been sent.
The response is received from Osaka in highlighted line 3. This response contains ID and HASH payloads, and these payloads are processed in highlighted lines 4 and 5.
Tokyo authenticates Osaka in highlighted line 6.
Finally, in highlighted line 7, the state changes to IKE_P1_COMPLETE, indicating that main mode negotiation has been completed.
Now that you have seen successful main mode negotiation, you are in a great position to analyse the main mode failures that I will discuss next time.
Mark