Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

ovt Bronze

ISAKMP identity on cisco routers


Can anybody explain why shared key should be tied to source IP address (in

outer IP header), rather than to Identity on cisco routers if Main mode

is used and to Identity if Aggressive mode is used ???

For example, our peer router uses Identity = hostname ("")

and IP address to initiate IKE/IPSec tunnel in Main mode.

Router "Down" has config as follows:

hostname Down

ip domain-name

crypto isakmp policy 1

authentication pre-share

group 2

crypto isakmp key cisco address no-xauth ! key tied to IP !!!

crypto isakmp identity hostname



crypto ipsec transform-set trans1 esp-des esp-sha-hmac


crypto map s2s 10 ipsec-isakmp

set peer

set transform-set trans1

set identity QQQ ! only accept peers with Identities in QQQ identity list

match address 100



crypto identity QQQ


This config works. If I change "fqdn" to say "fqdn bla-bla-bla"

I see "IPSEC(validate_proposal): peer failed identity check",

"ISAKMP (0:9): atts not acceptable. Next payload is 0",

"%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at". (Phase 1 SA is established).

So far as I understood this means that peer's Identity was really "".

But shared secret is tied to IP address! If I change this to

"crypto isakmp key cisco hostname no-xauth" I see

"ISAKMP (0:10): No pre-shared key with!"

Can anybody explain this? IOS 12.2(11)T

Oleg Tipisov,



  • Other Security Subjects

Re: ISAKMP identity on cisco routers

This might be a useful resource to you: but you may need to dig into the rfc's to find the detailed answers.

ovt Bronze

Re: ISAKMP identity on cisco routers

Thank you for the replay, but cisco documentation lies. lies also.

Eventually I found out, that it is not possible to use ISAKMP Identity (IDii) to

look up a key in Main mode, because Main mode encrypts Identity field ("hidden

identity" concept). Recepient cannot decrypt it until phase 1 SA is authenticated.

This is in turn requires shared secret to be determined by the recepient... So,

the only possibility for the recepient is to tie the secret to the initiator's IP address.

In general it would be possible to tie the secret to the peer's FQDN and use DNS

(or local "ip host" commands) to back-resolve sender IP to FQDN, but it doesn't

work with 12.2(11)T (BUG?). And it is not a secure method unless Secure DNS is


Oleg Tipisov,



This widget could not be displayed.