Implementing and Verifying an IPsec Site-to-Site VPN in Cisco IOS Devices
In this section, we take the information from our planning in the previous section to implement, verify, and troubleshoot the VPN using a combination of Cisco Configuration Professional (CCP) and the command-line interface (CLI).
In earlier chapters, we discussed important resources such as Network Time Protocol (NTP) and certificate authorities (CA). Because we chose to implement RSA-Signatures for this customer, we want to implement NTP as one of our first steps. This is because when exchanging certificates during IKEv1 Phase 1, if R1 thinks the year is 2040, and the certificate it just received from R2 is listed as being valid from 2012 through 2016, R1 will reject the certificate as not being valid, and IKEv1 Phase 1 will not end well. (If IKEv1 Phase 1 does not work, IKEv1 Phase 2 does not have a chance either.) So for this implementation, we use a service provider on the simulated Internet (in our customer’s topology) that will provide both NTP and CA services at the address of 3.3.3.3 (in the simulated Internet portion of the topology diagram).
Let’s synchronize the time on both R1 and R2 with the service provider’s NTP server, as shown in Figure 7-2.
The same process would be repeated for the other router as well. NTP can take up to 15 minutes to synchronize. Another item to be aware of is that NTP servers deliver time based on coordinated universal time (UTC), and setting the local time zone on your router is important so that correct offset from UTC is reflected on the local router. To verify that the time is synchronized with the time server, at the CLI of the router we can use the commands shown in Example 7-1.
Example 7-1 Verifying NTP Status
R1# show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**24
reference time is D2C15194.71E5E637 (14:11:32.444 UTC Wed Jan 18 2012)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000085 s/s
system poll interval is 64, last update was 1518 sec ago.
! Note the above indicates the time isn't synchronized.
! We can check to see if the router has the NTP server configured with the
! following:
R1# show ntp association
address ref clock st when poll reach delay offset disp
~3.3.3.3 .INIT. 16 - 64 0 0.000 0.000 16000.
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
! Based on this output, we know that it has information to use the 3.3.3.3
! server
! It may take anywhere from 5 to 15 minutes for
! the synchronization to happen. After verifying the configuration, and
! waiting about 5 minutes, we can then issue the verification commands
! again and see that the synchronization is complete.
R1# show ntp status
Clock is synchronized, stratum 3, reference is 3.3.3.3
nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**24
reference time is D2C15854.6F453DAE (14:40:20.434 UTC Wed Jan 18 2012)
clock offset is 0.0029 msec, root delay is 0.01 msec
root dispersion is 0.95 msec, peer dispersion is 0.06 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000097 s/s
system poll interval is 64, last update was 251 sec ago.
Our next task, in preparation for the IPsec, is to generate key pairs on R1 and R2, configure them to use a CA, have them authenticate the CA (get the root certificate), and then enroll with the CA (request their own identity certificates). The CA is at 3.3.3.3 and supports Simple Certificate Enrollment Protocol (SCEP). From R1 and R2, the process is the same, and the commands used for R1 are shown in Example 7-2.
Example 7-2 Preparing for and Obtaining Digital Certificates
! Specify the domain-name that will be included with the key pair you
! are about to generate
! Note: if you have already created a key-pair to be used with SSH
! you don't need to create a separate key-pair. You can use the same
! key pair for both purposes if desired.
R1(config)# ip domain name cisco.com
R1(config)# crypto key generate rsa
The name for the keys will be: R1.cisco.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
! The larger the key the better. Using a minimum length of 1024 is a best
! practice
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
! Specify the CA that you would like to use, and the URL to be used to
! reach that CA
R1(config)# crypto pki trustpoint CA
R1(ca-trustpoint)# enrollment URL http://3.3.3.3
R1(ca-trustpoint)# exit
! Request the root certificate through "authenticating" the CA
R1(config)# crypto pki authenticate CA
Certificate has the following attributes:
Fingerprint MD5: B1AF5247 21F35FE3 0200F345 7C20FBA0
Fingerprint SHA1: F5BB33E3 1CB5D633 0DF720DF 8C72CD48 E744CF5B
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
! Request an Identity certificate for this router, via SCEP and the
! "enroll" option
R1(config)# crypto pki enroll CA
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
! Specifying the challenge password that can be used in the event you need to
! ask the CA to revoke this certificate in the future
Password: SuperSecret!23
Re-enter password: SuperSecret!23
% The subject name in the certificate will include: R1.cisco.com
! The next 2 items are optional elements that may be included in the certificate
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose CA' command will show the fingerprint.
CRYPTO_PKI: Certificate Request Fingerprint MD5: E8E01D26 862C811C 32CB3FCF 858BAF5F
CRYPTO_PKI: Certificate Request Fingerprint SHA1: E3133B07 07DEA5FD BC6A1D64 DBC9F71F
3CACA767
%PKI-6-CERTRET: Certificate received from Certificate Authority
! We would repeat this process on the other router, R2
After we have digital certificates on both routers, we can configure the IKEv1 Phase 1 policy. This can be done in CCP by navigating to Configure > Security > VPN > Site-to-Site VPN, as shown in Figure 7-3.
Using the Launch the Selected Task button to continue, we choose the Step-by-Step Wizard (in contrast to Quick Setup), and then click the Next button. We have the opportunity to begin entering the information we collected earlier about the interfaces to use and the policies to implement, as shown in Figure 7-4.
Notice that this time, because of our policy, we select the Digital Certificates radio button instead of using pre-shared keys for the authentication. After clicking Next, we are presented with the default IKEv1 Phase 1 policy, which is built in to CCP. To add a new policy, click the Add button and enter the details for the IKEv1 Phase 1 policy per the plan, as shown in Figure 7-5.
After you click OK, highlight the new policy, and then click Next to advance to the IKEv1 Phase 2 policy information. Once there, click Add and enter the IPsec/IKEv1 Phase 2 options that we planned earlier, as shown in Figure 7-6.
Unfortunately, the options for setting up PFS for IKEv1 Phase 2 are not integrated in the wizard. Let’s finish the wizard, to confirm the ACL information, by clicking OK for the transform set, clicking the transform set to highlight it, and clicking Next to continue. In the next window, we specify which traffic to encrypt. Remember that this is from the local router’s perspective of outbound traffic that it should apply IPsec to. Figure 7-7 shows an example of implementing our crypto ACLs via the wizard.
On R1, the ACL matches on traffic from 172.16.0.0/16 that has a destination in the 192.168.0.0/24 network. The ACL on R2 must be a mirror image of the source and destination networks. When you click Next, a summary is provided, and then based on your preference settings in CCP, the actual commands about to be applied may be presented in a final window before you approve them to be delivered.
Example 7-3 shows the CLI implementation of the crypto policy for R1, including the PFS (which the wizard did not offer).
Example 7-3 CLI Implementation of the Crypto Policy for R1
R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encr aes 256
R1(config-isakmp)# group 5
R1(config-isakmp)# lifetime 3600
R1(config-isakmp)# authentication rsa-sig
R1(config-isakmp)# hash sha
! To verify the configuration:
R1# show crypto isakmp policy
Global IKEv1 policy
Protection suite of priority 1
encryption algorithm: AES - Advanced Encryption Standard (256 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #5 (1536 bit)
lifetime: 3600 seconds, no volume limit
! Note, that a show running-config, would only show configured items in the
! policy if they were different from the default. Here is a snippet from
! the show run:
crypto isakmp policy 1
encr aes 256
group 5
lifetime 3600
! Because the authentication and hash are using the defaults, they are not
! shown even though we put them in the configuration. (interesting to know)
! We won't need a pre-shared key, because we are using digital signatures/
! certificates for the IKEv1 Phase 1 authentication.
! Next we can create our transform-set, and crypto ACL, which will be
! placed inside the crypto map. The crypto map will be applied to the
! interface of the router.
! Transform set details the encryption and HMAC to use
R1(config)# crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
R1(cfg-crypto-trans)# exit
! Crypto ACL identifies which traffic (outbound) should be encrypted
R1(config)# access-list 100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0 0.0.0.255
! The crypto map contains the if/then statement to decide to encrypt or
! not to encrypt a packet on its way out
R1(config)# crypto map MYMAP 1 ipsec-isakmp
R1(config-crypto-map)# match address 100
R1(config-crypto-map)# set peer 209.165.201.1
R1(config-crypto-map)# set transform-set MYSET
! Here is the PFS part that we are adding manually, as the wizard didn't
! support this feature
R1(config-crypto-map)# set pfs group2
R1(config-crypto-map)# exit
! Applying the crypto map to the interface is what allows the entire IPsec
! function to be triggered. That is why it is important that the router
! has at least a default route (if not a more specific route) out of this
! interface to reach the remote network for which the router is providing
! IPsec support.
! When the router considers forwarding traffic out the interface, that is
! what triggers the decision to encrypt or not. If the traffic matches
! the crypto ACL in the crypto map, the router will encrypt the original
! packet, encapsulate the encrypted packet into a new packet with ESP as
! the L4 header, and the peer's global IP address as the new L3 header.
! If no IPsec SA (tunnel) is in place yet, this will also trigger the
! negotiations to build the tunnel, including the IKEv1 Phase 1 if it is not
! already in place.
R1(config)# interface GigabitEthernet1/0
R1(config-if)# crypto map MYMAP
R1(config-if)# exit
After the appropriate compatible configuration has been placed on R2, we should be able to encrypt traffic between the two networks using IPsec.