Brian, Yes, OU should match the ISAKMP group name by default. Also try to correlate CN with the hostname.domain-name.
Regards, -- Piotr Kaluzny CCIE #25665 (Security), CCSP, CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com On Sun, Feb 28, 2010 at 9:30 PM, Brian Schultz <[email protected]> wrote: > I tried re-enrolling both the IOS router and client, no change. Cry isa > iden dn is definitely configured. Maybe it is the way I am enrolling the > cert on the client? Shouldn't the OU match the ISAKMP group name? Does the > CN correlate to anything? > > Brian > > On Sun, Feb 28, 2010 at 1:43 PM, Kingsley Charles < > [email protected]> wrote: > >> I observed this in the client's debug >> >> SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:INVALID_PAYLOAD) to 8.9.50.4 >> >> With digital authenticaiton, the hash of the CA signature recieved cert is >> checked with the local cert's hash. If it doesn't match, then the >> authentication fails. >> >> If the "crypto isakmp identity dn" doesn't work, try enrolling the client >> and IOS router again with the CA. >> >> >> >> With regards >> Kings >> >> On Mon, Mar 1, 2010 at 1:07 AM, Kingsley Charles < >> [email protected]> wrote: >> >>> Feb 28 14:00:21.438: ISAKMP (1009): received packet from 8.9.2.200 >>> dport 500 sport 1208 Global (R) MM_KEY_EXCH >>> Feb 28 14:00:21.442: ISAKMP:(1009):Input = IKE_MESG_FROM_PEER, >>> IKE_MM_EXCH >>> Feb 28 14:00:21.442: ISAKMP:(1009):Old State = IKE_R_MM4 New State = >>> IKE_R_MM5 >>> Feb 28 14:00:21.442: ISAKMP:(1009): processing ID payload. message ID = 0 >>> On the IOS, the stage is MM5 to MM6 which means there is not problem on >>> the router and the identity/certification validation has passed on the >>> router. >>> >>> >>> Failed to validate the payloads (MsgHandler:105) >>> 635 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE300009B >>> Failed to process MM Msg 6 (NavigatorMM:570) >>> 636 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE30000A7 >>> >>> On the client, it has failed at MM6 which is the last stage of ISAKMP >>> Phase 1 (authentication phase) and after it has recieved the certification. >>> Again, this should be some sort of certification validation error. >>> >>> Might me IKE ID mis-match again. You can see the IKE ID in debug crypto >>> isakmp. Check if that is there in the cert's subject of the router. Ensure >>> you have crypto isakmp indentity. >>> >>> >>> >>> >>> >>> >>> With regards >>> Kings >>> >>> >>> >>> >>> On Mon, Mar 1, 2010 at 12:48 AM, Brian Schultz <[email protected]>wrote: >>> >>>> Since that now works on the ASA, I went back to the EasyVPN on IOS >>>> section 4.6 to attempt again. I have cry isa iden dn configured on R4. I >>>> re-enrolled the cert on the client and have a valid cert. Again, same >>>> problem where client disconnects immediately. I must be missing something >>>> again... >>>> >>>> Here are the logs from the client and router debug. >>>> >>>> 621 14:59:32.921 02/28/10 Sev=Info/6 IKE/0x63000001 >>>> IOS Vendor ID Contruction successful >>>> 622 14:59:32.921 02/28/10 Sev=Info/4 IKE/0x63000013 >>>> SENDING >>> ISAKMP OAK MM (KE, NON, NAT-D, NAT-D, VID(?), VID(Unity)) to >>>> 8.9.50.4 >>>> 623 14:59:32.968 02/28/10 Sev=Info/5 IKE/0x6300002F >>>> Received ISAKMP packet: peer = 8.9.50.4 >>>> 624 14:59:32.968 02/28/10 Sev=Info/4 IKE/0x63000014 >>>> RECEIVING <<< ISAKMP OAK MM (KE, NON, CERT_REQ, VID(Unity), VID(dpd), >>>> VID(?), VID(Xauth), NAT-D, NAT-D) from 8.9.50.4 >>>> 625 14:59:32.968 02/28/10 Sev=Info/5 IKE/0x63000001 >>>> Peer is a Cisco-Unity compliant peer >>>> 626 14:59:32.968 02/28/10 Sev=Info/5 IKE/0x63000001 >>>> Peer supports DPD >>>> 627 14:59:32.968 02/28/10 Sev=Info/5 IKE/0x63000001 >>>> Peer supports DWR Code and DWR Text >>>> 628 14:59:32.968 02/28/10 Sev=Info/5 IKE/0x63000001 >>>> Peer supports XAUTH >>>> 629 14:59:33.015 02/28/10 Sev=Info/4 IKE/0x63000013 >>>> SENDING >>> ISAKMP OAK MM *(ID, CERT, CERT_REQ, SIG, >>>> NOTIFY:STATUS_INITIAL_CONTACT) to 8.9.50.4 >>>> 630 14:59:33.109 02/28/10 Sev=Info/5 IKE/0x6300002F >>>> Received ISAKMP packet: peer = 8.9.50.4 >>>> 631 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000014 >>>> RECEIVING <<< ISAKMP OAK MM *(ID, CERT, SIG, >>>> NOTIFY:STATUS_RESP_LIFETIME) from 8.9.50.4 >>>> 632 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE30000A4 >>>> Unexpected payload type found: type = 11 (MsgHandler:360) >>>> 633 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000013 >>>> SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:INVALID_PAYLOAD) to 8.9.50.4 >>>> 634 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE300009B >>>> Failed to validate the payloads (MsgHandler:105) >>>> 635 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE300009B >>>> Failed to process MM Msg 6 (NavigatorMM:570) >>>> 636 14:59:33.109 02/28/10 Sev=Warning/2 IKE/0xE30000A7 >>>> >>>> Unexpected SW error occurred while processing Identity Protection (Main >>>> Mode) negotiator:(Navigator:2263) >>>> 637 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000017 >>>> Marking IKE SA for deletion (I_Cookie=54EE5E00E1549F9F >>>> R_Cookie=414B5575CA86DE32) reason = DEL_REASON_IKE_NEG_FAILED >>>> 638 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000013 >>>> SENDING >>> ISAKMP OAK INFO *(HASH, DWR) to 8.9.50.4 >>>> 639 14:59:33.109 02/28/10 Sev=Info/5 IKE/0x6300002F >>>> Received ISAKMP packet: peer = 8.9.50.4 >>>> 640 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000058 >>>> Received an ISAKMP message for a non-active SA, >>>> I_Cookie=54EE5E00E1549F9F R_Cookie=414B5575CA86DE32 >>>> 641 14:59:33.109 02/28/10 Sev=Info/4 IKE/0x63000014 >>>> RECEIVING <<< ISAKMP OAK TRANS *(Dropped) from 8.9.50.4 >>>> 642 14:59:33.125 02/28/10 Sev=Info/5 IKE/0x6300002F >>>> Received ISAKMP packet: peer = 8.9.50.4 >>>> 643 14:59:33.125 02/28/10 Sev=Info/4 IKE/0x63000058 >>>> Received an ISAKMP message for a non-active SA, >>>> I_Cookie=54EE5E00E1549F9F R_Cookie=414B5575CA86DE32 >>>> 644 14:59:33.125 02/28/10 Sev=Info/4 IKE/0x63000014 >>>> RECEIVING <<< ISAKMP OAK INFO *(Dropped) from 8.9.50.4 >>>> 645 14:59:33.906 02/28/10 Sev=Info/4 IKE/0x6300004B >>>> Discarding IKE SA negotiation (I_Cookie=54EE5E00E1549F9F >>>> R_Cookie=414B5575CA86DE32) reason = DEL_REASON_IKE_NEG_FAILED >>>> 646 14:59:33.906 02/28/10 Sev=Info/4 IKE/0x63000001 >>>> IKE received signal to terminate VPN connection >>>> >>>> >>>> Feb 28 14:00:21.266: ISAKMP (0): received packet from 8.9.2.200 dport >>>> 500 sport 1208 Global (N) NEW SA >>>> Feb 28 14:00:21.266: ISAKMP: Created a peer struct for 8.9.2.200, peer >>>> port 1208 >>>> Feb 28 14:00:21.266: ISAKMP: New peer created peer = 0x4888DC84 >>>> peer_handle = 0x8000000B >>>> Feb 28 14:00:21.266: ISAKMP: Locking peer struct 0x4888DC84, refcount 1 >>>> for crypto_isakmp_process_block >>>> Feb 28 14:00:21.266: ISAKMP: local port 500, remote port 1208 >>>> Feb 28 14:00:21.266: ISAKMP:(0):insert sa successfully sa = 482BB914 >>>> <snip> >>>> Feb 28 14:00:21.270: ISAKMP:(0):No pre-shared key with 8.9.2.200! >>>> Feb 28 14:00:21.270: ISAKMP : Scanning profiles for xauth ... ISA_PROF >>>> Feb 28 14:00:21.270: ISAKMP:(0): Authentication by xauth preshared >>>> <snip> >>>> Feb 28 14:00:21.306: ISAKMP:(0):Checking ISAKMP transform 22 against >>>> priority 60 policy >>>> Feb 28 14:00:21.306: ISAKMP: encryption 3DES-CBC >>>> Feb 28 14:00:21.306: ISAKMP: hash MD5 >>>> Feb 28 14:00:21.306: ISAKMP: default group 2 >>>> Feb 28 14:00:21.306: ISAKMP: auth XAUTHInitRSA >>>> Feb 28 14:00:21.306: ISAKMP: life type in seconds >>>> Feb 28 14:00:21.306: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 >>>> 0x9B >>>> Feb 28 14:00:21.306: ISAKMP:(0):atts are acceptable. Next payload is 3 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Acceptable atts:actual life: 86400 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Acceptable atts:life: 0 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Fill atts in sa vpi_length:4 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Fill atts in sa life_in_seconds:2147483 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Returning Actual lifetime: 86400 >>>> Feb 28 14:00:21.306: ISAKMP:(0)::Started lifetime timer: 86400. >>>> Feb 28 14:00:21.306: ISAKMP:(0): vendor ID is NAT-T v2 >>>> Feb 28 14:00:21.306: ISAKMP:(0):Input = IKE_MESG_INTERNAL, >>>> IKE_PROCESS_MAIN_MODE >>>> Feb 28 14:00:21.306: ISAKMP:(0):Old State = IKE_R_MM1 New State = >>>> IKE_R_MM1 >>>> Feb 28 14:00:21.310: ISAKMP:(0): constructed NAT-T vendor-02 ID >>>> Feb 28 14:00:21.310: ISAKMP:(0): sending packet to 8.9.2.200 my_port 500 >>>> peer_port 1208 (R) MM_SA_SETUP >>>> Feb 28 14:00:21.310: ISAKMP:(0):Sending an IKE IPv4 Packet. >>>> Feb 28 14:00:21.310: ISAKMP:(0):Input = IKE_MESG_INTERNAL, >>>> IKE_PROCESS_COMPLETE >>>> Feb 28 14:00:21.310: ISAKMP:(0):Old State = IKE_R_MM1 New State = >>>> IKE_R_MM2 >>>> Feb 28 14:00:21.334: ISAKMP (0): received packet from 8.9.2.200 dport >>>> 500 sport 1208 Global (R) MM_SA_SETUP >>>> Feb 28 14:00:21.334: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH >>>> Feb 28 14:00:21.334: ISAKMP:(0):Old State = IKE_R_MM2 New State = >>>> IKE_R_MM3 >>>> Feb 28 14:00:21.386: ISAKMP:(1009): sending packet to 8.9.2.200 my_port >>>> 500 peer_port 1208 (R) MM_KEY_EXCH >>>> Feb 28 14:00:21.386: ISAKMP:(1009):Sending an IKE IPv4 Packet. >>>> Feb 28 14:00:21.390: ISAKMP:(1009):Input = IKE_MESG_INTERNAL, >>>> IKE_PROCESS_COMPLETE >>>> Feb 28 14:00:21.390: ISAKMP:(1009):Old State = IKE_R_MM3 New State = >>>> IKE_R_MM4 >>>> Feb 28 14:00:21.438: ISAKMP (1009): received packet from 8.9.2.200 dport >>>> 500 sport 1208 Global (R) MM_KEY_EXCH >>>> Feb 28 14:00:21.442: ISAKMP:(1009):Input = IKE_MESG_FROM_PEER, >>>> IKE_MM_EXCH >>>> Feb 28 14:00:21.442: ISAKMP:(1009):Old State = IKE_R_MM4 New State = >>>> IKE_R_MM5 >>>> Feb 28 14:00:21.442: ISAKMP:(1009): processing ID payload. message ID = >>>> 0 >>>> Feb 28 14:00:21.538: ISAKMP: Unlocking peer struct 0x4888DC84 for >>>> isadb_mark_sa_deleted(), count 0 >>>> Feb 28 14:00:21.538: ISAKMP: Deleting peer node by peer_reap for >>>> 8.9.2.200: 4888DC84 >>>> Feb 28 14:00:21.538: ISAKMP:(1009):deleting node 1743953128 error FALSE >>>> reason "IKE deleted" >>>> Feb 28 14:00:21.538: ISAKMP:(1009):Input = IKE_MESG_FROM_PEER, >>>> IKE_MM_EXCH >>>> Feb 28 14:00:21.538: ISAKMP:(1009):Old State = IKE_DEST_SA New State = >>>> IKE_DEST_SA >>>> >>>> crypto isakmp policy 60 >>>> encr 3des >>>> hash md5 >>>> group 2 >>>> crypto isakmp identity dn >>>> crypto isakmp client configuration group CCIE >>>> pool EZPOOL >>>> acl 170 >>>> crypto isakmp profile ISA_PROF >>>> match identity group CCIE >>>> client authentication list XAUTH >>>> isakmp authorization list EZ_POL >>>> client configuration address respond >>>> virtual-template 2 >>>> crypto ipsec transform-set SET6 esp-3des esp-md5-hmac >>>> crypto ipsec profile IPSEC_PROF6 >>>> set transform-set SET6 >>>> set reverse-route distance 15 >>>> set isakmp-profile ISA_PROF >>>> interface Virtual-Template2 type tunnel >>>> ip unnumbered Serial0/0/0 >>>> tunnel mode ipsec ipv4 >>>> tunnel protection ipsec profile IPSEC_PROF6 >>>> >>>> Thanks, >>>> Brian >>>> >>>> >>>> On Sun, Feb 28, 2010 at 12:25 PM, Brian Schultz <[email protected]>wrote: >>>> >>>>> Thank you Kings! I had 'crypto isakmp identity address' on the ASA. >>>>> Works perfectly now! >>>>> >>>>> Regards, >>>>> Brian >>>>> >>>>> On Sun, Feb 28, 2010 at 12:19 PM, Kingsley Charles < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Feb 28, 2010 at 11:49 PM, Kingsley Charles < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 82 11:41:00.781 02/28/10 Sev=Warning/3 IKE/0xE3000081 >>>>>>> Invalid remote certificate id: ID_IPV4_ADDR: ID = 0x0A020908, >>>>>>> Certificate = 0x00000000 >>>>>>> 83 11:41:00.781 02/28/10 Sev=Warning/3 IKE/0xE3000059 >>>>>>> The peer's certificate doesn't match Phase 1 ID >>>>>>> 84 11:41:00.781 02/28/10 Sev=Warning/2 IKE/0xE30000A7 >>>>>>> Unexpected SW error occurred while processing Identity Protection >>>>>>> (Main Mode) negotiator:(Navigator:2263) >>>>>>> >>>>>>> Check out the debugs. >>>>>>> >>>>>>> The VPN client, expects the IKE ID to be present in certificate. In >>>>>>> the client, we don't have an option disable the peer validating check >>>>>>> as we >>>>>>> do on ASA. >>>>>>> >>>>>>> So we need to ensure that "crypto isakmp indentity dn" is configured >>>>>>> on the ASA. This will send all the information is the subject and will >>>>>>> match >>>>>>> the IKE ID. >>>>>>> >>>>>>> If you don't enable "crypto isakmp indentity dn", it will send the >>>>>>> hostname and will not mtach the cert's subject and hence the validation >>>>>>> fails. >>>>>>> >>>>>>> >>>>>>> >>>>>>> With regards >>>>>>> Kings >>>>>>> >>>>>>> On Sun, Feb 28, 2010 at 11:40 PM, Jimmy Larsson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> It looks almost the same as I posted here about last week. I >>>>>>>> guess it has something to do with username. The CN in the cert is ASA1 >>>>>>>> but >>>>>>>> further down it saids "Username = IP ExperT". >>>>>>>> >>>>>>>> Just a guess. Anyone else? >>>>>>>> >>>>>>>> /J >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------- >>>>>>>> Jimmy Larsson >>>>>>>> Ryavagen 173 >>>>>>>> s-26030 Vallakra >>>>>>>> Sweden >>>>>>>> http://blogg.kvistofta.nu >>>>>>>> ------- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
