Hi Paul ASA needs to find the appropriate tunnel group.
With Certificates, the remote peer will send the "FQDN" name as it's IKE identity. ASA goes in the following order to find a match in the tunnel group name First OU in the certificate Second FQDN in the IKE message Next IP address in the IKE message Finally default tunnel group 1) If you configure OU as the tunnel group name, then the remote peer should have OU defined in certificate and should have taken care while enrollment with CA. 2) If you configure FQDN in the tunnel group name, the FQDN from the IKE message is taken and matched. 3) If OU or FQDN doesn't match none to of tunnel group names in the ASA, the IP address is used to find a match. 4) Else DefaultL2lGroup is used. If you wish to use other attributes, then you need to use "tunnel-group-map" and "crypto ca certificate map" With certificate rules, you can match attributes other than OU, FQDN or IP address. "crypto isakmp identity" hostname is global on ASA. Anyway this will send the hostname (FQDN), if the peer can't find this hostname it will use the IP address in the IKE message. Hence, it will solve the issue where we need to send hostname to some hosts and address to some hosts. I think "peer-id-validate cert" is required when digital cert is used. With regards Kings On Sun, Oct 18, 2009 at 2:30 AM, Paul Stewart <[email protected]> wrote: > 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 > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
