Hi there and welcome back to this series on the Cisco Configuration Professional tool. In the last article, we began configuring Lab #8, which deals with setting up a site-to-site VPN tunnel between RTR1 and RTR3. We got through the VPN wizard on RTR1 and in this article, we will be continuing with our configuration by reviewing the configuration sent to RTR1, configuring RTR3 and also testing our tunnel.
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.
Configuration solutions cont’d
In the last article, we saw that the configuration sent to RTR1 was 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
Review this configuration carefully and you will see that CCP has created an ACL to match VPN traffic (ACL 101), a second ACL to match return traffic in the VPN tunnel (ACL 103) and a third ACL to match the IP address of the remote peer (ACL 102). It then edited our firewall rules so that our VPN traffic is not affected. It did this by assigning a pass action to VPN protocols from 192.168.23.3 (ACL 102 matched by class-map SDM_VPN_PT) and assigning an inspect action to the return traffic of our VPN tunnel (ACL 103 matched by class-map sdm-cls-VPNOutsideToInside-1). Also, because we asked CCP to edit our NAT rules, it used route-maps to prevent our VPN traffic from being ‘natted’.
When our configuration has been delivered, we are taken to the Edit Site to Site VPN tab where we see the result of our configuration, as shown below.
However, we are not yet done on router RTR1. We still have a default IKE policy that has a higher priority than the one we configured. We can fix this by navigating to Configure > Security > VPN > VPN Components > IKE > IKE Policies.
I can either reduce the priority of the CCP default IKE policy (the one that currently has a priority of 1) or I can delete it completely. I will delete it using the Delete button.
The command to delete it is very simple:
no crypto isakmp policy 1
We are now done with this side of our VPN tunnel. We also need to perform similar steps on RTR3. There are two ways to go about this: configure RTR3 through CCP or use the Generate mirror button in the Edit Site to Site VPN tab to generate the configurations for RTR3 as shown below:
Since we already have RTR3 discovered, I will use the CCP wizard to configure the VPN tunnel on that router. The configuration to be sent to RTR3 is as shown below:
access-list 100 remark CCP_ACL Category=4 access-list 100 remark IPSec Rule access-list 100 permit ip 184.108.40.206 0.0.0.0 220.127.116.11 0.0.0.0 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.12.1 set transform-set MYSET set peer 192.168.12.1 match address 100 exit interface FastEthernet0/0 no crypto map crypto map SDM_CMAP_1 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
After the commands were delivered to RTR3, for some reason, CCP lost connection to that router and I had to rediscover it. Also, another thing to note here is that I didn’t have to delete the CCP default IKE policy on RTR3 since it will never be used: both VPN peers must agree on the same IKE policy and RTR1 does not have that CCP default IKE policy anymore (we deleted it).
We have come to the moment of truth: will our tunnel come up and function correctly? We can use the Test Tunnel feature of CCP to test our tunnel.
Notice that the status of the tunnel is still down and that is why the Clear Connection button is greyed out. I will now click on the Test Tunnel button which brings up the VPN Troubleshooting dialog box shown below.
Clicking on the Start button should begin the VPN troubleshooting and when that is done, you will get a dialog box similar to what is shown below:
My VPN troubleshooting report is shown below. It tells me that the VPN failed because even though the RSA signature authentication method has been configured, there are no digital certificates present on the device.
But I know this is not true because I have digital certificates on both devices. We can confirm that CCP knows about those certificates by navigating to Configure > VPN > Public Key Infrastructure > Router Certificates.
So let’s go to the console and try to ping from there.
Notice that the tunnel is still not built. When you put your troubleshooting hat on, you will discover that 18.104.22.168 cannot ping 22.214.171.124.
You will also find out that 126.96.36.199/32 is not in the routing table of RTR3. When you dig deeper, you will discover (or remember) that 188.8.131.52/32 is not in the routing table because RTR1 is being NATted and therefore not advertising that network:
It means if we want our VPN tunnel to come up, we have to exempt our interesting traffic from going through NAT and also configure a route for 184.108.40.206/32 on RTR3.
Note: Even though CCP created NAT exemption for our VPN traffic, it created it on the wrong NAT rule.
The following configuration will be added on RTR1:
ip access-list extended NAT_EXEMPT_ACL deny ip host 220.127.116.11 host 18.104.22.168 permit ip host 22.214.171.124 any route-map NAT_RMAP permit 10 match ip address NAT_EXEMPT_ACL no ip nat inside source static 126.96.36.199 192.168.12.11 ip nat inside source static 188.8.131.52 192.168.12.11 route-map NAT_RMAP
The above configuration shows how to configure NAT exemption for static NAT translation on Cisco IOS. The following will be configured on RTR3:
ip route 184.108.40.206 255.255.255.255 192.168.12.1
Now, let’s try our ping again.
Note: I noticed that if you try to use the VPN Troubleshooting tool in CCP to test the tunnel before bringing it up via ICMP traffic from console, it still fails. However, after the tunnel is up, it works correctly. I wonder what command it uses to test the tunnel.
We can also check our ISAKMP and IPSEC SAs.
For completeness’ sake, let’s ping from RTR3.
It’s also a good idea to test is if the tunnel will come up if RTR3 is the initiator.
This brings us to the end of Lab #8 where we have configured a site-to-site tunnel between RTR1 and RTR3. We discovered that the NAT on RTR1 was affecting the VPN tunnel from coming up. Also, we found out that RTR3 did not have a route to the remote subnet to be protected. In the end, our tunnel came up and our ICMP traffic (ping) was protected by the VPN tunnel.
I hope you have found this article helpful and look forward to the next article in the series.
Exempting Static Translations in IOS NAT: http://www.packetu.com/2012/06/05/exempting-static-translations-in-ios-nat/
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