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:

CCP-Lab8-06182014

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 11.11.11.11/32 and 3.3.3.3/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 11.11.11.11 to 3.3.3.3 and vice versa is protected.

Configuration solutions cont’d

Task #2

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 111.111.111.111 to 22.22.22.22
remark CCP_ACL Category=2
remark IPSec Rule
deny ip 11.11.11.11 0.0.0.0 3.3.3.3 0.0.0.0
permit ip host 111.111.111.111 host 22.22.22.22
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 3.3.3.3 0.0.0.0 11.11.11.11 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 11.11.11.11 0.0.0.0 3.3.3.3 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 3.3.3.3 0.0.0.0 11.11.11.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).

Task #3

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 3.3.3.3 cannot ping 11.11.11.11.

You will also find out that 11.11.11.11/32 is not in the routing table of RTR3. When you dig deeper, you will discover (or remember) that 11.11.11.11/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 11.11.11.11/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 11.11.11.11 host 3.3.3.3
 permit ip host 11.11.11.11 any
 route-map NAT_RMAP permit 10
 match ip address NAT_EXEMPT_ACL
 no ip nat inside source static 11.11.11.11 192.168.12.11
 ip nat inside source static 11.11.11.11 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 11.11.11.11 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.

Awesome!

Summary

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.

Further reading