Hi Jason, Now then when you confirmed that your Hub router was missing an identity certificate it becomes clear why you saw those error messages. In my view this is what was happening. The spoke router tried to initiate the tunnel and presented its certificate to the Hub. The Hub is supposed to verify the validity of this certificate against the existing trustpoint, namely querying the CA for CRL and so on. In your case this trustpoint didn't exist and the Hub unconditionally dropped the connection from the Spoke. Just out of curiosity what did you see on the Spoke while debugging ISAKMP? It should have complained about the peer certificate as well because the CA certificate (the only one available on the Hub) can't be used for peer authentication.
Eugene From: Jason Madsen <[email protected]<mailto:[email protected]>> Date: Thursday, August 23, 2012 9:14 AM To: Kingsley Charles <[email protected]<mailto:[email protected]>> Cc: Eugene Pefti <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [OSL | CCIE_Security] IPSec VPN w RSA-SIG Using Cert Authority (CA) as one of the VPN Peers Kings, You were right on! I'm VERY glad I ran into this and got your feedback, thanks! I just recreated the scenario and was immediately getting "bad cert" messages on the hub. I then created another Trust Point on the hub referencing itself, authenticated, enrolled, and then IPSec came right up. I guess I'm a little confused regarding how Identity works regarding Certs. This is definitely one area I need to get a better mastery of. So, R1 was the Hub and CA in this scenario, and R2 was the Spoke. Prior to the fix, I was seeing the following message on the Hub: Mar 1 00:12:58.543: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 12.12.12.2 is bad: CA request failed! The fix consisted of creating another Trust Point on the Hub and getting a new Cert from itself. Why did the symptoms seem to point toward the Spoke's cert and not the Hub's cert, and what specifically was being seen as "bad"? KInd of weird R1 would determine R2's cert as "bad" when it was the device that issued the cert! Here's relevant config's and output from both devices, and the cert' store for both devices before the fix: R1 (Hub and CA): Mar 1 00:10:03.811: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 12.12.12.2 is bad: CA request failed! ! cryp isak pol 10 enc aes hash sha auth rsa-sig ! crypto ipsec transform-set TS esp-aes esp-sha-hmac ! crypto ipsec profile PROF set transform-set TS interface FastEthernet0/0 ip address 12.12.12.1 255.255.255.0 ! interface Tunnel9 ip address 9.9.9.1 255.255.255.0 no ip redirects ip mtu 1440 ip nhrp authentication blah ip nhrp map multicast dynamic ip nhrp network-id 9 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel key 9 tunnel protection ipsec profile PROF end ! R1#sho crypto pki certificates verbose CA Certificate Status: Available Version: 3 Certificate Serial Number: 0x1 Certificate Usage: Signature Issuer: cn=R1 CA ou=Dept A o=My Org l=Some Town c=US Subject: cn=R1 CA ou=Dept A o=My Org l=Some Town c=US Validity Date: start date: 00:04:40 UTC Mar 1 2002 end date: 00:04:40 UTC Feb 28 2005 Subject Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Signature Algorithm: MD5 with RSA Encryption Fingerprint MD5: 2210B4F9 78E12C7E 91ACAF31 71F97030 Fingerprint SHA1: 10BBE7A1 B9EF3303 5A65953B 43C46BF2 9219C149 X509v3 extensions: X509v3 Key Usage: 86000000 Digital Signature Key Cert Sign CRL Signature X509v3 Subject Key ID: B6FFF7C9 6D855713 A40689E1 BE0249C6 A7CA2935 X509v3 Basic Constraints: CA: TRUE X509v3 Authority Key ID: B6FFF7C9 6D855713 A40689E1 BE0249C6 A7CA2935 Authority Info Access: Associated Trustpoints: R1-CA ! ! R1#sho crypto key mypubkey rsa ! % Key pair was generated at: 00:02:42 UTC Mar 1 2002 Key name: R1-CA Storage Device: not specified Usage: General Purpose Key Key is exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B0D4A2 10BC71F1 D1B19822 249831E9 5208A3A5 8ED595A6 6B9E19E4 551BF630 BC414028 71172E6C 9B233630 F5AA020C 43BE26FA 61866713 AC25D48E FBA18799 B4F16A6B 273A0EC1 F080F99F 78F7C559 B6DB76BC 3E75CB80 B37E1E36 A9AD0468 F87B69F2 0BAE7D08 6C2528B8 E5A431D5 B285C5F3 7B9C4FC8 8209F048 BE6FAB6A 25020301 0001 % Key pair was generated at: 00:02:43 UTC Mar 1 2002 Key name: R1-CA.server Temporary key Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A5FA02 6F6771F7 A41A5925 C66D44E8 0CB5BF57 E7DE71C7 2C096598 52959315 49C61EBA A71F65F5 96783FB8 3D3C37E6 77AE43D8 D2426086 45602BEC F4EDA508 91020B84 A20B8534 3EE3BDCC 37F82921 07519A60 BB3355A0 5E279E57 3F478BBC 3D020301 0001 ! R1#sho cryp isak sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status 12.12.12.1 12.12.12.2 MM_KEY_EXCH 1023 0 ACTIVE 12.12.12.1 12.12.12.2 MM_NO_STATE 1022 0 ACTIVE (deleted) R2 (Spoke got Cert from Hub): (no error message) ! cryp isak pol 10 enc aes hash sha auth rsa-sig ! crypto ipsec transform-set TS esp-aes esp-sha-hmac ! crypto ipsec profile PROF set transform-set TS interface FastEthernet0/0 ip address 12.12.12.2 255.255.255.0 ! interface Tunnel9 ip address 9.9.9.2 255.255.255.0 no ip redirects ip mtu 1440 ip nhrp authentication blah ip nhrp map 9.9.9.1 12.12.12.1 ip nhrp map multicast 12.12.12.1 ip nhrp network-id 9 ip nhrp nhs 9.9.9.1 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel key 9 tunnel protection ipsec profile PROF end ! R2#sho cryp pki cert verbose Certificate Status: Available Version: 3 Certificate Serial Number: 0x2 Certificate Usage: General Purpose Issuer: cn=R1 CA ou=Dept A o=My Org l=Some Town c=US Subject: Name: R2.blah.com<http://R2.blah.com> Serial Number: FTX0945W0MY serialNumber=FTX0945W0MY+hostname=R2.blah.com<http://R2.blah.com> CRL Distribution Points: http://12.12.12.1/cgi-bin/pkiclient.exe?operation=GetCRL Validity Date: start date: 00:05:57 UTC Mar 1 2002 end date: 00:05:57 UTC Mar 1 2003 Subject Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Signature Algorithm: MD5 with RSA Encryption Fingerprint MD5: 4500A2B9 C6DED1A0 73E1C5D1 B53F44BF Fingerprint SHA1: 296ECCF1 58CF2B20 191B11A0 BCDF3860 D6DEB896 X509v3 extensions: X509v3 Key Usage: A0000000 Digital Signature Key Encipherment X509v3 Subject Key ID: 87179F80 265A26CE C27428E4 5EEF4624 5DBBDDB0 X509v3 Authority Key ID: B6FFF7C9 6D855713 A40689E1 BE0249C6 A7CA2935 Authority Info Access: Associated Trustpoints: R1-CA Key Label: R2.blah.com<http://R2.blah.com> CA Certificate Status: Available Version: 3 Certificate Serial Number: 0x1 Certificate Usage: Signature Issuer: cn=R1 CA ou=Dept A o=My Org l=Some Town c=US Subject: cn=R1 CA ou=Dept A o=My Org l=Some Town c=US Validity Date: start date: 00:04:40 UTC Mar 1 2002 end date: 00:04:40 UTC Feb 28 2005 Subject Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Signature Algorithm: MD5 with RSA Encryption Fingerprint MD5: 2210B4F9 78E12C7E 91ACAF31 71F97030 Fingerprint SHA1: 10BBE7A1 B9EF3303 5A65953B 43C46BF2 9219C149 X509v3 extensions: X509v3 Key Usage: 86000000 Digital Signature Key Cert Sign CRL Signature X509v3 Subject Key ID: B6FFF7C9 6D855713 A40689E1 BE0249C6 A7CA2935 X509v3 Basic Constraints: CA: TRUE X509v3 Authority Key ID: B6FFF7C9 6D855713 A40689E1 BE0249C6 A7CA2935 Authority Info Access: Associated Trustpoints: R1-CA ! R2#sho crypto key mypubkey rsa % Key pair was generated at: 00:05:42 UTC Mar 1 2002 Key name: R2.blah.com<http://R2.blah.com> Storage Device: not specified Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B6390A E2BA542F 34E4B5FE 3A292DAE 47AEAE26 E6DF5A85 1CEDD79A 6F6A4120 96726ED3 416DBD38 3A079337 AE228D56 0F062188 F0140927 A7020340 29AFC5C2 C597559A B900A36E 0C169840 610FFDAA 1C2027B6 51CF07E1 1FA24B90 A053CB75 ECBA2B5C 5044DFAF A0C520AE 0AC6D02D F77E18A3 7B736BDF C207C07F 91B1D635 F3020301 0001 % Key pair was generated at: 00:05:43 UTC Mar 1 2002 Key name: R2.blah.com.server Temporary key Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A9838F C9AF2B5D F993422C 0DFF3975 F45ADBB1 3CF3D598 CA5D91CF E4079F16 960CE78B 8B5326CF DA8B6184 77D38695 132D3186 FFBA325E 0D3D62BF 3C498433 B8CC6CCE C6B88449 CDF5F32D AFC4E179 D2B6A0F7 51A89344 9A39D534 7DCAF215 D3020301 0001 ! R2#sho cryp isak sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status 12.12.12.1 12.12.12.2 MM_NO_STATE 1023 0 ACTIVE (deleted) ################################################# On Thu, Aug 23, 2012 at 4:51 AM, Kingsley Charles <[email protected]<mailto:[email protected]>> wrote: His statement "The unusual part is that I used the DMVPN hub as the Cert Authority (CA) for the DMVPN Spoke" People, miss the one that I mentioned. If it's not that, then we should look for other issues. With regards Kings CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security) On Thu, Aug 23, 2012 at 1:08 PM, Eugene Pefti <[email protected]<mailto:[email protected]>> wrote: Isn’t it the other way around? Jason says that Hub doesn’t trust the Spoke certificate. For me it means that Hub already has the identity certificate. Of course we don’t the content of certificate store from the Hub and can’t be 100 sure. But the similar scenario worked for me. Eugene From:[email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kingsley Charles Sent: Wednesday, August 22, 2012 11:50 PM To: Jason Madsen Cc: [email protected]<mailto:[email protected]> Subject: Re: [OSL | CCIE_Security] IPSec VPN w RSA-SIG Using Cert Authority (CA) as one of the VPN Peers On the DMVPN Hub, configure separate trustpoint and enroll to itself. With regards Kings CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security) On Thu, Aug 23, 2012 at 11:32 AM, Jason Madsen <[email protected]<mailto:[email protected]>> wrote: Hi all, I was practicing going through some random IPSec VPN configurations to work on configuration speed, and I ran into something unexpected. I setup DMVPN with just 2 devices participating...a single hub and spoke. The unusual part is that I used the DMVPN hub as the Cert Authority (CA) for the DMVPN Spoke. I busted through the config's for DMVPN, and then found that ISAKMP kept failing to negotiate using certificates. I changed to "auth pre-shared" and everything came up immediately, so I knew it was cert related. After reverting back to RSA-SIG auth mode, I found that the Hub kept stating that the Cert from the Spoke was "bad". Is this an unsupported configuration (using a DMVPN hub as a CA for the Spokes), is it a supported config' that requires a unique configuration, or did I just fat finger something? I just redid the scenario using a non-DMVPN member as the CA, and everything worked immediately...no issues. Thanks, Jason _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
