Problems with QuickVPN to RV042

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by Saggy, Jun 16, 2005.

  1. Saggy

    Saggy Network Guru Member


    I have waded through many topics here and elsewhere, which I can thank for getting me as far as I currently am. There have been a number of similar situations decribed, but nothing quite the same so I would be grateful for some thoughts. I like computers and have plenty of experience tweaking hardware, but I dont deal with computers for a living and setting up a VPN is tesing my skills somewhat. Excuse me if I say something which is blatantly retarded.

    I am accessing my work network from home, have succeeded in making a quickvpn connection, but am not able to access remote machines (other threads I have read have been able to ping, but have problems with windows shares, this is not the problem I have).

    - Netgear D834G modem/router
    - Dell laptop (which is also used at work when I am there), XP Pro SP2 no firewall
    - Home-built desktop PC, XP Pro SP2, again no firewall
    Internet Access
    - 2Mb ADSL with Zen

    Modem/Router 1
    - Zyxel Prestige 650R-31
    Router 2
    - Linksys RV042
    - 'Server' which is running XP Pro with shared folders
    Internet Access
    - 512kb ADSL with Zen

    Having ordered the Linksys on the basis of a couple of comments I read about the relatively easy QuickVPN setup, I was rather gutted when I ran into problems getting it setup. I fiddled for ages, which we wont get into, but I will outline what I have maneged to get running.

    The Zyxel is working as a router, using PPPoE (lucky me the exchange seems to support it!) and its set to allow PPPoE passthough. It has the static external address for the office which was allocated by Zen (say, with an internal address slightly modified from the default (say, and uses NAT-SUA to forward all ports to the WAN port address of the Linksys (say,

    The linksys WAN1 is set as a static IP is sequential to the Zyxel internal ip, with the DNS details as provided by Zen and the gateway set as the Zyxel internal ip, it is running DHCP, is in router mode, I havent changed the NAT settings from default, and has a LAN address something like I have turned off block wan request, though am not sure if it matters. A number of devices are connected to the linksys with static addresses (for example the two printers mentioned above, both of which have web interfaces), and some with DHCP which are a couple of laptops.

    I only set this new arrangment up this morning, and everything in the office seems to be working fine when my laptop is there, internet access, printing, access to the server etc (including the ability to VPN out via the double NAT using a client supplied IBM windows XP SP1 laptop to a client VPN gateway). With my own work laptop attached to the loffice lan directly I can access the linksys internal address, and also the zyxel address.

    When I got home, I was pleased to see that I was sucessfully making a Quick VPN connection to the office using my laptop (so far the desktop has refused, bringing up a an error message about the remote gateway, not responding but that is an side issue). My home network router is on something like, with the machines connected to it numbered sequentially.

    When logged in with QuickVPN I can access the Linksys internal ip (to get into the configuration page), but cannot ping or otherwise access any machines connected to the linksys (computers, printers on the lan, or the Zyxel attached to the Wan port). However, from within the Linksys configuration page I can use the diagnostic utility to ping all of the above, so they are still there.

    My understanding is that I must have a working VPN connection to access the Linksys configuration (at least I hope so, or my security is rather poor!) and the VPN status would suggest so both with the sofware staus on my laptop and the status page on the linksys configuration. Why then does my laptop not behave as if it is a machine on the remote network in the same was as it does when attached to the linksys directly in the office?

    IP details on my laptop when using quickvpn are those allocated by the local netgear router, but I believe that this is correct, otherwise it would not be able to access the internet from here to make the vpn connection.

    Oh, I should probably add that all addresses are set with a subnet of If there is any other critical info just ask. I am not 100% sure of the implications of the ip ranges and subnet masks, so there is a risk I have done something I shouldnt, but to be honest I am stumped. It would at least have been clearer to me if I failed to get a connection...

    Thanks in advance for any help.


    Edit - The quickVPN seems stable, been up now for three hours. Having considered the issues, I would like to add that I can ping my local router just fine. I'm beginning to think it is some issue with subnet masks, in that the ranges set dont allow the local and remote networks to realise they are within the same private network. Could this be true? Though, why would I be able to ping and open the configuration interface on the linksys? Anyway, just a thought. Someone save me soon before I have to go googling for subnet mask tutorials.
  2. DocLarge

    DocLarge Super Moderator Staff Member Member

  3. Saggy

    Saggy Network Guru Member

    Hi Doc,

    I have already read the links, and did indeed pick up some points which helped me get to the reasonably advanced position I am in.

    Reading my message above, it is rather full of what os probably irrelevant guff, but I just wanted to be clear how things were set up, I only really get to the issue 2/3 of the way down. I believe (and both the sofware status information on the client computer and vpn log on the rv042 agree) that I am sucessfully making a vpn connection. Once the connection is made I am logging into the rv042 using its internal office lan ip, I have not enabled any remote managment.

    The problems discussed in your links relate to making the vpn connection in the first place or in mapping drives from machines which are visible by ip only. I fall between these camps - I am making a connection but I cannot see anything remote other than the vpn gateway, by ip or otherwise (i.e. although all of the remote devices I want to see are 'pingable' from the remote Linksys, and I can internally ping the remote linksys from my client laptop when it is connected using quickvpn, I cannot ping any of the other remote devices).

    I have read what I have been able to find both here and elsewhere that relates to either quickvpn, the rv042 or the 650R-31 but I cant find any mention of a similar issue. Perhaps I am missing the significance of some of your points in the threads above, but I dont see anything there which can help me get any further. I can understand that it gets pretty tiring repeating the same old stuff to every person who stumbles across the site, but either my problem is new, or I am misunderstanding something which has already been discussed. As Nicholas Cage said to Sean Connery in The Rock, "I'm only a biochemist"...

  4. DocLarge

    DocLarge Super Moderator Staff Member Member

    No worries, :) :)

    I'm a post graduate psychology student (working towards my Ph.D as a cyberpsychologist[combines networking functions, behaviors with psychological research]) while being a full time U.S. Air Force systems administrator, so there's always room for misunderstanding; getting to the root of the issue regardless of the platform is just a way of the gun :). I'll never claim to be the greatest, but I'll drop a little info should I think I know enough to help...

    If you fall between the two, then that's as good a place as any to start. Now when you say "you can't see," are you expecting to see the remote lan in your network places? If this is the case, make sure you allow access to ports 137 thru 139 in your firewall...

    Also, you want to make sure that the computers holding the information you want access to "have" an account created for you on "each" machine if they aren't managed by active directory; if the computers you want to access are in an active directory domain, then you should have an account created on the master domain controller (which of course extends to all other computer resources).

    Is this closer to what you're referring to?

  5. Saggy

    Saggy Network Guru Member

    We are making progress, you seem to be getting a better idea of where I am.

    I was half-expecting to see the remote network in my local neighbourhood, at least eventually, but to be honest I dont care as long as I can map one shared network drive. We are a small legal firm, so we dont have active directory, or even a full-blown server, we use laptops with docking stations, with one fixed desktop which is the 'server', all are running XP Pro SP2 as a peer to peer workgroup. This I believe means that we should have no issues with needing an individual account on each machine, but I cant say for sure until I can at least see the remote machines.

    When I say I cant see, I mean I cannot ping any of the remote machines other than the internal port of the vpn gateway. I thought if I could get that far then I should be able to ping the other remote machines too. Will opening ports 137-139 fix this problem? Obviously if you cant ping something it isnt going to be in the network neighbourhood. But is the reverse true that everything which is pingable is always in the network neighbourhood?

    Finally, is opening ports 137-139 otherwise harmless? I am a little wary of creating an open door into our office network. Are there any other ports which should be open? I havent changed any of the firewall defaults, apart from turning off the block wan request.

    I'll try opening the ports anyway, but I cant test the vpn again until I get home this evening.

    Thanks for your help.

  6. DocLarge

    DocLarge Super Moderator Staff Member Member

    And there's a part (or all) of your problem; XP SP2 firewall!!!!

    XP SP2 firewall is "completely" restrictive in nature and is "not" conducive with quickvpn. What I've suggested for some people is if they don't have a third party firewall, then it's best to invest in Norton Internet Security 2004 in place of sp2 firewall. With NIS, you can run quickvpn with the firewall up.

    Now that I know for sure you're running a decentralized network (a.k.a. peer-to-peer or simply called a "workgroup") you need to make sure you have a user account on "each" computer and disable the firewall that comes with SP2 on all laptops.

  7. Saggy

    Saggy Network Guru Member

    You are continuing to be very helpful, thanks. I think I have been slack with my wording again and may have sent you off on another tangent.

    The SP2 firewall is not running on any machines, I found it conflicted with some of the sharing so just disabled it. We do not run a third party firewall at this time (we have a handful of machines behind a router so I didnt think it was necessary and I do regular patches and scans for malware), but since having VPN access to the office will entice us to connect our laptops to the internet from 'open' locations (atm this doesnt happen) this is on the list of jobs to do once I get vpn working. We currently use AVG for antivirus and may use their new firewall, I havent looked into it enough yet.

    Was your reference to opening firewall ports for the software firewall or the linksys hardware firewall? I had originally thought you meant the linksys, but now believe you mean the software firewall if I have one. I will hold off opening the hardware ports until you confirm, I dont want to do anything stupid.

    I note you say that I will definately need a user account on the machines I want to access remotely (only the 'server' to be honest) that can be set up easilly enough, though not today since I am at home.

    However, you seem to be a step ahead of where I currently am. I believe that when I have a quickvpn connection I should be able to ping all of the remote machines, if not the windows XP machines, then at least the networked printers. Also, since I can log into the linksys internal web configuration interface, I cant understand why I am unable to log into the remote printer web configuration interfaces (these are on fixed ips, and in the same subnet as the linksys internal ip).

    My gut feeling is that my current problem is some sort of routing/subnet/ip type issue. How does the local vpn client computer know when an ip address is within the local private network or the remote private network? If I enter a public ip or web address, does it reach that address directly via the local gateway or indirectly via the vpn connection and the remote gateway?

    Of course, if it is the hardware firewall ports which need to be opened then my questions may be moot.

  8. DocLarge

    DocLarge Super Moderator Staff Member Member

    As soon as you connect to the remote network via quickvpn, go to network places and bring up your tcp/ip settings. You'll be able to see that when you make a connection via quickvpn, your "primary" DNS server "automatically defaults" to the remote router you are connecting to. This is how it knows what to look for...

    If you can't see your printer server through an internet "lookup" the same way you connect to your router, there is an ip setting or a port setting that is misconfigured. The way you access your router across the internet is the same way you should be able to access your print server.

    You are on the money when I make statements referring to "opening ports." This is where I'm making direct reference to a third party firewall; this is how you want to control traffic "in and out" of your computer. The WRV54G has a "stateful packet inspection" (SPI) firewall that inspects packets "across your entire network" whereas a firewall on your machine looks at packets "directed towards that machine only." If you can't ping any of the machines on your internal LAN segment, check to see if all the machines have been setup with DNS enabled.

    As I said, I'm not an expert, but I've done this long enough to where I'm familiar with an assortment of problems. Somewhere along the way, you'll bee seeing commentary submitted from others who are also familiar with the problems you're having for having gone through the same thing also :)

  9. Saggy

    Saggy Network Guru Member

    Just a quick update, I continued to have no luck, so went through all the network settings on the linksys router and modem, reseting them to what I wanted, strangely enough that did the job (nothing seemed to be set wrong, but obviously something must have been). I can ping remote machines and log in to the remote printers using their web interfaces. Typically I forgot to set up an account for myself on the server machine while I was in the office earlier, so dont know if I can definately get the drive share going in windows, but at this point I feel confident that the problems are sorted.

    Thanks for your help.


    Edit - THE PROBLEMS ARE SORTED! Despite not having an account on the other machines, I know the user name and password of the main account on the server. When mapping a drive I just has to click connect as another user.
  10. DocLarge

    DocLarge Super Moderator Staff Member Member


    Glad to help...

  11. Brian_B

    Brian_B Network Guru Member

    Howdy hi there Doc and Saggy! Been reading through these threads so much I feel like I already know Doc! Kudos to your work on "A real QuickVPN Setup Guide"! I've followed it to a tee and all the other potential tweaks as well from other posters. I am still having a tough time with QuickVPN though.

    Immediately after arrival of the pair of RV042 routers a couple of weeks ago Bruce and I went right out to install the latest firmware, This is a matter of good practices as one hardly wants to update firmware after the config with the potential of loosing all that time and work. Bruce and I then set forth to create our Gateway to Gateway tunnel with our remote office some four hours away. Got it up and going just fine, it works GREAT!!!

    After applying all the KNOWN quantities to the RV042 from these threads I downloaded the QuickVPN installer at home and installed to my Tablet PC. Set the MTU to 1458 as instructed and gave it a whirl... The dreaded "Verifying Network"with the Connection Error window! "The remote gateway is not responding....

    Looked in the System Log of the RV042 and found an interesting factoid. At the same time I tried to connect it logged an "Event-Type" "Invalid mask `' specified". I have DHCP turned off as we have a Windows 2k box handling that in our office. Bruce set this router up and he swears he went right through the install with out a hitch, no wrong Net Mask was input. I have verified that all is okay on the LAN side. This brings me to a question I have not seen the answer to in all the threads I've read so far. What IP address scheme is used for the clients that connect? I've read in one of the Linksys articles that you don't want to have conflicting addreses such as 10.252.242.x Is this the ip address range Linksys has appointed for the QuickVPN access? If so, could it be that the RV042 is stumbling with it's own netmask when assigning me an address?

    I'd been contemplating this as I have never seen the IP address show up yet where upon I'd run an ipconfig /all to see the structure and verify the settings. The IP addresses for both the office and home are legitimate public IP's run behind NAT! They are both completely seperate from each other by about 80 class A octets or so. And yes, 1723 and 47/500 ports are open inbound and outbound on all routers in question. No, the MS Firewall on the Tablet PC is diabled as I am behind a fairly robust appliance.

    The VPN log of the RV042 definately shows that I am touching the router! Of the 21 lines for each session it starts out with this first line:

    Ignoring Vendor ID payload Type = [MS NT5 ISAKMPOAKLEY 00000004]

    and ends the session with:

    [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected

    and finally:

    received Delete SA payload: deleting ISAKMP State #3145

    The Access Log says "Connection Accepted" for each connection attempt, the message portion shows "UDP (IP address):500->(IP address):500 on ixp1"

    We are dealing with the RV042 here. Linksys doesn't even show support for the QuickVPN in the Downloads section for this model nor is there applicable information in the Knowledge Base!

    I trust there may be a firmware update available soon to address the problems all we people in the forums are experiencing with QuickVPN and the RV042. At this point I wouldn't mind a SlowVPN software/hardware package :)

    PPTP pass through still works though and I am having to rely on it to tunnel into our network. In the meantime I'd like to see some refining of the firmware and possible updating of the software (QuickVPN) to include a bit more diagnostics and a page on this site or to explain the errors we would be receiving.

    One more tid-bit, I found that either the RV042 or QuickVPN do not like wildcard symbols in the passwords! I tried to use one that was something like this: "cAt)$(hAT" I would immediately get bounced back to an error from QuickVPN, I don't even think it tried to get out of the PC, let alone the LAN and through the Internet to the RV042.

    Hope I provided enough info in the logs.

    Will be looking forward to a fix.

  12. DocLarge

    DocLarge Super Moderator Staff Member Member

    If you haven't already checked it out, take a look at the "Reasons Quickvpn Won't Connect" post. If you have and are still having problems, I'd bet money a setting is off (10 times out of 10 a setting is off). One thing I do need to update in the guide for "Reasons Quickvpn Won't Connect" is if you are running any of the 50 vpn tunnels on the PPTP side, quickvpn won't connect. Yeah, bummer.

    I just happened to catch that in your post after I read it for a second time, or at least, this is the case with the WRV54G (try it for yourself and you'll see what I mean. So, it's a case of "This" (Quickvpn) or "That" (PPTP.

  13. Brian_B

    Brian_B Network Guru Member

    Hey Doc,

    The PPTP connections we are using "pass through" the RV042, and are initiated by our WatchGuard Firebox, so the RV042 is not being used for PPTP.

    Here's a thought, could it be that our full time "Gateway to Gateway" VPN connection is preventing "VPN Client Access" from working? Can the two operate simultaneously?

    I setup "Client to Gateway" Group VPN last night before leaving the office. I set the Remote Client as "Microsoft XP/2000 VPN Client". At home I added the IPSec Policy as described in "Configuring IPSec between a Microsoft Windows 2000 or XP PC and a Linksys VPN Router". This failed as well and probably needs tweaking due to the article being written for the first generation VPN routers, i.e. BEFVP41. I'll continue to tweak the policy to make sure it matches off with the RV042. In theory I should be able to direct my web browser to any office web enabled device like the RV042's LAN address and connect though as if I were there. XP would build the tunnel on demand. XP didn't build the tunnel in my case and at one in the morning I decided I had enough fun for one day :)

    Been through the "Reasons Quickvpn Won't Connect" post many times already! Good article, just a shame some of those steps have to be taken.

  14. DocLarge

    DocLarge Super Moderator Staff Member Member

    Gateway to gateway would probably do it... Try turning it off on both sides and give it a shot...

  15. BianchiJC

    BianchiJC Network Guru Member

    I also think it was probably the Gateway to Gateway as I had the exact same experience. As soon as I set up teh Gateway to Gateway VPN between two RV042's my QuickVPN Client would not connect from behind one of the RV042 but worked fine from a different remote connection.

    I'm having a different problem though. My QuickVPN Client connects without a problem but the connection only lasts at most 3 minutes before it disconnects. This is happening to all uses reguardless of where they connect from. The only tweaking I've tried so far was changing the MTU to 1492 and 1458 but that didn't seem to help at all.

    Other threads seem to indicate a problem with the firmware on the RV042 and one person mentioned there were gettnig a new beta firmware from Linksys.
  16. DocLarge

    DocLarge Super Moderator Staff Member Member

    I've had the "exact" same problem. This (in my experience) is "purely" MTU. Taking my WRV54 off of "manual/1492" and setting it to "auto/1492" made the difference (and thus was born the "Quickvpn Setup Guide") :) However, my isp changed from "data" to "ipstream" recently; vpn would connect, but not transfer. So, I finally thought about it and changed my MTU to "manual/1400" and I was able to transfer again. I then did a search (for curiousity sake) and found the following link:,39044847,39089320,00.htm (Tweaking Win2k registry to improve tcp/ip performance)

    This has made alot of difference in better understanding MTU.

    So, the first thing you can try is setting the MTU on your RV042. Set the MTU to "auto" and 1492 first. If that doesn't work, then try setting it to "manual" and try 1492 or 1458. If you're still getting no luck, then here's a definite way to know what the exact size packet setting you need is.

    Open a command prompt and type the following:

    ping -f -l [packet] [WAN gateway]

    Were you see "packet" is where you'd type the size of the packet you want to use and "WAN gateway" is the gateway ip provided by your ISP. So, an example would be:

    ping -f -l 1450

    If your ping comes back saying "Packet needs to be fragmented but DF set" the MTU you're choosing is still too high. Just keep whittling it down in increments of 10 or 20 and you'll soon find the right size. When you finally get a normal ping return, this means you've found an acceptable size.

    Once you find the right MTU setting that fits your needs, you can use DR TCP in a more exact manner instead of having to guess. If you read the article and see the levels you have to go to change it manually (which I've done for shitz) you can see why somebody creatd Dr TCP. If you do go the "regedit" route, the MTU will be in hexadecimal. The best way to figure out the MTU hexadecimal value is to open calculator (calc.exe from the "run" command), set the view for scientific; choose hexadeciamal and type in the hexadecimal value you see then change the calculator radio button from "hexadecimal" to "decimal;" there's your MTU!

    FYI, default MTU for 2000/XP is normally 1450-1458 and sometimes has a little bit to do with your ISP's WAN technology.

    This might help...

  17. russwmc

    russwmc Network Guru Member

    The RV042 problem is MTU induced but changing the MTU is not the answer in this particular case. I have used an RV082 configured the same way as the RV042 and it has no QuickVPN problems.

    Linksys has sent me the latest firmware It seems to be running fine. It is not generating the same log errors as the previous version. In fact it has not generated any log errors in about 30 minutes of running so far.

    Hopefully this is the answer.


    p.s. forgot to mention that the MTU information can also be found in the easy answers under technical support. Just search for MTU and there is a topic on determining proper MTU. Max MTU size with no fragmentation for a brighthouse cable customer is 576 :thumbdown:
  18. NerdsLogic

    NerdsLogic Network Guru Member

    QuickVPN while Windows XP SP2 is enabled

    For those of you who are having problem to connect using QuickVPN while Windows XP SP2 is enabled (Test to see if it works while it's disabled, if it does, then this is your fix so you can leave the XP Firewall on"

    After you install the update and restart, you can simply allow the Linksys QuickVPN Client to pass through Windows XP Service Pack 2 Firewall by adding it to Program Exceptions.

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice