DMVPN - Constructing a CERT payload with the wrong certificate.

[michael.leblanc]

Forum:

I have a group of routers participating in two parallel NHRP Networks. One of the NHRP networks receives tunnel protection (DMVPN), the other does not. The DMVPN was using certificate maps, and worked well.

I want to apply tunnel protection to the second NHRP network, with each router using a different certificate for each DMVPN it participates in.

On each router I have defined two new trustpoints (same CA), each referencing different RSA key pairs. The two ISAKMP profiles each reference different trustpoints (same CA), and different certificate maps. The two certificate maps have some common criteria, but differ in the "ou" being matched.

At this point, tunnel protection has not been applied to the second NHRP Network, and I've shutdown the DMVPN tunnel interfaces on all spokes, but one.

I am trying to bring up a crypto tunnel between the hub and spoke, but I am encountering issues with the hub constructing a CERT payload with the wrong certificate. The certifcate received by the spoke then matches the wrong profile, and the ISAKMP exchange is aborted.

Attachments to this post include debugs for the hub and spoke, and a summary of relevant crytpo configs for each.

*******

Edit: My appologies for a typo in the file titled: ISAKMP Debug - Spoke.pdf

I needed to scrub the files of production labels, and missed a simple replacement. The spoke debug refers to the spoke as br08-edg01.domain.null, and the hub debug refers to the spoke as sp08-edg01.domain.null. It was the same spoke.

*******

Further Investigation (best read after familiarizing yourself with the configs)

Reminder - Trying to bring up VPN-0, with the correct certificate on each end.

When I removed the VPN-1 IPSec and ISAKMP profiles (VPN-1 cert map still present) from the hub, the hub continued to send the wrong cert (vpn-1).

When I removed the VPN-1 IPSec and ISAKMP profiles (VPN-1 cert map still present) from the spoke, the tunnel came up, even though the hub sent the wrong cert (vpn-1), and it does not match the VPN-0 cert map on the spoke.

Note: Before each attempt, I'm shutting down T0 interfaces, clearing crypto SAs (clear cry sa, clear cry isakmp), removing tunnel protection from T0, verifying SA the database is empty, re-applying tunnel protection, and bringing the T0 interface up, on both devices.

I'm trying to get the hub to send the correct certificate (vpn-0).

Any thoughts would be welcome.

Best Regards,

Mike

[michael.leblanc]

Forum:

The attachment titled "ISAKMP Debug - Spoke.pdf" contained a typo, as acknowledged in the edit.

I  needed to scrub the files of production labels, and missed a simple  replacement. The spoke debug refers to the spoke as  br08-edg01.domain.null, and the hub debug refers to the spoke as  sp08-edg01.domain.null. It was the same spoke.

I'm attaching a corrected file here titled: "ISAKMP Debug - Spoke (amended).pdf"

Sorry for the hassle.

Best Regards,

Mike

[Marcin Latosiewicz]

MIke,

Check the debugs on hub side,

the isakmp profiles you have configured on the hub - you're not matching them correctly looking at the debugs.

I cannot copy for whatever reason but "Peer matches *none* of the profiles" is what you can see in the debug on hub.

May I suggest simplifying the cert maps used to match different certs to profiles?

Now regardign the ca trust-point:

http://www.cisco.com/en/US/docs/ios-xml/ios/security/a1/sec-cr-c1.html#GUID-DE9B49BB-FB15-41D0-933A-35180A5BBB59

It's only used to restrict the number of trustpoints for validation it's not trully a way to say which cerrt should be sent.

I remember seeing something similar in the past, need to go through our archives to dig it out.

M.

[Marcin Latosiewicz]

Mike,

The two tunnel interfaces configured - are they sourced from same interface?

M.

[michael.leblanc]

Marcin:

Yes, the two Tunnel interfaces (T0, T1), are using the same physical interface as the "tunnel source interface".

That is the primary reason that I have pursued the  dual certificate configuration, so that I could differentiate the two  crypto tunnels.

Best Regards,

Mike

[michael.leblanc]

Marcin:

The debug statement "Peer matches *none* of the profiles" is expected prior to processing of the CERT payload.

I've attached an excerpt from a Cisco document as a reference.

I will simplify the cert maps anyways, and reintroduce more complexity after achieving base functionality.

Best Regards,

Mike