In the previous article, we configured a site-to-site VPN tunnel between the Cisco ASA and a Cisco IOS router. We successfully brought up the tunnel and protected hosts were able to communicate with each other over the tunnel. In this article, we will explore the “behind-the-scenes” of the establishment of this tunnel.

Our network diagram remains the same, as shown below. Get your geeky hats on because this will be a bit technical (although I’d try to keep it as simple as possible).

Before we look at the debugs, let’s do a quick recap of the IKE phases. IKE has two phases: phase 1 and phase 2. Under phase 1, there are two possible modes: Main Mode (MM) which uses a total of 6 messages; and Aggressive Mode (AM) which uses a total of 3 messages. MM is more secure than AM as we will consider later. Phase 2 has one mode called Quick mode which uses three messages.

IKE Phase 1

In a later article, we will configure the tunnel to use AM, but for now, the peers will use MM to establish the IKE phase 1 SA. According to RFC 2409 which details IKE: “Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: The first two messages negotiate policy; the next two exchange Diffie-Hellman public values and ancillary data (e.g. nonces) necessary for the exchange; and the last two messages authenticate the Diffie-Hellman Exchange.

From the description above, notice that the identities of the peers are protected. This is what makes MM more secured than AM. The IDs are carried in the last two messages (in the 3rd exchange) and these messages are protected by the secret keying material generated in the 2nd exchange. Note that when we talk about 6 messages in three exchanges, we mean a “back and forth” communication; the initiator sends the first message, the responder sends the second message; the imitator sends the 3rd message and so on.

When using Pre-shared keys for authentication, the exchanges can be represented diagrammatically as shown below:

* The diagram above is an edited version of the phases as shown in the RFC. The messages can be split up into three exchanges as shown on the left.

Let’s now proceed to the terminal. If you still have your VPN tunnels established, clear them using the following commands: clear crypto isakmp and clear crypto ipsecsa.

To see the debug output, we will debug ISAKMP packets using debug crypto ikev1<debug level>. I’d initiate a connection from the 192.168.20.200 host behind the IOS router to the 192.168.10.100 behind the ASA. This means that the IOS Router will be the INITIATOR and the ASA will be the RESPONDER. You can specify the debug level on the ASA from 1 to 255. This helps you specify the ‘intensity’ of the debug output, with 255 being the most intense.

I’d like to show you something at the start of the VPN tunnel formation, so I’d use 255 and then as we go on, I’d switch to a lower intensity.

Now, I’d initiate the ping packet. (192.168.20.200 is a Loopback on the router).

The output is pretty lengthy so I’d just copy some part which I’d like to focus on. The first packet that the ASA receives is shown below:

As you’d notice, this is in the form ‘HDR, SA‘ shown in main mode exchanges diagram above. The payload is “Security Association” and it contains two transforms (i.e. ISAKMP policies); it then goes ahead to specify the transforms. As you can see, the initiator sends ALL its ISAKMP policies in one SA to the responder. The policies are listed in the order in which we configured them according to priority. The responder then checks through the transforms in that order for a matching policy.

Now that we have seen the content of the first packet, I’d switched to a terser debug output. I’d clear the SAs again and we start afresh.

We can now view a more compact debug output.

The first highlighted portion shows that the ASA received a message from 10.0.0.2 (the IOS router). Looking at the content of the message, you can see that it begins with a header (HDR) and contains a Security Association (SA) with some vendor attributes. We have seen the entire contents of this packet above. The ASA checks through the transforms and as you can see, it finds an acceptable transform: Transform #1 in SA Proposal #1. A match exists (acceptable transform) when there are matching encryption, hash, authentication and Diffie-Hellman group values. For IKEv1, the remote transform must also specify a lower or equal lifetime value and in a case of inequality, the ASA will use the shorter lifetime.

The next message in the debug is the ASA’s reply as shown below.

This now completes the 1st exchange (SA Exchange). The next exchange is the Key Exchange and as shown next, the ASA receives a message from the router.

As you will notice in the first highlighted portion of this output, the message is in the form of “HDR, KE, N” where KE stands for Key Exchange payload and N stands for Nonce payload. The remaining two highlighted sections show NAT-Discovery messages. NAT Discovery helps to discover if a device is perform NAT in the VPN path.

We have now gotten to an important part. Keep in mind that the peers have not exchanged IDs up until this point. This is because we are using Main Mode which protects the identities of the peers. The ASA now has to generate the shared encryption key for the VPN peer. However, when using PSK authentication, the PSK and the DH session key are used to generate the shared encryption key to protect the tunnel. So the question is: how will the ASA match the correct tunnel group (which contains the pre-shared key) to its VPN peer if it doesn’t have the peer’s ID? The only way it can do that is by using the IP address (which it already knows, of course, from all the messages received so far). This is the reason why tunnel groups using PSK and Main mode must use IP addresses.

Once the keys are generated, the ASA now sends its own Key Exchange packet.

This completes the Key exchange process. A total of 4 messages have been sent so far. The remaining two messages are encrypted because they contain the identities of the peers.

The first highlighted portion is in the form “HDR*, ID, HASH“; the * means that the packet is protected. Also notice that with NAT-D, they have been able to detect that there is no NAT going on in the VPN tunnel path. In another article, we will see an example with NAT taking place.

The ASA replies the message, thus completing the 3rd exchange making a total of 6 messages for Main Mode.

This completes the IKE Phase 1 negotiation and I think we have stared at enough debug output for one article. In the next article, we will look at the debug output for IKE Phase 2 Quick Mode.

Summary

In this article, we have looked at the IKE phase 1 debug output for a site-to-site VPN tunnel between the ASA and a Cisco IOS Router. We have seen the six messages (in three exchanges) of the IKE Phase 1 Main Mode. Briefly, we also saw the NAT discovery feature by which the peers can detect if NAT is taking place anywhere in the VPN path. We will look at this further in the next part.

If you are really interested in VPNs on the ASA and want a deeper understanding, I suggest you read the RFC (if not the entire RFC, maybe some part of it) and also look at the debug output on level 255.

I hope you have found this article insightful and I look forward to the next one in the series.

Reference and helpful resource: