cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3008
Views
10
Helpful
5
Replies

DMVPN with IKEv2 PKI

YORKIE23
Level 1
Level 1

Hello,

    I have gotten my DMVPN tunnels up, but I am having trouble with geting PKI authentication to work.  I am able to get the Ikev2 profile to work when I sent the hub and spoke to communicate with Pre shared key so I know that it has to be the PKI.  I have included a clearned versio of my configuration plus the errors I see in the logs

 

 

HUB

 

crypto pki server HUB

database level complete

no database archive

issuer-name CN=HUB

grant auto

hash sha512

cdp url http://192.164.124.25:80

auto-rollover 75

database url p12 nvram:

 

crypto pki trustpoint HUB

revocation-check crl

rsakeypair HUB

 

crypto pki trustpoint HUB-DMVPN  **Second trustpoint to enroll CA with itself**

enrollment url http://92.164.124.25:80

serial-number

subject-name CN=SPOKE

revocation-check crl

rsakeypair SPOKE

auto-enroll 75

hash sha512

 

Ikev2 Profile

match identity remote any

authentication remote rsa-sig

authentication local rsa-sig

pki trustpoint HUB-DMVPN

aaa authorization group psk list default default

 

SPOKE 

 

crypto pki trustpoint SPOKE-DMVPN

enrollment url http://92.164.124.25:80

serial-number

subject-name CN=SPOKE

revocation-check crl

rsakeypair SPOKE-DMVPN

auto-enroll 75

hash sha512

 

LOGS:

IKEV2-3-NEG_ABORT: Negotiation aborted due to ERROR: Failed to authenticate the IKE SA

CRYPTO_PKI: Rcvd request to end PKI session to end PKI session 

 

Please excuse small errors.  I had to type this because I am on two different networks.   The proposals, policies, and profiles are identical.  The same log errors keeps repeating until I take the ipsec off the tunnel.  What could be going on.  I had this all working before then it stopped due to an error in the IOS.  The IOS has since been updated to 16.3.6 and now I can't get this to work. 

 

 

 

1 Accepted Solution

Accepted Solutions

I wanted to give information for anyone who comes after me.  Setting the revocation-check to none did solve my issue, but it wasn't what I needed.  A requirement for my network was that crl checks were done.  I had reached out to Cisco concerning this issue at the same time I greated this post.  To get the crl to work I had to add the following commands to our CA server because it is the CDP location as well.  Some people place the CDP in a different location.  

 

cdp-url http://198.x.x.x:80/cgi-bin/pkiclient.exe?operation=GetCRL **You will have to press ctrl+v before the '?'.

database url crl publish http://198.x.x.x:80

    

The first configuration did not want to work until I added the second.   Everything worked PERFECTLY after this.  If this doesn't work for you, you may need to do a little alteraion. The first configuration that was suggested to me for cdp-url was cdp-url http://198.x.x.x:80/pkiclient.exe?operation=GetCRL.  I had to change it because my server is the CA and CDP server.  Listed below are the documents I referenced.  

 

https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/211333-IOS-PKI-Deployment-Guide-Initial-Design.html 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/15-mt/sec-pki-15-mt-book/sec-cfg-mng-cert-serv.html#GUID-2DE76C28-8FA6-4A48-9F02-0D8198AA1BA4

 

View solution in original post

5 Replies 5

You are not identifying yourself, try the following:-

 

crypto pki certificate map CERT_MAP 5
issuer-name co HUB
!
crypto ikev2 profile IKEV2_PROFILE
 match certificate CERT_MAP
 identity local dn

 

The value HUB is taken from your pki server issuer-name

 

crypto pki server HUB

 issuer-name CN=HUB

 

This command aaa authorization group psk list default default works with DMVPN? This is FlexVPN syntax, I don't it'll work with DMVPN (never tried though tbh).

Thanks for the input.  I have been working on this for 8 straight hours (LITERALLY) and should have mentioned everything I tried.  What you mentioned was one of them. Because the hub was the issuer, I set the crypto map check for issuer-name to contain a portion of the HUB's FQDN which was set at the creation of the CA server.  That didn't work.  I did, however, just change the revocation-check to none and the tunnel came right up.  I verified that it was using IKEV2 PKI with the show crypto ikev2 sa.  I could really cry right now because its the weekend and not getting something to work then having to wait a whole weekend to try again really bothers me.   

 

In regards to the aaa authorization group psk list default default  command, I am not even going to lie to you.  It was set by someone else when I took over the project so I have not checked the legitimacy of it.  I have just been trying to get the PKI to work.  I will look into it though because I need to ensure all commands are necessary and working.  Thanks for pointing that out.

Yeah, on a spoke it could never check the crl if it can only access the crl via the tunnel which would not have been established yet.

On the hub only, you could configure crl check, assuming there is a crl there to check. That way you still have the security and the ability to deny a spoke to establish a tunnel. You could use the "revocation-check crl none" so that way if the crl does not work, it would still fail open.

 

You are using PKI authentication, so the command aaa authorization group psk list default default doesn't apply as it would match on psk (pre-shared-key). Do you have any aaa authorization or crypto ikev2 authorization commands defined?

YORKIE23
Level 1
Level 1

So, I may have found the issue.  I changed the revocation-check to none and it started working. 

I wanted to give information for anyone who comes after me.  Setting the revocation-check to none did solve my issue, but it wasn't what I needed.  A requirement for my network was that crl checks were done.  I had reached out to Cisco concerning this issue at the same time I greated this post.  To get the crl to work I had to add the following commands to our CA server because it is the CDP location as well.  Some people place the CDP in a different location.  

 

cdp-url http://198.x.x.x:80/cgi-bin/pkiclient.exe?operation=GetCRL **You will have to press ctrl+v before the '?'.

database url crl publish http://198.x.x.x:80

    

The first configuration did not want to work until I added the second.   Everything worked PERFECTLY after this.  If this doesn't work for you, you may need to do a little alteraion. The first configuration that was suggested to me for cdp-url was cdp-url http://198.x.x.x:80/pkiclient.exe?operation=GetCRL.  I had to change it because my server is the CA and CDP server.  Listed below are the documents I referenced.  

 

https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/211333-IOS-PKI-Deployment-Guide-Initial-Design.html 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/15-mt/sec-pki-15-mt-book/sec-cfg-mng-cert-serv.html#GUID-2DE76C28-8FA6-4A48-9F02-0D8198AA1BA4

 

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: