I want to take a deep dive on IOS IKEv2 debugging so we can understand how the exchanges work. The logs in this post are from a basic site-to-site (S2S) FlexVPN using Pre-Shared-Keys (PSKs). Before we dive in, let's cover the types of messages used by IKEv2 for session establishment. These messages include:
IKEv2 only has two initial phases of negotiation to establish a secure channel of communication:
IKE_SA_INIT = Used to initiate & negotiate the cryptographic algorithms, exchange nonces, and do Diffie-Hellman exchange. A pair of messages between the peers occur. These messages are both unauthenticated and unencrypted.
IKE_AUTH = Used to exchange identities, authenticate peers, and also establish the first Child Security Association (SA). At this point these exchanges are encrypted, but not authenticated.
Note: Once the IKE_SA_INIT and IKE_AUTH messages are successfully completed Phase 1 is considered complete – Encrypted & Authenticated.
CREATE_CHILD_SA = These exchanges are used to create new Child SAs and also to rekey both IKE SAs and Child SAs. It is important to know that the first Child SA gets created during the IKE_AUTH exchange.
INFORMATIONAL = These exchanges are used to send notificationss/errors. One example includes deleting an SA.
Ok, so now that we have a better understanding let's dive in. Note for this debug series all debugs were captured from the initiator side. To see more about the lab config see: S2S FlexVPN with Smart Defaults
Debugging the IKE_SA_INIT exchange: Note that when the device receives a packet that matches traffic to be protected it will start the process of generating the first IKE_SA_INIT (in this example ping traffic was generated for the remote side):
A few things to pay attention to include: Our initiator computes the DH public key, followed by creation of the IKE_SA_INIT message that includes a list of transforms (9) the client is configured to support in its IKE proposal. You can see in the header that the packet also contains the initiator's Security Parameter Index (SPI). SPI = is a locally significant identifier that enables the respective client to select the appropriate SA for which received packets will be processed. Note the SPI identifier is changed upon IKE SA re-key.
Additional IKE_SA_INIT debugs:
You can see the payload contents includes the transforms the initiator supports, the generated DH key (identified via KE = key exchange) that was generated earlier, Vendor ID (VID), and NOTIFY which in this case is used for NAT detection.
Debugging the IKE_SA_INIT Exchange Response from the remote side:
In a smooth exchange the responder's IKE_SA_INIT response is received which contains its response and agreed upon crypto settings.
This next debug shows the remaining steps to complete the IKE_SA_INIT. Upon completion of these exchanges, all other packets are encrypted. Remember during the IKE_SA_INIT negotiation packets are unencrypted and the peers are unauthenticated.
Remaining steps are for the initiator to generate its own DH secret key, and the SKEYSEED (this is used to derive all cryptographic keys for the IKE SA).
Debugging the IKE_AUTH Exchange:
Remember the IKE_AUTH exchanges are used to exchange identities, authenticate each other, and to establish the first CHILD_SA.
Debugging the IKE_AUTH start:
You can see the initiator has started generating the IKE_AUTH message.
The packet is being built for encryption:
The next debug shows two important things I want to point out that tells us which source/destination traffic should be encrypted.
TSi = Traffic Selection Initiator (source address/es)
TSr = Traffic Selector-responder (destination address/es)
Debug showing IKEv2 IKE_AUTH exchange being requested from our initiator, followed by our initiator receiving the IKE_AUTH exchange RESPONSE from our peer. Note that ENCR means that our payloads are now encrypted:
Now the initiator processes & verifies the IKE_AUTH response:
Now that peers have been authenticated, and the IKE_AUTH exchange is complete the initiator begins creating our IPsec SA:
Note that for IPsec we will also have a unique SPI:
Debugging CREATE_CHILD_SA exchange:
We will now force a rekey by manually lowering our lifetime, which will generate a CREATE_CHILD_SA exchange:
Here is the CREATE_CHILD_SA exchange RESPONSE from our peer that shows our initiator processing/verifying the response to activate our new IKE SA:
Debugging INFORMATIONAL exchange:
Lastly, remember that INFORMATIONAL exchanges are used to send notifications/event errors. Brief INFORMATIONAL debug from manually deleting our IKE SA:
We have now successfully debugged IOS IKEv2 exchanges for a S2S FlexVPN. Cheers!