In the previous article, we began with the debug session of the site-to-site VPN tunnel between the Cisco ASA and a Cisco IOS router. We went through the main mode exchange for IKE phase 1 which includes six messages in three exchanges. In this article, we will continue with the debug session by moving on to IKE phase 2.

Our network diagram remains the same as shown below.

IKE Phase 2

IKE Phase 2 has one mode called the Quick mode which contains three messages. IKE Phase 2 is not a standalone exchange as this phase cannot take place without IKE phase 1 first taking place. According to a Cisco press article on IPsec, Quick mode “negotiates a shared IPsec policy, derives shared secret keying material used for the IPsec security algorithms, and establishes IPsec SAs“. Therefore, while the tunnel created by IKE phase 1 is a ‘management’ tunnel to protect further ISAKMP negotiations, the tunnel(s) created during IKE phase 2 protect the interesting traffic.

According to the RFC that documents IKE, the Quick mode exchanges can be represented as shown below:

We will go to the terminal now and pick up right where we stopped. As shown below, after the IKE Phase 1 was complete, the ASA receives a message from the initiator.

Notice the format of this first message: HDR*, HASH, SA, Ni, IDci, IDcr is as shown in the Quick mode exchange diagram above. You will also notice that the router sends the identities of the traffic it is willing to protect (i.e. remote IP Proxy subnet and Local IP Proxy subnet).

The content of this packet are encrypted and we will be able to see this encryption by taking a closer look at this first packet using a debug level of 255 as shown below.

As you can see from the snipped debug output above, the ASA received a packet from the router ( The only portion of the packet viewable before decryption is the ISAKMP header. The ASA goes ahead to decrypt this packet and as you will then notice, the entire content of the packet can be viewed ‘AFTER DECRYPTION’. The remaining portion of the packet is shown below:

The Security Association contains the IPsec transform set sent from the initiator (the router). Also notice that the ‘Identification’ payloads carry the identities of the traffic to be protected. In this case, the initiator is telling the ASA it is willing to protect traffic from to

Now that we have seen that packet in detail, let us switch back to a debug level of 9. At this point, the ASA has to scan through its crypto map looking for a match for the peer. The ACL configured for this peer must be the mirror of the one received from the peer. In our scenario, a match is found as shown below.

The ASA will also check for a matching locally configured transform set as the one sent by the peer. The transform set we configured on the ASA is as shown below:

This matches the transform set sent in the SA, therefore it is accepted as we can see in the debug output below.

The ASA is now ready to send the second packet of the Quick mode exchange. It prepares this packet similar to the first packet, and sends it to the peer.

As you can see, on the ASA (or the responder in general), the remote subnet is the protected subnet of the initiator and the local subnet is its own protected subnet.

To complete the Quick mode exchange, the ASA receives the third packet from the initiator as shown below.

At this point, IKE phase 2 is complete and if all went well, traffic should be passing through protected.

When we view the IPsec debugs, we also see the two unidirectional SAs that are created during IKE phase 2. First the inbound SA:

Then the outbound SA:


In this article, we have concluded the IKE negotiations by looking at the debug session for IKE phase 2. As we have seen, IKE phase 2 uses the Quick mode which contains three messages. If everything goes well, then your tunnel should be passing traffic fine after this point.

In the next article, we will be looking at Aggressive mode of IKE phase 1 and see the difference between this mode and Main mode.

For now, we will stop here and I hope you have found this article insightful. I look forward to the next article in this VPN series.

Reference and helpful resources: