Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1435
Views
5
Helpful
5
Replies

L2L with certificates between 2 ASAs

Go to solution
Peter Gammelgaard
Level 1
Level 1

‎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

Labels:
0 Helpful
2 Accepted Solutions

Accepted Solutions

Go to solution
Jason Gervia
Cisco Employee
Cisco Employee

‎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

View solution in original post

Go to solution
Jason Gervia
Cisco Employee
Cisco Employee
In response to Peter Gammelgaard

‎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

View solution in original post

0 Helpful
5 Replies 5

Go to solution
Jason Gervia
Cisco Employee
Cisco Employee

‎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

Go to solution
Peter Gammelgaard
Level 1
Level 1
In response to Jason Gervia

‎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

0 Helpful

Go to solution
Jason Gervia
Cisco Employee
Cisco Employee
In response to Peter Gammelgaard

‎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

0 Helpful

Go to solution
Peter Gammelgaard
Level 1
Level 1
In response to Jason Gervia

‎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

0 Helpful

Go to solution
Peter Gammelgaard
Level 1
Level 1
In response to Peter Gammelgaard

‎07-08-2010 02:07 AM

Jason - thanks.

That was the deal, set both ends to crypto isakmp identity auto.

0 Helpful
Getting Started

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:

Customers Also Viewed These Support Documents