We have a couple of customers seeking to use QuickVPN to allow their employees to connect to RV0x2's (one is a 42, the other an 82). We ensured both had the current firmware (188.8.131.52-tm for the 42, 1.3.98-tm for the 82). Created a test user account then proceeded to install QuickVPN 1.2.11 downloaded yesterday from the Cisco web site. We installed first on a Vista Ultimate SP1 (fully patched through March 2009's update cycle). The client installs fine then returns the error:
Failed to establish a connection.
This could be caused by one of the following:
1. Incorrect Password (I've checked, rechecked, and checked again, it's right)
2. No valid IP for the network card. (What network card is it talking about? The NIC on this computer allows ful LAN and Internet access so it obviously has a valid IP)
3. Incorrect server address. (One location has a server that has RDP enabled through the RV082 and I can copy/paste the address into mstsc.exe and connect with no problems so the address is correct).
4. Windows Vista with Windows Firewall disabled, which disabled IPSec service. (The Windows Firewall service on this Vista box is running as is the IPSec Policy Agent. Also, regardless of the Windows Firewall state, the Cisco VPN client works perfectly so I'm not convinced the statement that IPSec can't work if the WF is disabled unless the Cisco VPN v5 client uses a different protocol.)
5. Local IP address conflicts with the subnet of the remote VPN Server. (the local subnet is 192.168.100.0/24, the remote is 192.168.1.0/24 so no conflict here)
So we moved on to a XP Pro SP2 box. Again, we setup the same connection using the same QuickVPN software downloaded earlier yesterday. On the XP Box we received the following errors:
1. Incorrect Password (I've checked, rechecked, and checked again, it's right).
2. No valid IP for the network card. (What network card is it talking about? The NIC on this computer allows ful LAN and Internet access so it obviously has a valid IP).
3. Incorrect server address. (One location has a server that has RDP enabled through the RV082 and I can copy/paste the address into mstsc.exe and connect with no problems so the address is correct).
4. You may need to dsiable your Windows Firewall (Tried that, made no difference).
5. Local IP address conflicts with the subnet of the remote VPN Server. (the local subnet is 192.168.100.0/24, the remote is 192.168.1.0/24 so no conflict here).
We then tested the Cisco VPN v5.0.05 client on this XP Pro SP2 box and was able to instantly connect to remote Cisco ASA VPN hosts with no problem as we were with the Vista box.
So then I called Cisco Small Business TAC support for VARs. I gave them the SN of one of the devices and was told that since it was out of hardware warranty that support wasn't really able to help us. Huh? VARs can't get support for products we've recommended? We weren't looking to have a device replaced, only find out what QuickVPN, a product that has a less than stellar history, won't work on any system we try. Cisco has changed a long time policy with no way to renew support services like buying SmartNet contracts (which I'm not opposed at all to recommending to customers) to ensure continued access to support. I highly recommend that Cisco reconsider supporting VARs lest we start recommending customers buy products from a different vendor.
In the end, does anyone have any suggestions on why the Cisco VPN works and the QuickVPN won't? Honestly, I'm back to wishing that these products supported PPTP up to the max connections becuase I never have any problems with PPTP, but the limits on PPTP on these prevents me from using that as the solution.
Ok. 5 days later and we're still trying to get this to work. We've created new Certificates on the RV082's and copied them into C:\Program Files\Linksys\Linksys VPN Client but I still have no connections that work. Support has really not been all that helpful.
I have found some references to QuickVPN relying on ping to find out if the remote host is there, http://forums.linksys.com/linksys/board/message?board.id=Wired_Routers&message.id=2732 talks about it at the bottom of page 1; however, setting Block WAN Requests to Disable changes nothing.
During this testing we found a lovely little file that contains some REALLY NASTY information: C:\Program Files\Linksys\Linksys VPN Client\wget_error.txt. When opened, it contains the username, the password AND the remote connection address remote sides!!! How is this even remotely acceptable? IMHO, this build of QuickVPN should be pulled and reissued with the coding for this file set to munge the content unless a specific option, say in the registry or in some local config file is set to save verbose information, but otherwise there's no excuse for this as it could be on a laptop that could be easily stolen and thus provide FULL access to a company's LAN.
Cisco/Linksys should also make a public statement about this file so owners/admins can remove it.
Finally, I'd like an expalination why the readme.txt says the Vista firewall has to be on to make IPSec work when the Cisco VPN clent clearly doesn't require the Vista firewall to work.
My point here is the real Cisco VPN client works great from any machine I've tried. The QuickVPN client simply doesn't. Do we tell our customers here to dump this and go to a different vendor? Anyone from Cisco interested in working on this can call or e-mail me and I'll happily provide a certificate to test with as well as usernames & passwords, but at this point I fear this is another problem that isn't going away overnight and that we need to find a new vendor for these customers.
Well, I opened a 3rd case. This time I spoke with Bill. We were able to get connections after I purged all the user accounts and recreated the certificate. Now this is where it gets REALLY interesting:
1) Apparently the certificate is a useless piece of code. It’s not required to connect. Furthermore, there’s no way to require it to connect and changing the cert on the server side FAILS to prevent users from reconnecting without being given a copy of the new cert. What exactly does the cert do for the security of this device if ANY user can connect without a copy of the cert?
2) Apparently XP SP2 isn’t supported. I asked where this is documented and he said it wasn’t. I was told all XP clients would have to update to SP3 to use QVPN.
3) Apparently support knows nothing about the wget_error.txt file and the fact that a single failed connection writes UNENCRYPTED username, password, and remote IP to this file. I was told I had to go to engineering to get this fixed. I will do just that.
4) While we got XP Pro SP3 to connect, Vista 32-bit SP1 still won’t.
5) Vista x64 DOA with no known delivery date.
6) One must be a local admin to use the QuickVPN client. The release notes claims this is imposed by the Windows OS; however, the Cisco VPN client and the native PPTP clients do not have this so this is actually a limitation of the QVPN client or how it was written. Let’s see the documentation that provides it’s Windows fault or the statement needs to be reworded. IMHO, yet another security flaw.
In the end, QuickVPN fails where the Cisco VPN client works. QVPN has major security holes that the Cisco VPN client simply doesn’t have. That none of the security risks are published also leaves a great deal to be desired and making undocumented claims that Windows requires users to be admins when other VPN clients don’t have the same requirement only encourages misconceptions about Windows. Programmers that don’t take the time to write code for restricted users are the problem and hiding flaws only makes devices less secure because hackers know about them but business owners and administrators don’t.
Linksys/Cisco has had plenty of time to fix the problems in QVPN but, IMHO, as it stands now this is an alpha-grade product in need of major updates. I continue to stress the need to dump QVPN and replace it with Cisco’s code. It’s an IPSec connection, right? It shouldn’t be too hard to make them compatible.
I am going to have to chime in with BrianB and agree whole heartedly that someone in this company is not doing their jobs that well. QVPN has been out so long and is still not fully functional to the point of being useful for most folks who bought WRVS4400N and WRVSxxxx routers for this sole VPN client connect purpose.
I'd like to point out here also another glaring fault/bug that they need to fix with this QVPN is that it does not pass NETBIOS traffic! What's up with that decision? Who made that decision? Who thought it was okay to release a VPN router (for small business market no less) without NETBIOS support for the VPN Client connections? What in the world is going on here (there at Linksys/Cisco)?
And after identifying all these bugs for so many years, it still is not 100% functional nor fixed? Hey managers and CEO's what's up with that? You like hiring employee's who make these decisions?
And now WRVS4400N V1.0 and V1.1 hardware is obsolete? Will you still be supporting and releasing updates for it to back your customer base? When can we get a new QVPN fix or functional VPN Client replacement that supports NETBIOS shares and is 100% reliable and functional?
sorry for turning into a rant... it just gets to me... so frustrated after spending so much on this gear and wasting time researching for fix solutions.
Please fix it ASAP!?!
Cisco please let us know if you intend to keep working on fixing this or are totally dropping it and leaving your entire customer base hanging in the wind. I need to know so I can move on... to another vendor if need be,.
Before QuickVPN client supports NetBIOS, I can offer a workaround if the remote network (on the QuickVPN router side) has a WINS Server set up that can help name resolution. After QuickVPN tunnel is up, configure the TCP/IP property of the client PC to include the IP address of the remote WINS Server.
I continue to encourage Cisco to dump QVPN and embrace PPTP. It's PPTP server, at least in the RV082, is very solid and reliable, the only problem is someone made a HORRIBLE (not to mention TOTALLY illogical) decision to limit it to 5 connections. PPTP is available for PC, Mac, and Linux and in 32 and 64 bit versions. QVPN is available for 32-bit XP, supposedly for 32-bit Vista (though we can't get it to work here and neither can their support reps), and NOT for 64-bit XP/Vista (don't know about Mac/Linux).
The problem here is Cisco Small Business products are not really true Cisco products. They, as all Linksys products, are developed by 3rd parties and I'm betting that relationships come and go and without the ability to make quick changes Cisco's SMB customers get left in the cold.
Again I ask of Cisco, why not remove the limit on PPTP? PPTP would solve EVERY problem you have with QVPN and allow you to discontinue it. QVPN also doesn't leave password files on the disk when connections fail (note, Cisco support states they cannot reproduce that bug, but we're able to repro it here with no problems so one way or another there's a problem).
In the end, if Cisco doesn't get with the program and fix VPN problems across the board (traditional Cisco doesn't support x64 Windows without paying another license fee to run SSL VPN which is outrageous given the cost of ASA's), customers will start leaving in droves. Remote access is becoming an absolute necessity and something that the entire company has totally ignored.
BTW, PPTP does NOT require admin rights. Essentially QVPN is more of a security risk and hassle than it's worth. We've started recommending customers look elsewhere for SMB remote access technology.
We are looking at Cisco Small Business client options, but they are at least a year away. As far as adding NetBios to QVPN, we have looked to it. It probably requires a change on both the router and client. If it were easy to do, we would have done it. (Keep in mind that not all problems are with the technology.) I agree with you it should have been in from the start. It was a something that was overlooked in the definition of the product, which happened before my time.
As far as going forward with QVPN, given that we multi-task like crazy over here, there maybe be some stone that we have not overturned in trying to solve this problem. I have asked the team to do further investigation.
If you are unhappy with the QVPN client one suggestion is TheGreenbow client. I know the TheGreenBow client is not a low cost solution, but it has been tested with all of the routers. They do have a Vista client. I know it is not a low cost solution, but from our limited experience with The Greenbow client is that it works and their support has been good.
Hi, it's nice to hear back that Cisco is working on this solution... but we always are told that (by various vendor's support teams) and it (the solution) usually never materializes leaving customers with headaches and buyers remorse. At least you replied on this and are honest stating that you think it would be at least a year away... but that too is so disappointing to hear. By that time, there will probably be all kinds of new products and solutions to choose from instead of using these old buggy VPN routers.
Anyway, as for the NETBIOS stack or module implementation for QVPN connections.. I am no sure as I've not tried a direct gateway to gateway tunnel connection between two WRVS4400N routers yet, but does'nt it support passing NETBIOS shares across the gateway to gateway VPN mode? or is that connection crippled also? I seem to recall readng amongst the various Linksys related forums somewhere that the gateway to gateway VPN connection will allow full acess to all the main protocols which I assume means it also passes NETBIOS traffic. Is this so or not so? If so, what would make it so hard for the current developer to just reuse that NETBIOS stack and fit it into the QVPN connectivity module code? Just thinking aloud here. I wonder if I got some pointers from someone on this stuff, I might attempt and be able to modify the GPL firmware code to add such a mod. ? (I've downloaded the GPL source code for v1.113 firmewre and was able to compile it as provided.. I don't know anything else about the code modules yet on where to go change and for what to change at this time). Just that I can compile it successfully now on my Debian Linux 5.0.1 laptop PC I am toying around with.
I still submit that the solution here is to dump QVPN and go to PPTP. You already have very solid PPTP server in the RV082 but you've crippled it to 5 users. Just recompile the code to remove that limit. This solves EVERY problem. There are PPTP clients for every single build of Windows since 98 including x64 as well as recent Mac OS and Linux variants. Why send people to overpriced 3rd party VPN clients when there are perfectly good solutions right there that are not a year out and require no wait times? I've yet to hear solid reasoning behind why you won't consider PPTP? It's never been broken and it's a published RFC (not proprietary MS code as many claim).
I've downloaded the GreenBow VPN Client v4.6 their latest version and installed it on my Windows Vista PC.
Tried to set up a tunnel between WRVS4400N firnware 1.1.13 and the GreenBow VPN client. No go. No work.
In the GreenBow VPN document for WRVS4400N instructions, they put a RESTRICTIONS statement section stating that their VPN client only works with firmware version 1.00.16. They said they tried with firmware v1.1.03 and it will not work. They backed off to older firmware 1.00.16 and said it works and all their document is based solely on older firmware 1.00.16. Which I am not about to back off to since it probably is buggier than the recent 1.1.13 firmware. So we are stuck in a bad spot here. Wish Linksys would just get to work on it and fix their QVPN connectivity.
Also whilst configuring the VPN IPSec tunnel in the WRVS4400N, I noticed bugs galore with it in the VPN IPSEC config menu. After entering all my tunnel data and hitting save, the router would refresh the screen and all my settings would disappear in the data fields. They get reset back to defaults and the timeout fields come back blank. I've searched other forums and saw some mention to this bug too. What the heck? how in the world can we configure a tunnel reliably if the configuration menu screens don't even work right?
Can you please investigate this bad data fields in firmware v1.1.13 (and earlier firmwares also have the bug I read). This bug is serious and not acceptable for a high priced paid product. Especially not one that a small business should be relying on. This needs immediate attention and fix. Please send it up the development line and make them aware of it to get fixed ASAP.
If you know the GreenBow folks, you should work with them to make your products more compatible... using only one old version 1.0.16 firmware and being locked to it to use GreenBow VPN software just does not appeal to me. Especially since I would have to pay extra to buy the GreenBow VPN client. I should not have to pay extra to get your defective routers/software working.
Also please look into the buggy configuration screens for the VPN IPSEC Tunneling fields! They are not saving and not displaying properly after issuing a save to the router! Very important to fix that too along with contacting GreenBow about supporting Linksys current firmware. Nothing works right at this time. Terrible.
Frustrating. Hope something can be done quickly (not years down the road) to fix this mess.
P.S. - I read in LinksysByCisco forum somewhere that this configuration bug is related to some script that updates the values displayed on the screen. I am not sure how accurate that is in their diagnosis, but they seem to think that the tunnel values you enter get saved (after hitting the save button) but then when the router refreshes the screen after saving, it displays back the default values on the screen and some blank fields. It does not display what you entered and saved!
So one cannot be sure what values are actually saved in the router config and this can lead to a lot of the tunneling connection problems. I have no idea if my tunnel values took or not took inside the router.
Update: I might add that it may depend on what Internet Browser is used to do the configuring also. I just tried configuring the settings today and now it is showing the settings properly after I hit save button. Odd? Today I am using Windows Vista IE8 browser seems to configure, save and show correct results.
Yesterday I think I was configuring the router from my Linux laptop using Linux Firefox 3.0.10 browser. Maybe something to do with the browser cache on that system? I dunno, just guessing and throwing this info out here FWIW.
I just got TheGreenBow VPN Client v4.61 to connect to the WRVS4400N by kludging around with the WRVS4400N's IPSEC Tunnel config settings. If you follow TheGreenBows VPN client document to configure the router settings, it does not work. But when I changed and specified a direct IP Address for the Remote Group instead of specifying a "subnet and mask" then I got the TheGreenBow VPN Client to connect and the tunnel came up! I see negotiation errors in the GreenBow logs, but it still connects and the tunnel comes up. WRVS4400N shows tunnel as "Up" and the GreenBow Client shows tunnel as "Up".
I can ping from the GreenBow VPN Client PC to the VPN router subnet and PC's behind the VPN router. But if I try to ping from within the WRVS4400N VPN network out to the remote GreenBow VPN Client network, the pings fail with no response. What is this a one way tunnel? I read bugginess on other forums expressing same concern. One way throughput it seems. Remote client can access into the VPN network but the VPN network cannot ping out to the remote client network. Is this normal?
Also, I thought that NETBIOS traffic would pass when using this VPN Tunnel connection, but it seems that it does not! I have the NETBIOS enable checked off and it does not seem to make a difference. I cannot see my NETBIOS name shares on the VPN network from the GreenBow VPN Client connected remote PC. Is this normal? or is it still buggy? Please someone answer this. Bottom line is that I am trying to get a way to pass the NETBIOS traffic ! Should GreenBow's VPN client connecting as a IPSEC Tunnel work for passing NETBIOS? Isn't this client connecting up just like a gateway to gateway setup? doe'nt gateway to gateway tunnel setups allow NETBIOS traffic to pass on these WRVS4400N routers? If not, they go into the garbage soon.