07-07-2010 03:38 AM
Hello to all
I want to set up a L2L/Site-to-site VPN tunnel, which authenticates using certificates.
Actually I'm following this guide -> http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080aa5be1.shtml
I have configured the tunnel-group on both ends, with the configured, authenticated and accepted trustpoint specified.
I have matching isakmp policies at both ends and of course my crypto maps contains the identical 3 lines - set peer, match cryptomap access-list and set transform-set. Beside those, there are 2 identical lines for lifetime. I have not specified the trustpoint in the crypto map while it is not stated in the upper link (guide) to do that, although I have tried it, with no different result. The debugs comes up exactly the same every time:
Debug cry isa 10: (On remote end)
TEST-ASA-RA# debug cry isa 10
TEST-ASA-RA# Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 208
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing SA payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Oakley proposal is acceptable
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received NAT-Traversal ver 02 VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received NAT-Traversal ver 03 VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received NAT-Traversal RFC VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received Fragmentation VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, IKE Peer included IKE fragmentation capability flags: Main Mode: True Aggressive Mode: True
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing IKE SA payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, IKE SA Proposal # 1, Transform # 1 acceptable Matches global IKE entry # 3
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing ISAKMP SA payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing Fragmentation VID + extended capabilities payload
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 108
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + CERT_REQ (7) + CERT_REQ (7) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 374
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing ke payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing ISA_KE payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing nonce payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing cert request payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing cert request payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received Cisco Unity client VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received xauth V6 VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Processing VPN3000/ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received Altiga/Cisco VPN3000/Cisco ASA GW VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing ke payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing nonce payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing certreq payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing Cisco Unity VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing xauth V6 VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Send IOS VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, constructing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Generating keys for Responder...
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + CERT_REQ (7) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 298
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Rcv'd fragment from a new fragmentation set. Deleting any old fragments.
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Successfully assembled an encrypted pkt from rcv'd fragments!
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + ID (5) + CERT (6) + SIG (9) + IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 1987
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing ID payload
Jul 07 11:36:18 [IKEv1 DECODE]: IP = 80.62.240.136, ID_IPV4_ADDR ID received
80.62.240.136
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing cert payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing RSA signature
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Computing hash for ISAKMP
Jul 07 11:36:18 [IKEv1 DECODE]: Dump of received Signature, len 256:
0000: 8D97FE83 CDA9CEB2 A5D7F63F 0FAA76A4 ...........?..v.
0010: 21F229A8 2A714C2D 12F16ABF 08E44664 !.).*qL-..j...Fd
0020: 0D95A510 0AFFA63B 815CCBB0 B7C708CF .......;.\......
0030: 31246316 0E93E084 59395461 118C9251 1$c.....Y9Ta...Q
0040: 823A36CB 55F2F59C 3342326D 251F8B7A .:6.U...3B2m%..z
0050: B9C9F916 C403A4D1 59DA3AA8 932312C0 ........Y.:..#..
0060: 88476460 E9C9A07C 5671C18D A9202382 .Gd`...|Vq... #.
0070: 441F47AF 74E407B1 DB06B929 406E993D D.G.t......)@n.=
0080: A7C149FA 1677D1A2 E3105356 4E205E45 ..I..w....SVN ^E
0090: 06D2CB2A B6BF638E 0910283C 7FF6BAE2 ...*..c...(<....
00A0: 3F97ADF5 19B78872 69C0346B 7EF89FAE ?......ri.4k~...
00B0: 456E26CF 52CC296B 11F6AE68 2498024C En&.R.)k...h$..L
00C0: 74658112 16121A68 te.....h
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Processing IOS keep alive payload: proposal=32767/32767 sec.
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, processing VID payload
Jul 07 11:36:18 [IKEv1 DEBUG]: IP = 80.62.240.136, Received DPD VID
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, Trying to find group via IKE ID...
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, Connection landed on tunnel_group 80.62.240.136
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, peer ID type 1 received (IPV4_ADDR)
Jul 07 11:36:18 [IKEv1]: Group = 80.62.240.136, IP = 80.62.240.136, IKE Identity to Peer Cert Subject Alt Name mismatch
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, IKE MM Responder FSM error history (struct &0xd3dcecf0) <state>, <event>: MM_DONE, EV_ERROR-->MM_BLD_MSG6, EV_COMPARE_IDS-->MM_BLD_MSG6, EV_CERT_OK-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_VALIDATE_CERT-->MM_BLD_MSG6, EV_UPDATE_CERT-->MM_BLD_MSG6, EV_TEST_CERT-->MM_BLD_MSG6, EV_CHECK_NAT_T
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, IKE SA MM:1e531705 terminating: flags 0x0100c002, refcnt 0, tuncnt 0
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, sending delete/delete with reason message
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, constructing blank hash payload
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, constructing IKE delete payload
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, constructing qm hash payload
Jul 07 11:36:18 [IKEv1]: IP = 80.62.240.136, IKE_DECODE SENDING Message (msgid=5a228b67) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 80
Jul 07 11:36:18 [IKEv1]: Group = 80.62.240.136, IP = 80.62.240.136, Removing peer from peer table failed, no match!
Jul 07 11:36:18 [IKEv1]: Group = 80.62.240.136, IP = 80.62.240.136, Error: Unable to remove PeerTblEntry
Jul 07 11:36:26 [IKEv1]: IP = 80.62.240.136, Header invalid, missing SA payload! (next payload = 132)
Jul 07 11:36:26 [IKEv1]: IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 68
Jul 07 11:36:26 [IKEv1]: IP = 80.62.240.136, Header invalid, missing SA payload! (next payload = 132)
Jul 07 11:36:26 [IKEv1]: IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 68
Jul 07 11:36:26 [IKEv1]: IP = 80.62.240.136, Header invalid, missing SA payload! (next payload = 132)
Jul 07 11:36:26 [IKEv1]: IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 68
Then it waits a little and start over again. It doesn't matter whether I'm trying to establish the tunnel from headend or remote end - there is no difference in the output.
I have made a line of the debug output bold - I have not seen that before, didn't think Cisco devices used that alternative subject field? Thought it was Microsoft?
1 thing worth mention for the certificates - I'm using my won Microsoft PKI based on 2003 servers. I have 1 Root CA and 2 Subordinates. The Root CA is shutdown. When building my trustpoints, I start making my request, give it to one of the subordinates, gets my identity certificate and saves it on my computer. Then check to see the chain, which always looks good - RootCA->SubordinateCA->ClientCert. Then I extract the subordinate cert, to authenticate my trustpoint and lastly I import the Identity cert. No complaints, it's all good - and in fact working like a charm for my EZVPN setups.
So I do not think the problem is with the certificates, although the output says there's a mismatch with alternative name in subject.
The debug line after that statement, I don't quite understand - maybe someone can help me with that? Because just after that line it begins to torn down the tunnel.
I can provide configs if needed, but really, it matches the config in the guide.
/Peter
Solved! Go to Solution.
07-07-2010 06:39 AM
Can you check the 'crypto isakmp identity' command on both sides? It looks like one side is sending IP address, when it's expecting the certificate DN to be the identity so it can match it against the value in the cert.
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, peer ID type 1 received (IPV4_ADDR)
Jul 07 11:36:18 [IKEv1]: Group = 80.62.240.136, IP = 80.62.240.136, IKE Identity to Peer Cert Subject Alt Name mismatch
--Jason
07-07-2010 02:11 PM
Peter,
Setting both sides to auto should allow them to use the appropriate identity depending on the isakmp policy negotiated - ie, if using an isakmp policy with pre-shared-key then it will use the IP address as the identity, and use the DN of of the certificate if using rsa-sig in the isakmp policy.
--Jason
07-07-2010 06:39 AM
Can you check the 'crypto isakmp identity' command on both sides? It looks like one side is sending IP address, when it's expecting the certificate DN to be the identity so it can match it against the value in the cert.
Jul 07 11:36:18 [IKEv1 DEBUG]: Group = 80.62.240.136, IP = 80.62.240.136, peer ID type 1 received (IPV4_ADDR)
Jul 07 11:36:18 [IKEv1]: Group = 80.62.240.136, IP = 80.62.240.136, IKE Identity to Peer Cert Subject Alt Name mismatch
--Jason
07-07-2010 01:33 PM
Jason, thanks for the reply.
You're right. My headend is configured to send IP address, while the remote end hasn't been configured with that command yet, which should leave it to Auto, right?
But the thing is, I have several more site-to-sites, configured with pre-shared-keys. I'm afraid to change anything at the headend.
Do you think it will work if I change the remote end to send address too?
Or do both ends need to be set to Auto? And if I change that at the headend, will it cause the pre-shared-key-sites to be unable to authenticate?
Thanks.
Peter
07-07-2010 02:11 PM
Peter,
Setting both sides to auto should allow them to use the appropriate identity depending on the isakmp policy negotiated - ie, if using an isakmp policy with pre-shared-key then it will use the IP address as the identity, and use the DN of of the certificate if using rsa-sig in the isakmp policy.
--Jason
07-08-2010 12:06 AM
Well thanks then Jason.
I will try that out today, and confirm here if it works or not.
Peter
07-08-2010 02:07 AM
Jason - thanks.
That was the deal, set both ends to crypto isakmp identity auto.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: