I have found this issue to go away if you identify the router with the "dn" if the certificate instead of the hostname. The command is "crypto isakmp identity dn". I guess the ASA just checks the validity of the certificate against the trustpoint. If you add peer-id-validate req, I think the identity of the certificate must match the IKE ID sent. There is some misinformation out there that statest "cert" validates it by the "certificate". I think with "cert" the certificate would have to be valid, but would not need to match the IKE ID.
I think it is a good idea to validate the identity, but I am having trouble understanding how I send "dn" to some hosts and "address" or "hostnames" to other peers. I thought this would be an ISAKMP profile option, but I seem to be missing it. The settings seem global and no work around. Any thoughts would be appreciated. On Sat, Oct 17, 2009 at 4:54 PM, Badar Farooq <[email protected]> wrote: > Paul > I have also struggled with this issue. > I know the solution, i.e peer id validate cert but not the mechanism. > And solutions guides seem to get it work without this command anyway > > Waiting for someone to give a detail explanation. > > On Sat, Oct 17, 2009 at 9:27 PM, Paul Stewart <[email protected]> wrote: > > With the ASA, I continually get "Unable to compare IKE ID against peer > cert > > Subject Alt Name". By changing the tunnel-group to "peer-id-validate > cert", > > everything is fine. However, according to the Cisco documentation, this > > only validates the id against the certificate if the certificate supports > > it. Setting it back to the default of "peer-id-validate req", would > force > > it to validate the id with the certificate or fail. Mine fails. So, I > need > > to understand the process that happens for validating a id to a > > certificate. I am on lab 12 4.3 right now and cannot seem to resolve the > > issue. I have also tried enabling certificate mapping rules. I can get > the > > sessions to land where I think they should, but they always fail the same > > way. > > > > > > Oct 17 14:24:57 [IKEv1 DEBUG]: IP = 6.6.156.5, processing notify payload > > Oct 17 14:24:57 [IKEv1]: IP = 6.6.156.5, Automatic NAT Detection Status: > > Remote end is NOT behind a NAT device This end is NOT behind a NAT > > device > > Oct 17 14:24:57 [IKEv1]: IP = 6.6.156.5, Trying to find group via cert > > rules... > > Oct 17 14:24:57 [IKEv1]: IP = 6.6.156.5, Connection landed on > tunnel_group > > 6.6.156.5 > > Oct 17 14:24:57 [IKEv1 DEBUG]: Group = 6.6.156.5, IP = 6.6.156.5, peer ID > > type 1 received (IPV4_ADDR) > > Oct 17 14:24:57 [IKEv1]: Group = 6.6.156.5, IP = 6.6.156.5, Unable to > > compare IKE ID against peer cert Subject Alt Name <<< > > > > > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
