Currently my studies have taken me on an adventure into the wonderful world of Cisco Security. I am studying for the 300-209 (SIMOS) certification exam which is VPN technologies including DMVPN, FlexVPN, and a few other flavors of VPN.I find it interesting that so many try very hard to avoid having to implement security because its hard, or because that’s not how they did it at their old job. In this post I am going to go over the simple process of adding RSA Signatures into a DMVPN phase 3 deployment.
Below is the high level topology I’ve been using for my DMVPN labs:
As can been seen, its a single hub deployment with two spokes (one with two routers and the other with a single router). I am utilizing two separate tunnel types to allow for the addition of another hub (Datacenter) later on down the road. For this post, addressing doesn’t matter too much as I am only going over the parts that are required for RSA Signatures to work.
Lets start with the basics of what’s already in place:
- NTP (Time) – All routers are already configured with NTP to have synchronized time. This is important for certificates as they have Valid From and Valid To fields that are enforced.
- DMVPN Phase 3 with Pre-Shared Keys (PSKs)
- This includes all parts from IKEv2 Policies, all the way to tunnel protection being configured. Maybe another time I’ll go over my lab but there’s a good amount of posts about DMVPN already so not sure it’s really worth while.
- Both on the FVRF (Front Door VRF) and Internal VRF
- PKI Infrastructure
- I setup a single Signing CA for my lab environment with auto enrollment to allow for easy certificate signing on my routers.
Now that what’s in place has been gone over, lets see if things actually working.
As can be seen, from DMVPNR2 (which is the DMVPN hub for the second tunnel), both remote locations are currently using PSKs and sessions are in a healthy state.
And now the fun part, actually authenticating the CA, getting a signed RSA signature, and utilizing it with the current DMVPN configuration! As note, any configurations done on a device will be in italics, and any variable that can be changed will be in red like the following: hostname Branch2-R1
1.Generate a RSA keypair for your router:
crypto key generate rsa modulus 2048 label Branch2-R1.dmpvn.com
2.Configure the CA trustpoint:
crypto pki trustpoint TrustedCA
enrollment url http://10.0.0.6
revocation-check crl none
3. Authenticate CA
crypto pki authenticate TrustedCA
4.Enroll with the CA
crypto pki enroll TrustedCA
The following fields will need to be filled out:
- Password – This is needed to revoke the certificate
- The option to include the Serial number in the subject name (Yes or No)
- The option to include IP address in the subject name (Yes or No)
- If yes – it must be configured
- Accept the request to a certificate from CA (Yes or No)
The certificate request process runs in the background and syslogs are shown when the certificate is received from the CA. The command show crypto pki certificate verbose TrustedCA can be utilized to view the certificate fingerprints for the configured CA.
5. Create a certificate map
crypto pki certificate map CMAP 10
issuer-name co CA
For my lab environment, I simply created a certificate map that looks for the word “CA” in the issure-name field of the certificate. This can be a very specific variable to allow for strict control over what exactly is allowed for authentication.
6. Create / Modify IKEv2 profile for RSA Signature based authentication
crypto ikev2 profile FVRF-IKEv2
identity local dn
match certificate CMAP
authentication local rsa-sig
authentication remote rsa-sig
pki trustpoint TrustedCA
It’s important to make sure you add the authentication local and remote commands for rsa-sig, without them PSKs will still be used! In addition, if the profile is being reused and had the configuration for PSKs, the command for PSKs is NOT overwritten when the rsa-sig command is issued and need to be removed with the “no authentication remote pre-share” if it is no longer desired to utilize PSKs for IKEv2 SAs.
And that’s it! Any new SA for DMVPN IPSEC tunnels will be created utilizing RSA. Now, the way Cisco IOS maintains security SAs, they will be active with their negotiated security settings until the SA is renegotiated (if supported) or torn down. This means the old sessions (if RSA was added to an already configured deployment) will have been setup with PSKs. The easiest way to “refresh” these SA’s is to flap the tunnel. Extreme caution should be used when pushing changes to production environments, and as always test in your lab first!