1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QuickVPN Client v1.2.8 Released

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by Toxic, Dec 7, 2007.

  1. Toxic

    Toxic Administrator Staff Member

    QuickVPN Client v1.2.8 Release Note 12/6/2007 (VISTA)

    Issues Fixed:
    1. Fixed the issue that QuickVPN Client on Windows Vista cannot work properly when the Server Address field is
    2. a DDNS domain name.
    3. Upon uninstalling the QuickVPN Client, the install directory will be removed completely.
    4. QuickVPN Client will log more messages in the log.txt file to ease troubleshooting.
    Known Issues:

    1. QuickVPN Client v1.2.5 or newer, when running on Windows Vista, cannot connect to RVS4000 nor WRVS4400N when Vista is behind a Network Address Translation (NAT) device. The problem does not occur to QuickVPN Client running on Windows XP or 2000. This was caused by the change in Windows OS behavior. For more information, please see http://support.microsoft.com/kb/944335/en-us.
    2. Windows Firewall needs to be enabled on Windows Vista in order for QuickVPN Client to function properly. This is due to the fact that IPSec service on Vista is disabled when Windows Firewall is disabled. Some third-party firewall will disable the Windows Firewall, which will cause QuickVPN to fail.
    3. Users need to have the administrative rights in order to use QuickVPN Client. This is a constraint posed by the Windows operating systems.
    4. There is a known issue with Windows XP SP2 Firewall - ICMP packets are always dropped by the Firewall when the Firewall is enabled. The issue will cause the QuickVPN Client not being able to establish a tunnel with the remote QuickVPN Server successfully. Microsoft has released a patch to fix this issue. Once you install the patch, the issue should be resolved.
    http://support.microsoft.com/kb/889527/en-us

    QuickVPN tunnels do not pass NetBIOS broadcast packets. This may create a problem when users want to search computers by names or to browse the network neighborhood on Windows Explorer. Users can use a LMHOSTS file to work around this issue. More information can be found at
    http://www.microsoft.com/technet/pro....mspx?mfr=true

    [Download] : http://www.linksysinfo.org/forums/downloads.php?do=file&id=10
     
  2. Chris2002330

    Chris2002330 LI Guru Member

    Linksys still doesnt have solid Windows Vista support after 12 months+ ... who isn't behind a NAT solution anymore?
     
  3. Toxic

    Toxic Administrator Staff Member

    it is in the downloads section of this site
     
  4. Toxic

    Toxic Administrator Staff Member

    lol, look at Microsofts resolution then:

    how lame is that! Vista should fix its own problems first before blaming other OEMs
     
  5. Aviator256

    Aviator256 LI Guru Member

    Microsoft NAT-T Vista Solution

    I stopped by to see if there might be some people willing to try the following trick:

    http://support.microsoft.com/kb/926179

    Here is a short summary:

    1. Log on to the Windows Vista client computer as a user who is a member of the Administrators group.

    2. Click Start, point to All Programs, click Accessories, click Run, type regedit, and then click OK. If the User Account Control dialog box is displayed on the screen and prompts you to elevate your administrator token, click Continue.

    3. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

    Note You can also apply the AssumeUDPEncapsulationContextOnSendRule DWORD value to a Microsoft Windows XP Service Pack 2 (SP2)-based VPN client computer.

    To do this, locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec

    4. On the Edit menu, point to New, and then click DWORD (32-bit) Value.

    5. Type AssumeUDPEncapsulationContextOnSendRule, and then press ENTER.

    6. Right-click AssumeUDPEncapsulationContextOnSendRule, and then click Modify.

    7. In the Value Data box, type the values: 2

    A value of 2 configures Windows so that it can establish security associations when the Windows Vista-based VPN client computer is behind a NAT device.

    8. Click OK, and then exit Registry Editor.

    9. Restart the computer.
     
  6. florenceit

    florenceit LI Guru Member

    welp...

    Yea, gave it a try.. I'm glad to see at least there is a log.txt in the linksys directory now. unfortunately its still reporting "failed to ping the remote dns" (and is failing on the infamous validating network screen still..
    i also tried recreating the profiles fwiw.. nada.

    Oh, also i set my registry value for 2, i will try the other options at some point. how can they disable vpn behind a nat, isnt practically everyone behind a nat enabled firewall when connecting to work??!?
     
  7. Toxic

    Toxic Administrator Staff Member

  8. and247

    and247 Network Guru Member

    QuickVPN problem on Vista via WLAN

    I have a problem on Windows Vista Business - I can connect from my home network to my office RV082 via QuickVPN if I am using ethernet (wired) connection without any problem.

    But when I am using Wireless LAN adapter, Quick VPN won't connect, however, it will not crash. I can see the login screen, I can see connecting, aplying policies... but it stops on verifying network.

    By furhter investigating I found out, that the problem is in IPSEC.exe application, which will not set up any IPSec policies and ends up with an error: No IP Address for your configuration found.

    On the internet I found the source code for some older version of ipsec.exe (not yet Vista aware): http://vpn.ebootis.de/

    I looked into it and I think the problem is in two functions:

    1. getIpInfo() - looks up information about all network adapters, but only of type ETHERNET or PPP, however WLAN adapter is neither type ETHERNET nor PPP (on Vista the type = 71), so my WLAN adapter is ignored!

    2. getValidIPAdress() - tries to find out my own IP address, but only from information looked up by first function and again, only adapters of type ETHERNET - of course, no IP is found and error "No IP Address for your configuration found." is printed.

    I would correct the error myself, but I don't have the source code of ipsec.exe used in the recent QuickVPN 1.2.6 client, which I am using.

    Or am I wrong? Is there anybody out there, who was able to run and connect QuickVPN client on Windows Vista Business (maybe it works on XP) from a computer connected to internet by wireless adapter? Or is this issue corrected on this 1.2.8 version? Why is the 1.2.8 version here and not on the official Linksys web? I will try this version tomorrow and post here, if that helps...
     
  9. and247

    and247 Network Guru Member

    OK, I tried to use this 1.2.8 QuickVPN, but with no success. Connecting thru wireless LAN on Vista is impossible. Is there someone who can connect QuickVPN over wireless LAN?
    If using wired (ethernet) connection, QuickVPN connects withou any problem.
    Any ideas?
     
  10. nheimler

    nheimler LI Guru Member

    I know for sure I cannot connect. I didn't think to try the etho card of the laptop though. I'll have to give that a try. I will attempt to report back tomorrow when I'm outside my home to see. :)
     
  11. Toxic

    Toxic Administrator Staff Member

  12. and247

    and247 Network Guru Member

    no help

    Thanks, but those source codes are of no use.
    Linksys only provides source code for the opensource tools used in their software. QuickVPN uses wget tool and some parts of the openssl toolkit (e.g. ssleay32.dll, libeay32.dll).

    However the problem is in the ipsec.exe tool originally made by Marcus Mueller. Linksys probably modified the source code of this tool and don't provide the modified source for download. :(((

    So we'll have to wait until Linksys fixes the issue ... anyway, they should reprogram the whole ipsec.exe tool, now they search for the first ethernet interface, but I think, they should use routing table to find the correct if ... and also I don't understand, why QuickVPN adds the remote router's internal IP as a primary DNS on the machine running VPN client ... it makes more trouble than good for me :(
     
  13. Michel78

    Michel78 Guest

    Hi And247,

    I have exactly the same problem :

    QuickVPN Client v1.2.8 with :
    - Windows XP + wire Ethernet modem connexion => OK,
    - Windows XP + WIFI modem connexion => OK,
    - Windows Vista + wire Ethernet modem connexion => OK,
    - Windows Vista SP1 + wire Ethernet modem connexion => OK.

    QuickVPN Client v1.2.8 with :
    - Windows Vista + WIFI modem connexion => BUG,
    - Windows Vista SP1 + WIFI modem connexion => BUG.

    I called many times Linksys European support since 2007-12-31.
    I have not correct answered.
    It seems that Linksys European support have'nt portable PC with WIFI.

    Can you excuse my poor English?
     
  14. Toxic

    Toxic Administrator Staff Member

    my guess is vista is stopping something.
     
  15. and247

    and247 Network Guru Member


    Actually, the problem is that Windows Vista uses a different interface type number for wireless interfaces than previous versions of Windows did.

    See http://msdn2.microsoft.com/en-us/library/aa366058.aspx.
    Previously the number was IF_TYPE_THERNET_CSMACD (6), now it's IF_TYPE_IEEE80211 (71).

    So Linksys have to fix their software to include not only adapters of type 6, but also type 71. Very simple, but it is very difficult to tell to Linksys, they do not listen to me. :(
     
  16. Devilstorm

    Devilstorm Addicted to LI Member

    "Gateway Not Responding, Do You Want To Wait?"

    HELL NO!!!!
     
  17. PetervdM

    PetervdM Network Guru Member

    QuickVPN 1.2.11 has been released

    Issues Fixed:

    1. Fixed a QuickVPN Connectivity issue, where QuickVPN Client running on Vista with
    a wireless LAN adapter cannot connect to a remote QuickVPN router.
    2. When QuickVPN Client fails to establish a tunnel with WRV200, the client
    will try to detect whether the Ping (ICMP) is blocked or the IKE negotiation
    (on UDP port 500 or 4500) is blocked, and log messages in the log.txt accordingly.
     
  18. Partly working ...

    Thanks. That got me a step closer.

    I'm currently using XP Pro with QuickVPN 1.2.8 against an WRVS4400N upgraded to 1.1.8 (beta). It works ... mostly. For initial testing, I am going from inside the firewall, out and resolving usng DynDNS, and back in again. For secondary testing, I have a hot spot that I use.

    A few observations:

    1) On my 'loop back' it works if I create a second 'alternate IP'.
    2) The hot spot I use happens to have the same subnet as I use (rare, as I changed mine from default) and that hides all my internal IP addresses.
    3) More ISPs, telcos and cable companies around here (western Canada) are starting to block ICMP /ping and ports 21, 80 and 443
    4) All bets are off if the remote (QuickVPN client) end blocks ping.

    Wondering why QuickVPN uses ping at all? Indeed, why not use port (443, 60443, user settable) for the whole communication? Even the wget could be moved there for the initial data transfer.
     

Share This Page