DMVPN w/certificates - problems during re-keying

[m.coakley]

I have setup a DMVPN hub that is using another router as its certificate server. (This document is the basic setup of the VPN headend and certificate server: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080215686.shtml)

I'm using certificate mapping to get to my ISAKMP/IPSEC profiles and placing the each VPN (multiple customers) into their own VRF instance. Everything works fine and the tunnels are established properly using the certificates. The problems comes up when the tunnels re-key after 86400 seconds, the tunnels are dropped and cannot be re-established. If I manually go into the router and go into configuration mode and issue the "cryto ca certificate validate <trustpoint>" command the certificates are re-validated and the VPN tunnels re-establish.

Anyone have any ideas?

Thanks,

Mike

[smahbub]

Check for any misconfigurations that is causing the IKE packet drops.

[m.coakley]

I do not believe IKE is the issue. The failure occurs when the session is trying to validate the certificate against the local CA server. If I manually issue the "crypto ca certificate validate " command on the VPN head-end the session will work. Since I first posted the question I have setup a CRON job on a system that uses the CISCOCMD program to issue that command every 6 hours. Since I have started this my VPN sessions stay connected as expected. I would like them to stay connected without having to issue this command from a CRON job though.

Thanks,

Mike

[mnlatif]

Have you tried debugging the ISAKMP negotiation ? That would point you to the actual failure reason E.g. CRL check failing etc

I think the IKE re-negotiation occurs around 30 minutes before the expirey, so if you setup

debug crypto isakmp

debug crypto pki server (on the CA router)

debug crypto pki messages

debug crypto pki transactions

You should be able to get a reason for the failure.

\\ Naman

[m.coakley]

I have actually debugged the re-negotiation. It appears to me that the CRL check is failing. At this point since it is a new IOS CA server installation I do not have any revoked certificates so this may be the culprit. I will have to research this issue more.

Thanks,

Mike

[mnlatif]

Having no revoked certificates does not mean that you won't have a CRL. A CRL will still exist with no revoked certficates numbers.

Where is the CRL distribution Point (As specified in the Certificate) ?

Is that reachable by the Router (Who is failing the CRL check) ?

If you have hosted the CRL on the IOS router, then is it allowing the incoming packets ?

If the CRL distribution point is not reachable by the router, then you can manually define a CRL location E.g. on your DMZ Server etc. You will obviously have to copy the CRL to the DMZ server regularly though.

\\ Naman