The Trouble with IPsec VPNs, Part#3: IKE Phase 1 Success

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

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey: The results are in