Most of the IPsec tunnels I see configured, both in labs and in the real world, rely on relatively weak preshared keys to establish
the initial secure ISAKMP channel for key exchange between the IPsec peers (see my IPsec quick and dirty article for an example
configuration). A much stronger solution is to use public/private key pairs distributed by a secure Public Key Infrastructure (PKI)
Certificate Authority (CA). Unfortunately, deploying an enterprise PKI is no small undertaking, and many engineers are
understandably hesitant about tying any aspect of network connectivity to the functionality of unrelated servers or services.
Fortunately, IOS allows for a comfortable middle ground, using manually distributed RSA encryption keys on routers. The 12.4T
documentation has a pretty clear run-down of the steps required for such a setup. The example in this post will create an IPsec
tunnel between R1 and R3 in the following topology.
First, we need to generate an RSA public/private key pair on both of the endpoint routers.
If this is your first time creating an RSA keypair on the router, you may see a log message indicating that SSH has been enabled.
RSA keys are also used for securing SSH connections.
We can view the public key in our new keypair with the show crypto key mypubkey rsa command:
http://packetlife.net/blog/2009/jan/14/isakmp-associations-using-rsa-keys/ Page 1
Usage: General Purpose Key
Key is not exportable.
Key Data:
305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00B000A8 22C680DC
AC788B8D 536BFF8A 999F7905 8F6D6878 73C07ECC 2BB2478A ACF270DB 08FF854F
99827407 294C63C4 1B5E9EBB CD3277E3 88A48EFD 033F3806 C9020301 0001
Note that I've neglected to properly configure the clock on the routers in my lab; when creating crypto keys in the real world, you
want to first ensure the router's clock is accurate.
Both routers now have unique public and private keys. For these to be useful, we need to exchange the public keys between the
routers so that R1 has a copy of R3's public key and vice versa. To do that, we create a public key chain on each router and
manually copy the keys over.
At this prompt you can simply copy the key from the output of R3's terminal into R1's terminal. End by entering quit.
We can confirm that the key was successfully entered on R1 by inspecting its public key chain:
Note that the hex string above exactly matches that in the output of show crypto key mypubkey rsa R3 on R3. This verifies
that we have correctly copied its public key.
Repeat this configuration for R3, copying R1's public key to R3, to complete the key exchange.
http://packetlife.net/blog/2009/jan/14/isakmp-associations-using-rsa-keys/ Page 2
With the RSA keys settled, we can move on to the ISAKMP and IPsec configurations. Creating an ISAKMP profile to use the RSA
keys is almost indentical to one which uses a preshared key, except we specify RSA encryption as the authentication type instead
of pre-shared.
At this point, you might encounter the following system message, especially if performing this configuration on a Dynamips lab:
This message warns that hardware RSA encryption is unavailable on the platform, and can be safely ignored in our case.
We can verify the creation of our ISAKMP policy with show crypto isakmp policy:
I'll resist diving into the remainder of the IPsec configuration here, but the following is an example configuration for R1 (you can
also reference the complete R1 and R3 configs attached at the end of this article):
Once the configurations have been completed, you can inpsect the ISAKMP and IPsec security associations with show crypto
isakmp sa and show crypto ipsec sa, respectively:
interface: Tunnel0
http://packetlife.net/blog/2009/jan/14/isakmp-associations-using-rsa-keys/ Page 3
Crypto map tag: Tunnel0-head-0, local addr 10.0.12.1
• R1.txt
• R2.txt
• R3.txt
Posted in Security
http://packetlife.net/blog/2009/jan/14/isakmp-associations-using-rsa-keys/ Page 4