how can i test my vpn connection?

aaron.martinas · ‎11-09-2009

so recently i decided to test if ver 1.3.0.3 of the quickvpn client would work better with the 1.3.0.5 rvs4000 firmware. i loaded quickvpn to an xp pro computer (freshly built, i might add) and got to work. in order to test the connection, i attempted to piggy back off an unsecured wireless network. this network is on the same ISP network as i am.

i use dynamic DNS, and the unsecured wireless network could resolve my IP correctly, but for some reason i couldnt connect to my home network from the unsecured network. my router is set to respond to lan requests, but i couldnt ping it. my router passes HTTP traffic to a computer in my network, but i couldnt bring up the webpage. finally, my router responds with the router config page over port 443, and i couldnt bring that up.

so i used my ISP's dialup service to test. initially, as always, i had a million problems with the vpn client. systematically, i tried to resolve the issues. i installed the patch in the readme for quickvpn. i checked log files to see where stuff was failing. eventually, i could connect to the VPN, but would get that "remote gateway is not responding" crap. i know of a (poor) workaround for this which allows you to "finalize" the connection, but that workaround doesnt allow you to ping around in your network. sometime later, after randomly messing with settings, the tunnel would connect without the workaround. i have no idea what "fixed" this.

despite all this, my 28.8Kbps connection wouldnt allow me to do anything meaningful on my network. i couldnt connect to the router or to a server of mine (http or fileshare). the only thing i could do was ping internal devices. other requests seemed to "hang" rather than timeout or do anything more concrete. basically, i gave up on testing using dialup, even though my router and the client software confirm a good connection. but i still wasnt convinced.

next, i figured i could create some type of "DMZ" on my network by placing a switch between my ISP's modem and my router. im not a cisco network professional by any means, but im pretty familiar with networking on a above-average level. that said, despite my best, i couldnt get my quickvpn computer to see my router from the "DMZ".

finally, i figured i could just test the tunnel while directly connected to my network's lan. bad idea. everything seems to go okay until it locks up on "activating policy". rebooting or otherwise ending the negotiation ends in the computer being unable to do anything anymore. when i try to ping anything, i get "negotiating ip security" ad infinitum. the only way i could fix this was by doing a system restore.

so here's the question: how can i test my quickvpn connection?why can't i just tunnel through my network? and before you scream that you can't, thegreenbow vpn client has NO PROBLEM connecting to my rvs4000 while connected to my own network.

Alejandro Gallego · ‎11-09-2009

I will try to make this very short but clear enough so I will actually make sense.

When using the QuickVPN client that comes with our routers the type of tunnel that gets created is called IPSec. This type of VPN connection is extremely secure and it tends to be the connection of choice for that reason. One of the properties of an IPSec tunnel is that it uses a "To" and "From" type of mentality. Because of this, we always have to specify the local network and the local public IP as well as the remote side local network and the remote side public IP.

Usually stated like this:

Local Security Group:

LAN 192.168.1.0

WAN 215.65.X.X

Remote Security Group:

LAN: 172.16.20.0

WAN: 64.25.X.X

This setting also creates a "Route" so the router undestands that any traffic with a destination of 172.16.20.5 should go through the tunnel. Because of exactly this, if we connect internally or if the remote network happens to have the same network ID (local network) the router will not know in which direction to send the traffic. This is the reason QVPN will not connect. As for Greenbow, I am not that familiar with it as other clients so I cant asnwer that question. On other clients we can play tricks. Such as telling the software that our local network is something else that it actually is. Since the software is handling the the tunnel, it can create a virtual passage to keep the conversations straight.

David Hornstein · ‎11-09-2009

Hi Aaron,

I am going exactly the same thing as you however, I had my cousin buy and install a RVS4000 at his house in Australia.

I access it from the USA so that I can help manage his Local Area Network, he is just not technical..

I setup a DDNS client on his RVS4000 so that I can always get to his Router via a domain name rather than a IP address.

I noticed that you didn't mention anything regarding importing client certificate into the directory of the VPN client on your PC.

I also noticed I disabled IPSec passthrough on the router in Australia, see the pictures below, not sure why, but the VPN client is working.

I also did not setup any gateway to gateway VPN tunnels, Only added a client , exported certificate as per the manual, See the last screen capture below.

You will also note if you view the screen captures that my cousins RVS4000 has not been upgraded to the new code.Is there a reason for that...not really...he's just a user, not really technical. Also note I have not added any VPN tunnels on my RVS4000.

I have a reasonably reliable connection between the USA and Australia. I didn;t have to play with any other options, just add users to the VPN client database.

Your description of the working environment of your PC is missing details on the version of XP, so i will mention the following taken from the software release notes of the RVS4000 ;

There is a known issue with Windows XP SP2 Firewall.

ICMP packets are always dropped by the firewall when the firewall is enabled.
This issue causes the QuickVPN client to be unable to establish a tunnel with the remote QuickVPN server successfully.
Microsoft has released a patch to fix this issue, which you can get from:
http://support.microsoft.com/kb/889527/en-us
After you install the patch, the issue should be resolved. You can also fix this issue by upgrading Windows XP to SP3.

You cannot plug a PC on the same network as the router for testing, they must be on dissimilar WAN networks for testing purposes.

Your remote PC VPN client will not be allocated a IP address in the RVS4000's network, hosts behind the RVS4000 will still respond to pings, as they direct the responses to their default gateway, the RVS4000.

The thegreenbow VPN client is a distracter at this point costing 50 something EURO for a license, lets try to get the quickVPN client working !

So, if you still wish try the following, firstly make sure your XP has been upgraded to SP3;

1. If you upgraded your router to the new version of code, then reset your router to factory defaults to re-initialize your router, yes start again.

2. Export the VPN client certificate to the directory that contains the VPN client. In my case it is;

"C:\Program Files\Cisco Small Business\QuickVPN Client"

3. add a VPN client account to the router

4. Use port 60443 from the quickVPN client. and try VPNing to the router.

5 hmmm, if the client still fails try disabling IPSec Passthrough on the router for grins and giggles.

If this fails, call the SBSC at the following location for resolution;

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

good luck ...regards Dave