WRVS4400N and QuickVPN utility

Unanswered Question
Oct 14th, 2009
User Badges:

Hi, never set up VPN before and seem to be having some trouble. I have latest versions of firmware and utility. Was able to configure VPN client account on the router and installed utility and and certificate on XP client. And I even seem to be connecting through the VPN successfully. But now what?! Sorry if this is a silly newb question, but I thought at this point I would have some access to the remote LAN. But I can't ping any IPs there or otherwise interact with the remote LAN. Ideally I want to run Remote Desktop through the VPN so that I can control my work PC from home. Any help greatly appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
twistedpixel Thu, 10/15/2009 - 09:38
User Badges:

Still working on this but no luck yet. Can anyone give me a point in the right direction? I think creating the vpn client/cert is all that's needed (b/c that much seems to work) but maybe I also need to configure a tunnel?? Once I connect via QuickVPN utility how do I access the remote network?

youstupidwankers Fri, 12/04/2009 - 06:15
User Badges:

I've been struggling with Client VPN on WRVS4400Nv2 (fw. V1.00.09-ETSI) and the QuickVPN 1.2.11 software. These same problems seem to be still present with QVPN / Quick VPN client version  1.3.0.3.


The problem was, that I couldn't connect to the router with QuickVPN (the classic "Remote gateway not responding" error). I found a way to debug from the command line from experts-exchange.com (I think it was this link). So here goes...


This is what I found:

If I used the 123456789.dnsalias.net (number represent the lenght not the real hostname) the client didn't work, but once I changed to using the IP address it worked. The reason seem to be, that the server address in ipsec is LIMITED TO 16 CHARACTERS or it should be an IP address.


The command string with problems when running "c:\Program Files\Linksys\Linksys VPN Client>ipsec -debug":


NetshCommandStr = netsh advfirewall consec add rule name="IPsec_Tunnel"

endpoint1=192.168.0.100 endpoint2=10.0.0.0/24
action=requireinrequireout description="IPsec Tunnel" mode=tunnel enable=yes profile=any type=static localtunnel=192.168.0.100
remotetunnel=123456789.dnsalirequireinrequireout auth1=computerpsk auth1psk=kNF7askq2ghhkFDbcp5h
qmsecmethods=esp:md5-3des+60min+50000kb,esp:sha1-3des+60min+50000kb,esp:md5-aes128+60min+50000kb,esp:sha1-aes128+60min+50000kb
qmpfs=mainmode


As you can see the server address is truncated to just "123456789.dnsali". The generated ipsec.conf-file has the whole address. The QuickVPN FRONTEND for the console program should do it's job correctly.


THE BUGS - SUMMARY:

1. QVPN doesn't handle long hostanems - MUST USE IP address.

2. Client doesn't give ANY errors from that part of the execution, but only later when the ping doesn't work.

3. Client doesn't give specific errors (example. It should say if the problem was the password, or the gateway, etc.)

4. Client doest run on Windows 7 without compatibility mode (in the compatibility mode it works as well as in Vista)

4.b Error message is flawed "This only works in Windos 2000 / XP" - So where's Vista?


The Real problem IMHO:

If Cisco decides to create a quickly ductaped piece of software that is a combination of OpenSSL, GNU Wget and Marcus Muellers IPSEC-tool, you should give them credit, distribute the source code (Don't know really if open source principles apply here), or maybe hire them to do the job correctly


This is the same info as in my post here.

ed.sealing Fri, 12/18/2009 - 08:39
User Badges:

I have to say, I'm a little let-down by Cisco (and the former Linksys).


As a small business, I purchase a $300 WRVS4400N SECURITY router, and I expect to get a device that is on par with current industry security and accessibility. Instead I get something that barely works. Here is some of the information from Release notes of the QVPN (going from 1.2 to 1.3):


Changes:

- Removed the use of @ character in the password

- Rebranded for Cisco (changed install directory)


Known Issues:

- On Vista, Windows Firewall needs to be enabled

- On Windows XP, if Windows Firewall is enabled, ICMP gets blocked and QVPN will not work.

- QuickVPN tunnels do not pass NETBIOS names. This means you cannot connect to remote hosts via their NETBIOS names.

- Users need to have Administrative privileges to run QVPN.



Okay, let me get this straight. You changed the install directory and disallow the '@' character, and now you call it 1.3.


These issues are unexcusable. If you need Admin privs to run this thing, and you tell users to turn off the firewall in Windows XP, then how can you call this a security product. Users will be sitting in their coffee shops getting hacked while using this product.


There is also no L2TP or PPTP support so it's not using the remote office as the gateway or the DNS. This means that any information that is not specifically destined for the Office, will be going through the UNENCRYPTED internet access. This is a really poor implementation of VPN software, and wish I hadn't bought this POS.


As far as the Wireless goes, WPA-Personal only works every once in a while. Most of the time it won't even grab an IP address when it's trying to connect to the Wireless, and I end up having to connect with ethernet just to get a connection. The 802.11n 300Mbps is a crock. I put it up against an older 802.11g router from Netgear and the G router was faster.


I'm sorry Cisco, but you really need to do some better work with this one. Everything review I've read on this product has been awful, and I've had nothing but bad experiences with it thus far. Call this $300 wasted... which may not be much to you, but to a small business, that's not something that you want to throw away. I've worked with Cisco products a lot, and although most a a little more complicated, they do do the jobs... but this one has turned me away.


~Ed Sealing

NgaitahuIT Tue, 06/01/2010 - 22:00
User Badges:

Hi,


I'm a Senior Technical Analyst/Systems Engineer working for a large NZ corporation, I ordered the WRVS4400N for a remote site and expected to be able to setup the QuickVPN client direct to the site.  When I put a laptop on local wireless (which is unrestricted DSL on a home router) I can connect to the remote site fine.   Therefore, remote site is setup fine.


Following instructions to allow the same result out of our ISA 2006 firewall, all seem to fail miserably.   I'm allowing 443, 60443, IKE and IPSec NAT-T, UDP 500 and UDP 4500, the QuickVPN client will connect and "Activate Policy" but stops at "Verifying Network".   I'm UNABLE to ping anything at the remote end.  a windows ping says "Negotiating IP Security".


I expect this is a part of the IPSEC Phase 2 negotation failing, but I can't see any return denied packets on the ISA, only succesful logging up to the "Verifying Network" point.


I have to echo what others have said, we use dual CISCO ASA's for our primary line of defense, as well as Cisco routers at every remote site.  It's been an industry trusted and respected brand.


I bought this device (not cheap when you compare with other brands of the same basic 1 IPSec VPN requirement) with the expectation it would work, sure I expected it to be hard (name one Cisco ISO/Appliance that isn't?), but 6 months on and watching the rest of the world suffer the same grief, I seriously wonder if Cisco are aware of the detriment to their brand this is causing them, even if it is "Linksys by Cisco", the bad child.


I simply want to know WHAT to let out in MS ISA 2006 in order to make this work, it works on the home broadband wireless I described with no restrictions, so wheres the different, what else do I need to let out?


Someone said UDP 500 and UDP 4500 were also required, adding them didn't help (although you have to specify send, recieve, send and recieve, or recieve and send, when it comes to UDP).


I expected far better from such a basic product.  If anyone can provide further information I'd be interested, but unless I can get this up and running this week, I can no longer recomend this as a solution to the business.




Thanks,


Ryan

Federico Coto F... Tue, 06/01/2010 - 22:42
User Badges:
  • Green, 3000 points or more

Ryan,


I'm not sure if it's going to be of any help in your case, but you did not mentioned ESP.

All the ports you mentioned are valid, but the actual traffic through the IPsec tunnel travels in ESP (IP protocol 50).

Just want to see if opening that port makes any difference (perhaps not).


Federico.

Actions

This Discussion