Kings, I agree with almost everything you have stated. I have played with tunnel map rules to get the IKE sessions to land wherever I want them to. However, I do not like depending on "peer-id-validate cert" because it makes the IKE ID validation optional. So I believe the certificate is validated, but not the IKE ID. Through careful wording on the lab, we could be prohibited from using it. To get around the issue, we can use the dn as the identity sent from the other device. This is the ios command "crypbo isakmp identity dn".
My question now has more to do with how we can configure IOS to send dn identity to some devices and hostname to others. I thought this would be a isakmp profile option, but it doesn't seem to be. Any thoughts on this? On Sun, Oct 18, 2009 at 6:33 AM, Kingsley Charles < [email protected]> wrote: > 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
