We are configuring a switch from preshared key IKEv2 authentication to authentication using a digital certificate. A router named SERVER has two additional functions: a time server and a CA server.
Configuration steps before switching
Change the previous configuration so that routers ROUTER-A and ROUTER-B use digital certificates and discard the preshared key. Start with basic configuration on all routers to set up a CA server and retrieve digital certificates.
! hostname SERVER ! interface f0/0 ip address 10.2.2.2 255.255.255.0 no shutdown ! ip route 0.0.0.0 0.0.0.0 10.2.2.1 ! ntp master !
In a production environment, we will ensure that the time is accurate, but for our labs, this is possible. It is important for the router to agree on the right time, regardless of the current time.
! hostname ROUTER-A ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 no shutdown ! interface Serial5/0 ip address 188.8.131.52 255.255.255.0 no shutdown ! ip route 0.0.0.0 0.0.0.0 184.108.40.206 ! ntp server 10.2.2.2 !
! hostname ROUTER-B ! interface FastEthernet0/0 ip address 10.2.2.1 255.255.255.0 no shutdown ! interface Serial5/0 ip address 220.127.116.11 255.255.255.0 no shutdown ! ip route 0.0.0.0 0.0.0.0 18.104.22.168 ! ntp server 10.2.2.2 !
PC routers have the simplest configuration:
! hostname PC ! interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.0 no shutdown ! ip route 0.0.0.0 0.0.0.0 10.1.1.1 !
Now verify our connectivity. We can verify time synchronization on ROUTER-A and ROUTER-B. If we can, we can continue. For example, ROUTER-A:
ROUTER_A# ROUTER_A#show ntp ass address ref clock st when poll reach delay offset disp *~10.2.2.2 127.127.7.1 8 118 1024 377 12.103 -59951. 0.070 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured ROUTER_A#
We can see that we are in sync, so we can continue configuring.
Now let's focus on SERVER again and generate an RSA key pair for the digital certificate that this CA will use:
cry key gen rsa gen lab CA_SERVER mod 2048
We named the key pair CA_SERVER, and you want the key to be 2048 bits long. Next, we use the minimum settings to create CA authorizations:
crypto pki server CA_SERVER issuer-name CN=Popravak Root CA grant auto no shutdown
We named the CA and made sure it issued the certificate without any intervention. Finally, we activate this CA. Before proceeding, we need to make sure that the HTTP server on the CA is activated, as clients will use the HTTP protocol when communicating with the CA:
! ip http server !
This is a very basic setting for our CA server. Now, let's visit our friend ROUTER-A. We also need the RSA key pair on this router to obtain the certificate that will be issued by our CA server:
Issue Certificates to Router-A
cry key gen rsa gen lab ROUTER_A_CA mod 2048
Now let's create a trust point. It is the structure that describes our communication with the Certification Authority. In our case:
crypto pki trustpoint ROUTER_A_CA enrollment url http://10.2.2.2:80 subject-name CN=ROUTER_A.popravak.local, O=Popravak Inc revocation-check none rsakeypair ROUTER_A_CA
We have specified a name for the trust point and the URL that will be used for certificate requests and retrieval. We also explained the information to be encoded in the certificate. This is given as x509, and we only need the FQDN (CN or Common Name field) and organization name (O field) of the router. We do not want to check if the certificate is marked revoked by the CA because this is a lab environment. Finally, we specify the generated RSA key pair.
Now, there are two things to do. First, we must authenticate to the CA. ** This basically means that we connect to the CA and retrieve its certificate.
cry pki authenticate ROUTER_A_CA
We look forward to:
Trustpoint CA certificate accepted.
Once we have a CA certificate and public key, we can register the CA. That's a good statement. We want the CA to issue us a certificate:
cry pki enroll ROUTER_A_CA
This is what we want to see:
%PKI-6-CERTRET: Certificate received from Certificate Authority
Now we have all the functionality required to switch from pre-shared key authentication to certificate-based authentication. Of course, for router ROUTER-A. These exact steps also need to be performed on ROUTER-B. In addition to what we have typed on ROUTER-B so far, we also summarize the steps required to obtain a certificate:
Issue Certificate to Router-B
! cry key gen rsa gen lab ROUTER_B_CA mod 2048 ! crypto pki trustpoint ROUTER_B_CA enrollment url http://10.2.2.2:80 subject-name CN=ROUTER_B.popravak.local, O=Popravak Inc revocation-check none rsakeypair ROUTER_B_CA ! cry pki authenticate ROUTER_B_CA ! cry pki enroll ROUTER_B_CA !
We have reached the VPN setup section. Last
Change IKEv2 settings
Before changing the IKEv2 settings, let's look at the old IKEv2 configuration file:
Old IKEv2 Profile
crypto ikev2 profile IKEv2_PROFILE match identity remote address 22.214.171.124 255.255.255.255 identity local address 126.96.36.199 authentication remote pre-share authentication local pre-share keyring local IKEv2_KEYRING
If the remote peer identifies itself with an IP address of 188.8.131.52, we will use the IP address of 184.108.40.206, and both parties will authenticate with pre-shared keys stored in the specified key ring, this IKEv2 profile will be triggered. Before changing this profile, let's first create an IKEv2 proposal. Let's go back to ROUTER-A.
crypto ikev2 proposal IKEv2_PROPOSAL encryption aes-cbc-256 aes-cbc-192 3des integrity sha512 sha256 md5 group 14 5 2
crypto ikev2 policy IKEv2_POLICY proposal IKEv2_PROPOSAL
crypto pki certificate map IDENTITY_MAP 10 subject-name co o = popravak inc
IKEv2 New Profile
crypto ikev2 profile IKEv2_PROFILE match certificate IDENTITY_MAP identity local dn authentication remote rsa-sig authentication local rsa-sig pki trustpoint ROUTER_A_CA
Now, if we receive a certificate that matches what is specified in the certificate map, this profile will be used. We use certificates to identify ourselves, and both sides now use rsa-sig type authentication, which is digital certificate authentication. We also list the trust points we want to use. Our certificate mapping is now used to trigger profiles. Therefore, if the certificate mapping requirements are met, our profile will trigger, and we only want the certificate to contain the name of our organization. Basically, if we receive a certificate with the organization name "Popravak Inc", it will be used.
IPsec settings on ROUTER-A remain unchanged:
! crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac mode tunnel ! crypto ipsec profile IPSEC_PROFILE set transform-set IPSEC_TRANSFORM1 set ikev2-profile IKEv2_PROFILE !
Now we are ready to complete the ROUTER-A configuration by configuring the tunnel interface and completing the routing:
interface Tunnel0 description === SVTI INTERFACE === ip address 192.168.12.1 255.255.255.0 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source Serial5/0 tunnel mode ipsec ipv4 tunnel destination 220.127.116.11 tunnel protection ipsec profile IPSEC_PROFILE ! ip route 10.2.2.0 255.255.255.0 Tunnel0
So far, we have been preparing ROUTER-A. A similar configuration exists on ROUTER-B:
crypto ikev2 proposal IKEv2_PROPOSAL encryption aes-cbc-256 aes-cbc-192 3des integrity sha512 sha256 md5 group 14 5 2 ! crypto ikev2 policy IKEv2_POLICY proposal IKEv2_PROPOSAL ! crypto pki certificate map IDENTITY_MAP 10 subject-name co o = popravak inc ! crypto ikev2 profile IKEv2_PROFILE match certificate IDENTITY_MAP identity local dn authentication remote rsa-sig authentication local rsa-sig pki trustpoint ROUTER_B_CA ! crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac mode tunnel ! crypto ipsec profile IPSEC_PROFILE set transform-set IPSEC_TRANSFORM1 set ikev2-profile IKEv2_PROFILE ! interface Tunnel0 description === SVTI INTERFACE === ip address 192.168.12.2 255.255.255.0 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source Serial5/0 tunnel mode ipsec ipv4 tunnel destination 18.104.22.168 tunnel protection ipsec profile IPSEC_PROFILE ! ip route 10.1.1.0 255.255.255.0 Tunnel0
After the tunnel starts, we can verify that the peer has authenticated using a digital certificate:
ROUTER_A# ROUTER_A#show cry ikev2 sa IPv4 Crypto IKEv2 SA Tunnel-id Local Remote fvrf/ivrf Status 1 22.214.171.124/500 126.96.36.199/500 none/none READY Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:14, Auth sign: RSA, Auth verify: RSA Life/Active Time: 86400/27741 sec IPv6 Crypto IKEv2 SA ROUTER_A#
The last thought may not be related to IPSec. The command under the router interface is "no ip route-cache". Without this command, no traffic will be forwarded through the tunnel. This may be related to IOS images on the dynamips platform. But I'm sure it won't be a problem.