DMVPN + PKI AAA

[Ruterford]

Hello All,

I have a question about the DMVPN dual hub  and spokes over public internet scenario.

I am going to use PKI AAA authentication and I understand that in order to enroll a spoke that has never been connected to our office LAN and just being deployed remotely at the remote location I would need to have my CA server be exposed to the internet and public ip address of the CA server needs to be configured under "enrollment url" on the spokes.

In order to workaround this issue I could have all spokes unpacked and enrolled with  their certs in the office first and then get them deployed at remote locations.

But, another question is that if spokes will still require access to the CA server before they do authentication to establish VPN tunnels.

So, the VPN tunnel does not get established until the spoke queries the CA and makes sure that HUB's certificate is still ok, is this correct understanding?

If this is correct, then I am wondering what is the workaround not to expose the CA server to public internet and have PKI AAA authentication on the spokes and hub.

Thanks!

.

[Karsten Iwen · Accepted solution]

There are different ways to solve the mentioned problems:

Initial enrolement:
Best would be to do it before sending the routers out to the remote site. But of course that is not always possible.
You could expose your internal CA to the internet for enrollment and only allow the spoke-IP to access the server. You only need tcp/80 for SCEP as it's HTTP-based. Another way is to have an additional tunnel into your network which is authenticated with PSKs. This tunel should of course use a very strict access-control and could even be shut down when not needed. This tunnel could also be used for reenrollment if for some reasons your certificate is not valid (anyone here on the forum who never made the mistake to note a wrong expiration-date in outlook and lost his VPNs the days when autoenrollment was not available? )

After enrollment, the spokes don't need to reach the CA-server any more until the certificate has to be refreshed. But (and that is what you are refering to): The spoke should check the CRL for revoked certificates. And this CRL is controlled by the CA. But the CRL doesn't have to be stored on the CA. It can also be published for example on a publicly reachable Web-server.


Sent from Cisco Technical Support iPad App

[Ruterford]

Thanks for you response!

Another question - what if I deploy them all using PSK and then migrate them over to PKI?

So CA will be accessible initially via PSK based tunnels, and I will be able to enroll the spokes using this.

Then I will just add another crypto isakmp policy on both HUB and spoke with rsa-signature based authentication and delete the one with PSK on spokes one by one until I am done.

Main question here if I can have both authentication methods (PKi and PS) available at the same time on both HUB and Spokes via different crypto isakmp policies, so I will be migrating them remotely, sitting at one of the HUB locations andd SSHing into the spokes via PSK based tunnels.

Thanks!

[Karsten Iwen · Accepted solution]

That way of implementation is also not uncommon. You can have both methods configured at the same time. If both methods are in place at the same time, the responder of the session will decide based on the highest ISAKMP-policy-priority (which is the lowest configured value in the policy).

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni