In the last article, we began looking at RSA signatures as a method to authenticate VPN peers. To do that, we introduced another router into our network setup that acted as the Certificate Server. We were able to successfully authenticate and enrol with this IOS CA on both VPN peers i.e. the Cisco ASA and the Cisco IOS router. Our network setup is as shown below:

At the end of that article, however, we discovered that our VPN tunnel was not being set up when an interesting traffic wanted to pass through. Let’s refresh our memories about that issue; I will issue a ping from the router to the host behind the ASA and as shown below, the request fails.

Immediately after issuing the ping traffic, a look at the ISAKMP SAs shows that the exchange is stuck at the ‘Key Exchange’ phase.

After a while, we will notice that the SA gets deleted just like we saw in the last article.

So let’s find out where the issue is. We will turn on debugging on both the ASA and the router for this article.

I will initiate that ping traffic again from the router and we will first look at the debug output on the ASA.

As you can see from the output above, the first message is that the ASA (responder) receives from the router (initiator) is the 1st packet of the SA Exchange in IKE phase 1 Main Mode. We are already familiar with the contents of this packet. The ASA processes this packet and finds a matching (or acceptable) transform for ISAKMP as shown in the 2nd highlighted portion of that output.

Upon finding an acceptable transform, the ASA now prepares and sends its own reply to complete the SA Exchange.

The KE Exchange can now begin. The initiator sends the 3rd packet in the Main Mode Exchange while the responder sends the 4th packet.

Notice the CERT_REQ payload in the messages above? This is something we didn’t see when doing pre-shared key authentication. According to RFC 4945, “the Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs)“. In other words, our VPN peers are requesting for each other’s certificates. These certificates are sent in the 5th and 6th message of the Main Mode.

Continuing with our debugs, we see that the router sends the 5th message in the Main Mode exchange as shown below.

As you can see, the certificate is sent in this message – as contained in the CERT payload. Now notice what happens as shown in the 2nd highlighted portion of the debug output above: the ASA tries to find a tunnel group for this connection. It first tries to find a group using an ‘OU’ (organization unit) but it doesn’t find one; it then tries to match the connection using the IKE ID (which could be an IP address or a hostname) and this fails too. Finally, it tries to match the connection using the IP address and this succeeds as shown by the “Connection landed on tunnel_group” output.

We have now gotten to the moment of truth. The last message shown in the debug before an error occurred is “Unable to compare IKE ID against peer cert Subject Alt Name“. What does this mean? In simple terms, the ASA expects (by default) that the ID it received from the router should be the same as the Distinguished name (DN) in the router’s certificate. But the issue is, by default, the router uses its FQDN as its ID, not the distinguished name.

To see this happening, we will go to the router’s debug output and take a look at some part of it.

The output you see above is the router preparing to send the 5th message in the Main Mode exchange. As I said before, the router uses its FQDN as the ID and from above; we see that the FQDN is “”.

So how do we resolve this? There are two ways to resolve this and we will consider one of them now.

Option 1: On the router

The first option is to configure the router to send the certificate DN as its ID instead of FQDN. We do this by issuing the “crypto isakmp identity dn” command on the router.

Now, I will test the tunnel again while still debugging on the devices. Let’s look at that same point on the debug as before on the router.

Notice now that the router uses its DN as the ID, not its FQDN. If we go over to the ASA, we will see that there was no error and that IKE phase 1 completed just fine.

In fact, we will see that the ping actually succeeded. The result was lost in a lot of debug output.

Option 2: On the ASA

The 2nd option we have is to change a particular configuration on the ASA – the requirement to validate the peer’s ID against the peer’s certificate. This is done by changing the “peer-id-validate” settings under the tunnel group.

The default is “required”. We can change it either to “cert” or “nocheck”.

To test this, I will clear the current VPN connection; I will also remove the distinguished name ID configuration we made on the router.

Looking at the debug on the router, we will see that it has gone back to using its FQDN as the ID.

However, this does not stop the VPN from coming up. Taking a look at the ASA’s debug output, we see that it did not try to validate the peer’s ID using the certificate. You will also notice that the ASA sent the 6th message to complete the IKE phase 1 Main Mode Exchange.

Like before, the tunnel is formed as reflected in the success of the ping traffic.

We can take a look at the ISAKMP SA on the ASA and we will notice that the authentication method is “rsa”.


In this article, we have looked at the debug output for VPN using RSA signatures. In the midst of it, we discovered that the ASA tries to validate the peer’s ID using the peer’s certificate. However, the problem is that by default, the Cisco IOS will use its FQDN as its ID instead of the DN of the certificate. We then considered the two options for resolving this issue: configuring the router to use the certificate’s DN as its ID or configuring the ASA not to validate the peer’s ID with the peer’s certificate.

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

Reference and helpful resource: