In the last few articles, we configured a site-to-site VPN tunnel between the ASA and a Cisco router using the network diagram shown below.

We went on to look at the debug output for the set up of this tunnel. In one of the debug session articles, we saw the Main Mode exchange of IKE phase 1 which contains six messages in three exchanges: SA Exchange, Key Exchange, and ID and Authentication Data Exchange. However, we also discussed that there is another mode in IKE phase 1 which is the Aggressive mode which we will now consider in this article.

IKE Phase 1 Main Mode using PSK

Before we discuss Aggressive mode, let us revisit the constraint with using pre-shared keys for authentication with IKE Phase 1 Main Mode. During the Main Mode Exchange, peer identities are not exchanged until the tunnel is protected by the shared encryption key. This ensures that the identities of the peers are protected. However, it also introduces a challenge because to generate this encryption key, the PSK must be used. How will the peers know which PSK to use for the matching peer if identities have not been exchanged? The only way they can know is by using the peer’s IP address. This is why when using PSK authentication with Main mode, ASA tunnel groups can only be named with the IP address of the peer.

Let’s see this in practice by changing our tunnel group to a non-IP address name. We will then turn on debugging to see what happens.

Notice that the ASA gives a warning immediately that a tunnel group is configured that does not have an IP address as the name. It tells us that to use a non-IP address named tunnel group, we must be using digital certificates and/or aggressive mode on the peer. However, let’s go ahead and debug and generate traffic from to

As you can see, the Main Mode exchange failed after the third message just before the fourth message. The ASA could not find a valid tunnel group and it aborted. The error message we receive on the peer router is as shown below:

IKE Phase 1- Aggressive Mode

Now that we have considered the issue with Main Mode and PSKs in detail, let us consider an alternative – Aggressive Mode. According to RFC 2409 which details IKE, “Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange.

Aggressive mode therefore contains three messages in three exchanges. When using Pre-shared keys for authentication, the exchanges can be represented diagrammatically as shown below:

We will now configure the VPN tunnel to use Aggressive mode (AM). On the Cisco IOS router, we have to configure an ISAKMP profile which we will attach to the crypto map. We will use FQDN (hostname + domain name) to match the PSK to the correct peer. Since peer IDs are known beforehand in AM, we can specify the tunnel group name on the ASA as the FQDN of the router.

We will begin with the configuration on the Cisco IOS router.

First, I configured a domain name for the router. Then I created an ISAKMP profile called AGGRESSIVE. In the profile, I specified that AM should be initiated; the router should identify itself using its FQDN; and the router should check for the peer’s key in the default keyring. A crypto keyring is a store of pre-shared keys and RSA public keys. This means it will check the global key definitions for the peer (

The final piece of configuration to be done on the router is to attach the ISAKMP profile to the crypto map.

Let’s now move over to the ASA. We will create a tunnel group with a name that matches the FQDN of the router.

Our configuration is now complete on both devices and we can test the tunnel. I will initiate ping traffic from the host behind the router to the host behind the ASA.

Let’s look at the ISAKMP SA created on the ASA for this tunnel.

Notice that it now shows as “AM_ACTIVE” signifying Aggressive mode. There is no difference in the IPsec SA as aggressive mode is only applicable to IKE phase 1, as shown below.

Our aggressive mode works. However, I’d like to bring your attention to something at this point: the tunnel came up because we initiated traffic from the router side. If we were to initiate the traffic from the host behind the ASA, this tunnel will not come up. Let me show you this.

First, we will clear the VPN tunnel connection on both devices.

Then I initiate a ping connection from the host (simulated by a router).

As you can see, the connection fails. Why do you think this happens? Have a think about it, turn on debugging and try to resolve the issue. We will address this issue in our next article.


In this article, we have begun looking at the Aggressive mode of IKE phase 1 and how it allows more flexibility even when using PSK authentication because the identities of the peers are not protected from the beginning of the exchange. We also discovered from our configuration that while our tunnel will be brought up if traffic is initiated from one end (the router), it will not be built if traffic is initiated from the other end (the ASA).

In the next article, we will look at the debug output for Aggressive mode and also resolve the issue we pointed out in this article.

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

Reference and helpful resource: