Hi there and welcome back to this series on the Cisco Configuration Professional tool. In the last article, we configured a lab on digital certificates with our RTR2 acting as our IOS Certificate Server, and our two other routers, RTR1 and RTR3, enrolling for digital certificates on RTR2.
In this article, we will build on that lab by configuring a site-to-site VPN tunnel between RTR1 and RTR3 using digital certificates for authentication. Our network diagram is shown below:
The configuration tasks for Lab #8 are as follows:
* Confirm that the digital certificates on all routers are still valid and active.
* Configure a site-to-site VPN tunnel between RTR1 and RTR3 to protect all IP traffic between 126.96.36.199/32 and 188.8.131.52/32. ISAKMP policy settings: digital certificates, MD5, 3DES. IPSEC transform set: ESP-3DES and ESP-MD5-HMAC.
* Test your VPN tunnel: Ensure that ICMP traffic sourced from 184.108.40.206 to 220.127.116.11 and vice versa is protected.
The first task requires us to confirm that our digital certificates are still valid. This step is even more important because we are using GNS3. I think the new version of GNS3 (0.8.6) gives you the option to save your crypto keys but previous versions did not. It means, in previous versions, we will probably lose our crypto keys when we restart our GNS3 devices (there is a workaround). It also means that our certificate server on RTR2 will be disabled because the RTR2_CA RSA keypair is missing.
There are a few things you need to do to ensure that your digital certificate configuration works again. First, you want to make sure your clock is set because after we restart GNS3 devices, not only do we lose crypto keys, we also lose time settings.
Next, you will want to recreate your certificate server key on RTR2, i.e. the RTR2_CA RSA keypair.
You will notice from above that after I generated the RSA key (the label RTR2_CA is important!) the Certificate server became enabled.
On our two other routers, RTR1 and RTR3, you want to ensure that the clocks have been synchronised via NTP. Also, you may see two messages on the router’s console: PKI-3-POLLCACERT and PKI-3-POLLROUTERCERT as shown below:
I’m not sure but maybe if you wait long enough, the router will poll the certificates and get them restored. However, what I did was I removed the RTR2_CA trustpoint completely, reconfigured it, authenticated the CA server again and then waited for the digital certificate to be automatically renewed.
At the end of this task, you should have three certificates (two certificates if there is no self-generated certificate) on RTR1 and RTR3, and two certificates (one certificate if there is no self-generated certificate) on RTR2.
In truth, this task contains the bulk of the configuration for this lab and we would not have had as much to do in task #1 if we were using real devices. To set up VPN through CCP, we navigate to Configure > Security > VPN.
Hint: The VPN Design Guide is a helpful tool that will determine what type of VPN tunnel you should configure based on the answers you give to certain questions asked. You should check it out in your spare time.
In this lab, we will be configuring Site-to-Site VPN and as usual, there is a wizard to accomplish this.
We will be using the first wizard so I will leave the default selected option and click on Launch the selected task.
We are presented with two options: Quick setup or Step by step wizard. You can view the defaults that will be applied if you used the Quick setup option.
As shown above, CCP will configure two IKE policies, one with digital certificates and the other using pre-shared keys. This option would have been perfect for us except our task requires that SHA be used as opposed to MD5. Therefore, I will proceed with the Step-by-step wizard.
From the above screen, I have selected Fa0/1 as the interface to use for my VPN connection. I have also specified the Fa0/0 interface IP address of RTR3 as the remote peer. By default, Digital Certificates is selected for authentication so I can click on the Next button.
On the screen shown above, we can configure our IKE proposals. CCP contains a default proposal that does not suit my purposes so I will create one that does.
The only challenge here is that CCP’s default IKE proposal has a priority of 1 and I cannot change that priority here. What we can do is continue with the wizard and then delete/reconfigure the CCP default policy when we are done.
On the next screen, I need to configure a transform set. CCP also includes a default transform set but since it does not meet my requirements, I will create another transform set by clicking on the Add button.
You can use the Show Advanced button to configure more options like tunnel or transport mode and AH. When I’m done creating my transform set, I can click on the OK button and the transform set I created is now selected.
On the next screen, we will match our interesting traffic. We have the option of configuring a local/remote subnet or we can use an ACL to match our traffic.
The next screen gives us a summary of our configuration and also allows us to test the VPN after configuring. Since RTR3 is not set up yet, we will leave that test option unchecked.
One of the benefits of using CCP is that it catches things you may have missed. From the screenshot below, we can see that CCP identified NAT rules on the router and it asks you if you want to convert those NAT rules so that your VPN traffic is not affected. I will click Yes and we will see later if this helps us or not.
The configuration to be sent to the router is as follows:
ip access-list extended SDM_ESP remark CCP_ACL Category=1 permit esp any any exit no ip access-list extended NAT-ACL1 ip access-list extended NAT-ACL1 remark Match 18.104.22.168 to 22.214.171.124 remark CCP_ACL Category=2 remark IPSec Rule deny ip 126.96.36.199 0.0.0.0 188.8.131.52 0.0.0.0 permit ip host 184.108.40.206 host 220.127.116.11 exit ip access-list extended SDM_AH remark CCP_ACL Category=1 permit ahp any any exit access-list 103 remark CCP_ACL Category=0 access-list 103 permit ip 18.104.22.168 0.0.0.0 22.214.171.124 0.0.0.0 access-list 102 remark CCP_ACL Category=128 access-list 102 permit ip host 192.168.23.3 any access-list 101 remark CCP_ACL Category=4 access-list 101 remark IPSec Rule access-list 101 permit ip 126.96.36.199 0.0.0.0 188.8.131.52 0.0.0.0 class-map type inspect match-any SDM_ESP match access-group name SDM_ESP exit class-map type inspect match-any SDM_AH match access-group name SDM_AH exit class-map type inspect match-any SDM_VPN_TRAFFIC match protocol isakmp match protocol ipsec-msft match class-map SDM_AH match class-map SDM_ESP exit class-map type inspect match-all SDM_VPN_PT match access-group 102 match class-map SDM_VPN_TRAFFIC exit class-map type inspect match-all sdm-cls-VPNOutsideToInside-1 match access-group 103 exit policy-map type inspect ccp-permit no class type inspect TEMP_ICMP no class type inspect ccp-cls-ccp-permit-1 no class type inspect SDM_EIGRP_PT class type inspect SDM_VPN_PT no drop pass exit class type inspect TEMP_ICMP no drop pass exit class type inspect ccp-cls-ccp-permit-1 no drop inspect exit class type inspect SDM_EIGRP_PT no drop pass exit exit policy-map type inspect ccp-policy-allow-icmp class type inspect sdm-cls-VPNOutsideToInside-1 no drop inspect exit exit crypto ipsec transform-set MYSET esp-md5-hmac esp-3des mode tunnel exit crypto map SDM_CMAP_1 1 ipsec-isakmp description Tunnel to192.168.23.3 set transform-set MYSET set peer 192.168.23.3 match address 101 exit interface FastEthernet0/1 no crypto map crypto map SDM_CMAP_1 exit route-map SDM_RMAP_1 permit 1 match ip address NAT-ACL1 exit interface Loopback1 no ip nat inside exit interface Loopback2 no ip nat inside exit interface FastEthernet0/1 no ip nat outside exit do clear ip nat translation forced no ip nat inside source list NAT-ACL1 pool NAT-POOL1 ip nat inside source route-map SDM_RMAP_1 pool NAT-POOL1 interface Loopback1 ip nat inside exit interface Loopback2 ip nat inside exit interface FastEthernet0/1 ip nat outside exit crypto isakmp policy 2 authentication rsa-sig encr 3des hash md5 group 2 lifetime 86400 exit crypto isakmp policy 1 authentication rsa-sig encr 3des hash sha group 2 lifetime 86400 exit
Let’s pause on this lab for now as it is already getting too long. In the next article, we will begin by analysing the configuration sent to the device by CCP and then configure RTR3 and bring our VPN tunnel up.
In this article, we have begun the configuration for Lab #8 which deals with configuring a Site-to-Site VPN tunnel between RTR1 and RTR3. The first task required us to confirm that our digital certificates were still valid. We found a way to re-enable those certificates in case we are using GNS3. We then went on to configure RTR1 for our site-to-site VPN tunnel.
I hope you have found this article interesting and look forward to the continuation.
[FIXED] https/ssh rsa key lost after restart: http://forum.gns3.net/topic5374.html
Configuration Professional: Site-to-Site IPsec VPN Between Two IOS Routers Configuration Example: http://www.cisco.com/c/en/us/support/docs/cloud-systems-management/configuration-professional/113337-ccp-vpn-routerA-routerB-config-00.html