ISAKMP Phase II issue, with IPSec Profile on mGRE Tunnel interface.

Unanswered Question
Jul 9th, 2010

Background: We are migrating a stable P2P GRE + IPSec implementation (with rsa-encr authentication), to a DMVPN (mGRE) implementation. We intend to migrate to rsa-sig after successfully establishing the DMVPN with pre-share authentication. All P2P GRE + IPSec crypto maps have been removed from the physical interfaces, and the P2P GRE tunnel interfaces have been administratively shutdown. With DMVPN configured, we have the spoke initiating ISAKMP with the hub, and ISAKMP phase I negotiation succeeds (QM_IDLE).

Issue: We are encountering ISAKMP phase II issues.

A debug (ISAKMP + IPSec) on the hub indicates that the proposed IPSec attributes are acceptable. When the proposal request is validated, we are presented with the following errors:

Jun 30 21:22:56.616 EDT: ISAKMP:(2001):atts are acceptable.
Jun 30 21:22:56.616 EDT: IPSEC(validate_proposal_request): proposal part #1
Jun 30 21:22:56.616 EDT: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= <hub-ip-physical>, remote= <spoke-ip-physical>,
    local_proxy= <hub-ip-physical>/255.255.255.255/47/0 (type=1),
    remote_proxy= <spoke-ip-physical>/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= NONE  (Transport),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
Jun 30 21:22:56.616 EDT: map_db_check_isakmp_profile profile did not match
Jun 30 21:22:56.616 EDT: map_db_check_isakmp_profile profile did not match
Jun 30 21:22:56.616 EDT: map_db_find_best did not find matching map
Jun 30 21:22:56.616 EDT: IPSEC(ipsec_process_proposal): proxy identities not supported
Jun 30 21:22:56.616 EDT: ISAKMP:(2001): IPSec policy invalidated proposal with error 32
Jun 30 21:22:56.616 EDT: ISAKMP:(2001):Checking IPSec proposal 2
... snip ...
Jun 30 21:22:56.616 EDT: ISAKMP:(2001): phase 2 SA policy not acceptable! (local <hub-ip-physical> remote <spoke-ip-physical>)

We are not sure why a matching ISAKMP profile and map are not found.


hub# sh cry isa profile
ISAKMP PROFILE DMVPN
Ref Count = 3
   Identities matched are:
    ip-address aaa.bbb.ccc.0 255.255.240.0
   Certificate maps matched are:
   keyring(s): dmvpn
   trustpoint(s): <all>

hub# sh cry ips profile
IPSEC profile DMVPN
        Security association lifetime: 4608000 kilobytes/3600 seconds
        Responder-Only (Y/N): N
        PFS (Y/N): Y
        DH group:  group1
        Transform sets={eni-xfm-des:  { esp-des esp-sha-hmac  } , eni-xfm-3des:  { esp-3des esp-sha-hmac  } ,}

hub# sh cry map
Crypto Map "Tunnel0-head-0" 65536 ipsec-isakmp
        ISAKMP Profile: DMVPN
        Profile name: DMVPN
        Security association lifetime: 4608000 kilobytes/3600 seconds
        Responder-Only (Y/N): N
        PFS (Y/N): Y
        DH group:  group1
        Transform sets={eni-xfm-des:  { esp-des esp-sha-hmac  } , eni-xfm-3des:  { esp-3des esp-sha-hmac  } ,}
        Interfaces using crypto map Tunnel0-head-0: Tunnel0

Note: Two other crypto maps exist on the hub, and are listed in the show output. However, they are not applied to any interfaces.

On the spoke, we see a Profile Instance such as this:

Crypto Map "Tunnel0-head-0" 65537 ipsec-isakmp
        Map is a PROFILE INSTANCE.
        Peer = <hub-ip-physical>
        ISAKMP Profile: DMVPN
        Extended IP access list
            access-list  permit gre host <spoke-ip-physical> host <hub-ip-physical>
        Current peer: <hub-ip-physical>
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): Y
        DH group:  group1
        Transform sets={eni-xfm-des, eni-xfm-3des,}
        Interfaces using crypto map Tunnel0-head-0: Tunnel0

... but not on the hub.


Configuration (Hub & Spoke): Relevant crypto portions of the DMVPN configurations follow:

crypto keyring dmvpn
pre-shared-key address 0.0.0.0 0.0.0.0 key <removed>

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 3600

Note: Other ISAKMP policies snipped.

crypto isakmp identity hostname

crypto isakmp profile DMVPN
keyring dmvpn
match identity address aaa.bbb.ccc.0 255.255.240.0

Note: aaa.bbb.ccc.0 255.255.240.0 represents the address space used on the Internet exposed interfaces.
Note: Also tried "match identity address 0.0.0.0 0.0.0.0" on the hub and spoke.


crypto ipsec transform-set eni-xfm-3des esp-3des esp-sha-hmac
mode transport
crypto ipsec transform-set eni-xfm-des esp-des esp-sha-hmac
mode transport

crypto ipsec profile DMVPN
set transform-set eni-xfm-des eni-xfm-3des
set pfs group1
set isakmp-profile DMVPN

interface Tunnel0
ip address <removed> 255.255.255.0
tunnel protection ipsec profile DMVPN

Note: NHRP,  mGRE, and most other parameters have been snipped.

Any assistance would be appreciated.

Best Regards,
Mike

I have this problem too.
2 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marcin Latosiewicz Sat, 07/10/2010 - 02:45

Michael,

Regarding lacking entires on the hub - as far as I remember they will be only created when tunnel establishes (ie, hub doesn't know endpoints to create this mapping you point out) - I might be wrong on this one.

Those problems come usually from minor misconfigs (or something completly wicked)

- check nat traversal being enabled if spoke is behind nat.

- vrf config?

- source interfaces on both tunnel interface correct?

- version information...

Honestly after checking basics I would open a TAC case.

Marcin

michael.leblanc Sat, 07/10/2010 - 07:02

Marcin:

We are attributing the absence of a Profile Instance on the hub, to the inability to find a matching ISAKMP profile and map.

The hub and spoke both use PAT, and are Internet exposed. The PAT configuration has successfully supported the prior P2P GRE + IPSec configuration.

No VRFs configured.

The tunnel source interfaces have been verified as correct. They both specify FastEthernet0, which are the Internet exposed physical interfaces.

The hub is a c1811 with c181x-advipservicesk9-mz.124-24.T.


The spoke is a c1711 with c1700-advipservicesk9-mz.124-15.T9.

Thank you for your interest.

Best Regards,

Mike

michael.leblanc Thu, 07/22/2010 - 09:11

To All:

We side-stepped the issue.

We eliminated the need for the ISAKMP profile by implementing rsa-signatures (X.509 certificates) as our ISAKMP authentication method (our original goal) rather than pre-shared keys.

Best Regards,

Mike

Jitendriya Athavale Thu, 07/22/2010 - 10:58

i have one doubt here

i do not understand the need for

crypto isakmp profile DMVPN
keyring dmvpn
match identity address aaa.bbb.ccc.0 255.255.240.0

since you are using certificates

and i think probably that is causing the issue as the debugs say they are not matching identities

michael.leblanc Thu, 07/22/2010 - 14:57

Jathaval:

I think you mis-understood our post.

Although our ultimate goal was to establish a DMVPN with certificates, the initial configuration posted here utilized pre-shared keys as the ISAKMP authentication method. The routers had not been enrolled in a PKI, and did not have certificates available to them.

When a solution was not readilly identified, we proceeded with setting up a Cisco IOS Certificate Server, enrolled the routers in the PKI, and ammended the configuration(s) to utilize the certificates for ISAKMP authentication. We then encountered an issue with that configuration which was documented in a separate post titled "mGRE tunnel SAs negotiated, but don't survive."

Content from post titled mGRE tunnel SAs negotiated, but don't survive.:

Note: This was the PKI configuration.

"We were migrating from a P2P GRE to mGRE configuration. In doing so, we defined new tunnel interfaces for mGRE, and shutdown the P2P tunnel interfaces. We migrated configuration parameters we wished to retain, including the "tunnel key". We assumed erroneously, that we could do so given that the P2P tunnels were administratively shutdown. NOT!

On a hunch, we shutdown the mGRE tunnel interfaces, modified the tunnel key to a value different than that configured on the shutdown P2P tunnel interfaces, and then brought the mGRE interfaces out of shutdown. The tunnel came up, stayed up, NHRP registration took place, routes were exchanged, and we breathed a sigh of relief."


When we encountered the phase II issues described in this post (pre-shared keys), the mGRE tunnel key would have been the same as configured on the shutdown P2P GRE tunnels. Since modifying the mGRE tunnel key to a value different than that configured on the shutdown P2P tunnel interfaces resolved our issues with the PKI configuration, it seems plausible that it would have resolved our issues with the pre-shared key configuration (documented in this post).

Thanks for your interest in our issue.

Best Regards,

Mike

Michael Harding Tue, 12/21/2010 - 05:57

Hi Mike,

tunnel protection ipsec profile DMVPN shared

If you have mutiple tunnels sourced from a single interface. I think you may need the shared command at the end of this statement? I could be wrong..

but I beieve it associates the tunnel interface with the ipsec profile, in your case DMVPN and ties them together. so if you have another tunnel interface it could be getting confused with that in the absence on this command.

Kind regards,

Mike H

Vittorio Alfieri Tue, 07/15/2014 - 00:54

Hi!

I had the same problem, on a Cisco 2801 with IOS 15.1.

map_db_check_isakmp_profile profile did not match
map_db_find_best did not find matching map
IPSEC(ipsec_process_proposal): proxy identities not supported

 

I have a router that is doing nat + dmvpn + ezvpn + vrf-lite, and was having trouble as soon as I added the vrf.

 

Like the OP posted, removing the crypto isakmp profile did the trick.

I had the crypto isakmp profile, because I use PSKs and have multiple VPN types on the router.

After removing the isakmp profile ( by removing the associating line from the crypto ipsec profile section), I had to wait about an hour an the tunnel came back up.

Can somebody confirm for me that dmvpn + vrf + crypto isakmp profiles do not work together, or is there a workaround or something I'm missing?

I had tried adding the vrf keyword to the match address statement, but to no avail.

 

Thanks,

Vittorio

Actions

This Discussion

Related Content