Broadband Tech > Virtual Private Networking > WRV4400 and QuickVPN Client setup

WRV4400 and QuickVPN Client setup

First you need to know what type of equipment that he's trying to connect to at the other end. Some VPN equipment requires special client-side software. Have you talked to the IT folks at the plant he's trying to connect to? They can probably be quite helpful since they know what works with their stuff.

"WRV4400 and QuickVPN Client setup"

sooooo... a Cisco WRV 4000 series router.... Mainly I need to make the tunnel connect. He's doing a couple of weird things when he gets there, like hooking up to a PLC on a 1.x.x.x network, but I should be able to assign him any internal IP address once I get the tunnel connected. Right now, the tunnel won't connect. It just sits at "Verifying network".

The only way for the Tunnel to connect is if you have the proper credentials --- have the IT responsible person provide the proper credentials then you will have success.

reply to Ahhzz
As others have already said, you need the IT person who manages the WRVS to configure the router to allow the quickVPN connection. So you need to speak with them to do that.

You can't just configure the software and then connect. There's a user to be assigned on the WRVS and a certificate to be created on the WRVS that will be paired with the quickVPN in order to use it for that router. Once that is done by IT on the WRVS, your client has to install that cert locally on his machine to use with the quickVPN.

Also, your clients router (not the WRVS, but his local router) has to be configured to allow VPN passthrough also (either a passthrough configuration or specific ports forwarded) which depends on what model your client has. Without that done too you'll technically be able to connect out through his router to the WRVS but no return communication can happen so no joy either.

Look up the user guide for this model which explains how to configure quickVPN, although you won't be able to configure it unless you get IT there to do it.

-Jim

reply to Ahhzz
A friend and I originally put this list together almost 8yrs ago when CISCO (back then "Linksys") first introduced quickvpn. I tested a WRVS4400N that was given to me by CISCO to play with a few years ago, but I eventually gave up on on it (it was a Ver. 1). Quickvpn is essentially nothing more than a rebadged windows "IPSEC policy," so again, it's nothing special, but Hell to deal with when it doesn't work.

Anyhoo, here are the top reasons you'll get "Verifying Network:"
----------------------------------------------------------------
REASONS YOU CANNOT CONNECT WITH QUICKVPN

1. The quickvpn client is not the only vpn client loaded on the client machine.

2. MTU on the WRV54G you are connecting to isn't set at "auto" and/or the packets being sent from the client computer are too large (should this be the case, download "DrTCP" and set the MTU of the client's NIC to 1458). Additionally, it doesn't hurt to check and see if the MTU on the client router is set at "auto" also.

3. You are trying to connect through a dialup or ISDN connection.
NOTE: I have never been able to connect from a dialup/ISDN connection with quickvpn. More power to those who can.

UPDATE: Recently, someone was able to connect over dialup in a highly "unusual" manner Basically, when connecting over ISDN, quickvpn hangs at “verifying network†but it will still negotiate the ip security portion and allow you access to your LAN. The only way to close the connection is to terminate it through task manager.

4. The firewall software on your computer is registering the "ACK" conversation from the distant-end device (wrv54g) as an "Invalid ICMP Type." In this instance you can either "shut down" the firewall for the session or, as I've done, uninstalled my firewall software (NIS 2004) and quickvpn, then reinstalled both (Norton first followed by quickvpn). After that, launch quickvpn, and once Norton detects it, it establishes all the proper rules to allow it to pass through the firewall. Hopefully your firewall software should do the same.

In the case of #4, I never caught this until I noticed after reloading one of my computers, I had to drop the firewall on one of them to access "the same damn share" as the others, but I didn't have to bring the firewall down on any of the others except that one particular machine.

5. IPSEC Passthru is not enabled on the client/distant end router.

6. You have communication software loaded that is preventing quickvpn authentication with the wrv54g router

Note: I loaded software from motorola cellphone that installed its own "liveupdate" software that blocked quickvpn from talking to my wrv54g router. I knew there was a program I'd recently loaded that was most likely the problem because I had just used quickvpn an hour prior.

7. You have installed two NICs on the client computer and quickvpn is trying to utilize the connection that is not assigned an ip address. Simply disable the card that is not being used.

8. IPSEC is not running on the client computer you're connecting with. To remedy this, go into control panel, administrative tools, then click on services. If IPSEC isn't started, set it to automatic and start the service. If you've ever used ssh sentinel, this knocks your ipsec out and you have to go into windows services to restart it.

9. The user account and password is not created or has not been typed in correctly.

10. Large downloads will disrupt the routers tables causing quickvpn to not respond every so often.

11. Quickvpn terminates in the middle of a quickvpn session. Just like #10, this hoses up the routing tables for vpn. The answer is to delete all existing accounts and recreate them (don’t create the same username and passwords twice) or reset the router to factory default and start from scratch.

12. HTTPS is not Enabled by default (For RV0XX Series Only). If you will use the Linksys QuickVPN Client Software for allowing VPN Clients to connect.

NOTE: NetBIOS is not supported across a QuickVPN connections. Use either WINS, DNS or the LMHosts Methods.
----------------------------------------------------------------
These configurations are just what we noticed when having quickvpn problems. People world wide have been following this guide with and have had success with the WRV54G, RV042 and the RV082 routers. Again, this is just a baseline. When you figure out what you need, just vary things as needed.

As I stated before, this "cheat sheet" is over 8yrs old. Since that time, I was actually given an RV220W by CISCO last year to test and I actually find that to be a better alternative to the WRVS4400N series routers.

The guys and I over at linksyinfo.org spent a few years fooling around with all the subsequent models that preceded the WRVS4400N (i.e., WRV200, WRV210) to the point CISCO had us working as their remote "beta team" testing firmware. Again, if in your budget, check out the RV220W; you'll have the ability to use onboard PPTP and SSL as well, to include "site-to-site" IPSEC vpn.

Until such time you do, see what the "quickvpn rules" do for you

Jay

Thanks DocLarge. Tons of useful data there. We actually got the VPN to work halfway with some minor issues. We had been trying to create a custom tunnel, that issued an internal address that matched the PLC in the warehouse, and it just wasn't working. So, we deleted the tunnel completely, and started the connection with a very short user and password. We also changed all the internal networking to match the 1.0.0 subnet. The QuickVPN client comes up with a note that the certificate we had on our computer didn't match, but we ignored that, and told it not to terminate the connection. This let us into the network, but here's where it got weird on us.

At this point, I can ping any machine on the network: printers or PCs. Logging into the router, I can use the routers diagnostics to ping the PLC. But using the VPN connection, I cannot hit the PLC. I can hit everything else, even load printer drivers if I wanted to, but I can't hit that PLC.

After looking at the address setup on the PLC, we noticed that the original programmer had not put the gateway or the dns settings in (obviously, didn't need them for a PLC). But, our best guess is that the PLC doesn't respond properly without gateway and/or DNS info. So, we're hoping to use BootP to stick that information in this morning.