While working on some Cisco VPN labs on both Cisco IOS routers and the Cisco ASA running on GNS3, I discovered an “issue” that took me many hours of troubleshooting my configuration. I finally found a suggestion online which worked but I’m not sure it is properly documented anywhere. In this article, we will explore this issue I discovered and the workaround I used. If you know any other workaround, please be sure to add it to the comment section of this article.

The Issue

I found out that if you use a VPN client installed on the host GNS3 system to connect to a remote access VPN configured on a router or ASA running in GNS3, the VPN session will be terminated quite all right but packets will not go through that tunnel. This also happens in the case of SSL VPN when you try to connect to the SSL VPN service from the host system. Let’s see this in action, using the GNS3 topology below:

Note: I’m using GNS3 0.8.6 installed on a Windows 8 Operating operating System system and this is the only version I have confirmed this on. I have not tested on other GNS3 versions or operating systems so, if it works for the version you are running, do let us know.

In the set up above, I have configured IPsec remote access VPN on the ASA enabled on the outside interface, i.e., the interface connected to the switch. The router is connected on the inside interface of the ASA and we will use this for testing purposes. I have added three clouds to the topology: one for my loopback interface; the second is my Wi-Fi NIC; and, finally, I have a Virtual Box NIC. All the clouds are connected to the same VLAN on the switch and we will test them one after the other so that there is no conflict. The configuration on the ASA is as follows:

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 41.1.1.1 255.255.255.252
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.10.1 255.255.255.0
!
access-list SplitTunnel_ACL standard permit 192.168.10.0 255.255.255.0
ip local pool RA-POOL 192.168.10.50-192.168.10.60 mask 255.255.255.0
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
group-policy IntenseSchool-RA-VPN internal
group-policy IntenseSchool-RA-VPN attributes
 vpn-tunnel-protocol ikev1
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SplitTunnel_ACL
username vpnuser password vpnuser
username vpnuser attributes
 vpn-group-policy IntenseSchool-RA-VPN
tunnel-group IntenseSchool-RA-VPN type remote-access
tunnel-group IntenseSchool-RA-VPN general-attributes
 address-pool RA-POOL
 default-group-policy IntenseSchool-RA-VPN
tunnel-group IntenseSchool-RA-VPN ipsec-attributes
 ikev1 pre-shared-key intenseschool
!

The router has an IP address of 192.168.10.2 and we should be able to ping that IP address when the VPN session has been successfully terminated.

We will begin with my loopback interface. I will configure the IP address of that interface as 41.1.1.2/30.

In the screenshot below, you can see that I can ping the ASA’s outside interface.

Now I will connect to the VPN using my Cisco VPN client. Notice that I have already configured the VPN group as shown below:

As shown below, I have successfully connected to the VPN tunnel using the vpnuser user to authenticate.

Let’s take a look at the statistics shown below. Pay special attention to the Bytes and Packets sections.

Notice that the Sent and Encrypted fields are increasing but the Received and Decrypted fields remain at zero. This shows that, even though the VPN client seems to be sending packets through the tunnel, it is not receiving anything back. To further prove this point, I will try to ping the router while also enabling logging on the ASA.

As you can see from the two screenshots above, not only did the ping fail, the ping packets never got to the ASA. All we see are VPN keepalive packets between the Cisco ASA and the VPN client.

When I discovered this, I thought maybe there was an issue with the loopback interface, so I decided to use another interface: my Wi-Fi interface. I will show you that the same thing happens. First, we will remove the 41.1.1.2/30 IP address from the loopback interface and then assign it to our Wi-Fi NIC.

Hint: You must be connected to an access point or some other wireless connection for your Wi-Fi NIC to be enabled.

Hint: If you are having issues pinging the ASA after this IP address switch, check your system’s routing table using the route print command and remove the offending route to 41.1.1.1 going through the loopback.

Again, I will terminate my VPN session and see if I can ping the router on 192.168.10.2.

As shown in the screenshots above, again, our ping is not successful, nor does it get to the Cisco ASA.

The Solution

After much troubleshooting using different IOS versions and banging of head, I read someone say somewhere that he used a virtual machine instead of his loopback address so I decided to give it a shot. I will remove the 41.1.1.2/30 IP address from my Wi-Fi interface and assign it to my virtual machine.

Hint: You don’t have to set the Virtual-Box interface on the host to 41.1.1.2/30. You can use “Host-only Adapter” on the virtual machine interface and set the virtual machine’s IP address itself to 41.1.1.2/30.

Now, I will connect to the VPN and test connectivity using ping.

The ping goes through! Not only that, we see the packets on the ASA, as highlighted below:

Finally, notice that the Bytes Received and Sent fields increase, as do the Packets Encrypted and Decrypted fields.

There you have it. I don’t know why it happens like this but, if anyone knows, please share. In case you are thinking that the VPN client on my Windows 8 OS is the one that is faulty, I can tell you that is not the case because I use it normally for real-world VPN connections and it works.

If you try it with an SSL VPN service, you will notice that, after you receive the certificate warning in the web browser, the next page that should be the login screen is not displayed and you will just get No data received (Chrome) or Page cannot be displayed (Internet Explorer).

Summary

In this article, we have explored the issue that GNS3 has with remote access VPN sessions when using the GNS3 host interfaces to terminate the VPN. We saw that the workaround is to use a virtual machine for VPN testing.

I hope this article saves someone a lot of ‘false’ troubleshooting time.

Reference

VPN client connection to GNS3 router no ping pass: https://supportforums.cisco.com/discussion/11743591/vpn-client-connection-gns3-router-no-ping-pass