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

QuickVPN issues/troubleshooting/reliablity

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by YeOldeStonecat, Dec 6, 2006.

  1. YeOldeStonecat

    YeOldeStonecat Network Guru Member

    Having issues with QuickVPN reliability....

    Been setting up RV0's for a couple of years now...always had lighter VPN needs, so I relied on the trusty old PPTP VPN server.

    However..recently upgraded a client to an RV016 due to their expanding "road warrior fleet"....about 35 remote users. The 016 is licensed for 50.

    Latest firmware, on static cable. MTU on router set to auto, https enabled.

    Initial deploy...seemed to go well. However, over time, clients seem to become unreliable, requiring an uninstall/reinstall of QuickVPN. Yesterday I remoted into a user...she could appear to connect fine..but could not get replies when she pinged resources on the office LAN. So her "mobile" version of her software could not "replicate" with the database server. Yet there was some sort of connection there.....because from her laptop, I could pull up the web admin of the RV0, and I could RDC to a server.

    It's odd...the fact that when you run an IPCONFIG /ALL...you don't see any info from a VPN adapter, like in most other VPN setups.
     
  2. ifican

    ifican Network Guru Member

    QucikVPN is a strange beast. I have wondered some of this myself and even dug into the setting to see if any of it made any sense. From best I can tell, QuickVPN works like an application layer intercept. When the tunnel is connected it determines if the traffic should be destined for the tunnel (then packages it accordingly) or not (simply lets it pass through and go out normally). Indeed because of this it makes troubleshooting very interesting. What have have also figured out though, at least in my using. I will occasionally see that it just stops working right, symptoms vary but end result is always shows connected but for all intents and purposes its not. Anytime i remotely sense any issue arise I reboot the QuickVpn router and all comes back just fine and runs stable till the next time. For me, and i always have 2 ipsec tunnels running is maybe once every 2 months or so. But again I have only have at the most 2 ipsec and 3 quickvpn connections at the same time.
     
  3. ccbadd

    ccbadd Network Guru Member

    I really wish they would spend some time on QuickVPN. My main problem is it just does not work with my Sprint Broadband card. It is supposed to be a business class app (small business!) so I don't understand why Linksys does not put more into making it a great app.
     
  4. pvanamst

    pvanamst Guest

    I have spent the past couple of weeks trying to debug quickvpn connecting to a linksys wrv54G access point.
    From what I have determined, quickvpn is just a shell that calls a set of programs that establish the connection to the wrv54G.

    The quickvpn program appears to do the following :

    From the c:\program_files\linksys\linksys VPN Client directory, the application calls :
    I have spent the past couple of weeks trying to debug quickvpn connecting to a linksys wrv54G access point.
    From what I have determined, quickvpn is just a shell that calls a set of programs that establish the connection to the wrv54G.

    The quickvpn program appears to do the following :

    From the c:\program_files\linksys\linksys VPN Client directory, the application calls :

    Step 1 - wget https://userid:*password*@remotelin...n.htm?version=1?IP=192.168.0.10?USER=pvanamst

    The output is saved to a file called vpnserver.conf, which should look like :
    version=1
    msgtype=configuration
    conn userid_rw_rw
    presharedkey=preshared_key_info_stored_here
    rightsubnet=10.0.1.0/24
    dnsserver=10.0.1.1
    domain=linksys

    The output of the wget command is stored in a file called wget_error.txt, which all going well should look like :
    --04:11:20-- https://userid:*password*@remotelin...n.htm?version=1?IP=192.168.0.10?USER=pvanamst
    => `C://Program Files//Linksys//Linksys VPN Client//vpnserver.conf'
    Resolving remotelinksyshostname.yourdomainname.com... 24.5.173.73
    Connecting to remotelinksyshostname.yourdomainname.com[remotelinksys_ip_address]:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified

    0K 139.65 KB/s

    04:11:29 (139.65 KB/s) - `C://Program Files//Linksys//Linksys VPN Client//vpnserver.conf' saved [143]

    wget is just a simple utility that is shareware that allows you to call a url. So if you go to your browser and call https://userid:*password*@remotelin...ion.htm?version=1?IP=192.168.0.10?USER=userid

    If you get no response from this url, then you need to investigate why the router is not responding to this https request. Maybe you have port forwarding turned on for port 443 (default https port), or the backup port of 60433 ? Either way, you should be able to see the file vpnserver.conf that has the valid connect information with the ip addresses and the presharedkey present. Note that the preshared key will change every 60 mins or so.

    If this step fails, you will get a nice little popup window, showing that you were unable to connect, as the firewall is blocking the connection, or you have entered the incorrect userid/password. But get this first step resolved before you look any further.

    Step 2 - The file ipsec.exe is called, which reads a file called ipsec.conf:
    The ipsec.conf file looks like :

    conn HostToRemote
    left=%any
    right=remotelinksyshostname.yourdomainname.com
    rightsubnet=10.0.1.0/24
    presharedkey=preshared_key_info_stored_here
    auto=start
    pfs=yes

    You can actually run the ipsec command from the command line, with the flag -debug to see what is going on :

    C:\Program Files\Linksys\Linksys VPN Client>ipsec -debug
    IPSec Version 2.2.0 (c) 2001-2003 Marcus Mueller
    Getting running Config ...
    Microsoft's Windows XP identified
    Debugging on.
    Setting up IPSec ...

    Deactivating old policy...
    Removing old policy...

    Connection HostToRemote:
    MyTunnel : 192.168.0.10
    MyNet : 192.168.0.10/255.255.255.255
    PartnerTunnel: remotelinksyshostname.yourdomainname.com
    PartnerNet : 10.0.1.0/255.255.255.0
    CA (ID) : Preshared Key ******************
    PFS : y
    Auto : start
    Auth.Mode : MD5
    Rekeying : 3600S/50000K

    Command 1: ipseccmd -w REG -p FreeSwan -r Host-HostToRemote -t remotelinksyshostname.yourdomainname.com -f 192.168.0.10/255.255.255.255=10.0.1.0/255.255.255.0 -n ESP[MD5,3DES]3600S/50000KPFS -a PRESHARE:"preshared_key_info_stored_here" -lan -1p > NUL:

    Command 2: ipseccmd -w REG -p FreeSwan -r HostToRemote-Host -t 192.168.0.10 -f 10.0.1.0/255.255.255.0=192.168.0.10/255.255.255.255 -n ESP[MD5,3DES]3600S/50000KPFS -a PRESHARE:"preshared_key_info_stored_here" -lan -1p > NUL:
    Activating policy...

    Command 3: ipseccmd -w REG -p FreeSwan -x > NUL:

    C:\Program Files\Linksys\Linksys VPN Client>

    All going well, your tunnel should now be connected and you should be able to ping the local port of the wrv54G, which in this case is 10.0.1.1

    If you get a response saying 'Negotiating IP security' when pinging, it means that the ipsec policy was established, but there is a problem with the wrv54G responding and acknowledging the policy/ipsec tunnel creation.

    A way to debug this, is to turn on the logging for the ipsec stack in windows, by enabling the oakley.log to be created.
    Please follow the steps in the document : https://thesource.ofallevil.com/technet/prodtechnol/windows2000serv/howto/ispstep.mspx
    --- start cut and paste from the above url:
    To enable debug logging by IKE

    1. From the Windows desktop, click Start, click Run, and type regedt32 in the text box. Click OK. This starts the Registry Editor.

    2. Navigate to HKEY_LOCAL_MACHINE on Local Machine.

    3. Navigate to the following location: System\CurrentControlSet\Services\PolicyAgent.

    4. Double-click PolicyAgent.

    5. If the Oakley key doesn't exist, on the Edit menu, click Add Key.

    6. Enter the Key Name (case sensitive): Oakley.

    7. Leave Class blank, and click OK.

    8. Select the new key, Oakley.

    9. On the Edit menu, click Add Value.

    10. Enter the Value Name (case sensitive): EnableLogging

    11. Select Data Type: REG_DWORD and click OK.

    12. Enter value 1

    13. Click Hex as the Radix. Click OK

    14. Exit from the Registry Editor.

    15. At the Windows 2000 command prompt, type net stop policyagent, then type net start policyagent to restart the IPSec related services.

    The file will be written to windir\debug\oakley.log by default, and the file oakley.log.sav is the previous version of the log after the policy agent service is restarted.

    The log is limited to 50,000 entries, which usually limits the file size to less than 6 megabytes.
    --- end cut and paste.

    Now you should be able to look at the oakley.log and see if the policy was created successfully on the PC, and if it was if you are receiving a correct reply from the wrv54G. If all is going well, the oakley.log should look like :

    12-15: 04:11:43:643:cc4 Acquire from driver: op=0000000D src=192.168.0.10.0 dst=10.0.1.1.0 proto = 0, SrcMask=255.255.255.255, DstMask=255.255.255.0, Tunnel 1, TunnelEndpt=remotelinksyshostname.yourdomainname.com Inbound TunnelEndpt=192.168.0.10
    12-15: 04:11:43:643:7f0 Filter to match: Src remotelinksyshostname.yourdomainname.com Dst 192.168.0.10
    12-15: 04:11:43:643:7f0 MM PolicyName: 2
    12-15: 04:11:43:643:7f0 MMPolicy dwFlags 2 SoftSAExpireTime 28800
    12-15: 04:11:43:643:7f0 MMOffer[0] LifetimeSec 28800 QMLimit 1 DHGroup 2
    12-15: 04:11:43:643:7f0 MMOffer[0] Encrypt: Triple DES CBC Hash: SHA
    12-15: 04:11:43:643:7f0 MMOffer[1] LifetimeSec 28800 QMLimit 1 DHGroup 2
    12-15: 04:11:43:643:7f0 MMOffer[1] Encrypt: Triple DES CBC Hash: MD5
    12-15: 04:11:43:643:7f0 MMOffer[2] LifetimeSec 28800 QMLimit 1 DHGroup 1
    12-15: 04:11:43:643:7f0 MMOffer[2] Encrypt: DES CBC Hash: SHA
    12-15: 04:11:43:643:7f0 MMOffer[3] LifetimeSec 28800 QMLimit 1 DHGroup 1
    12-15: 04:11:43:643:7f0 MMOffer[3] Encrypt: DES CBC Hash: MD5
    12-15: 04:11:43:643:7f0 Auth[0]:presharedKey KeyLen 38
    12-15: 04:11:43:643:7f0 QM PolicyName: Host-HostToRemote filter action dwFlags 1
    12-15: 04:11:43:653:7f0 QMOffer[0] LifetimeKBytes 50000 LifetimeSec 3600
    12-15: 04:11:43:653:7f0 QMOffer[0] dwFlags 0 dwPFSGroup -2147483648
    12-15: 04:11:43:653:7f0 Algo[0] Operation: ESP Algo: Triple DES CBC HMAC: MD5
    12-15: 04:11:43:653:7f0 Starting Negotiation: src = 192.168.0.10.0500, dst = 24.5.173.73.0500, proto = 00, context = 0000000D, ProxySrc = 192.168.0.10.0000, ProxyDst = 10.0.1.0.0000 SrcMask = 255.255.255.255 DstMask = 255.255.255.0
    12-15: 04:11:43:653:7f0 constructing ISAKMP Header
    12-15: 04:11:43:653:7f0 constructing SA (ISAKMP)
    12-15: 04:11:43:653:7f0 Constructing Vendor MS NT5 ISAKMPOAKLEY
    12-15: 04:11:43:653:7f0 Constructing Vendor FRAGMENTATION
    12-15: 04:11:43:653:7f0 Constructing Vendor draft-ietf-ipsec-nat-t-ike-02
    12-15: 04:11:43:653:7f0 Constructing Vendor Vid-Initial-Contact
    12-15: 04:11:43:653:7f0
    12-15: 04:11:43:653:7f0 Sending: SA = 0x000EC0A8 to remotelinksyshostname.yourdomainname.com:Type 2.500
    12-15: 04:11:43:653:7f0 ISAKMP Header: (V1.0), len = 276
    12-15: 04:11:43:653:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:43:653:7f0 R-COOKIE 0000000000000000
    12-15: 04:11:43:653:7f0 exchange: Oakley Main Mode
    12-15: 04:11:43:653:7f0 flags: 0
    12-15: 04:11:43:653:7f0 next payload: SA
    12-15: 04:11:43:653:7f0 message ID: 00000000
    12-15: 04:11:43:653:7f0 Ports S:f401 D:f401
    12-15: 04:11:44:554:7f0
    12-15: 04:11:44:554:7f0 Receive: (get) SA = 0x000ec0a8 from 24.5.173.73.500
    12-15: 04:11:44:554:7f0 ISAKMP Header: (V1.0), len = 84
    12-15: 04:11:44:554:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:44:554:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:44:554:7f0 exchange: Oakley Main Mode
    12-15: 04:11:44:554:7f0 flags: 0
    12-15: 04:11:44:554:7f0 next payload: SA
    12-15: 04:11:44:554:7f0 message ID: 00000000
    12-15: 04:11:44:554:7f0 processing payload SA
    12-15: 04:11:44:554:7f0 Received Phase 1 Transform 2
    12-15: 04:11:44:554:7f0 Encryption Alg Triple DES CBC(5)
    12-15: 04:11:44:554:7f0 Hash Alg MD5(1)
    12-15: 04:11:44:554:7f0 Oakley Group 2
    12-15: 04:11:44:554:7f0 Auth Method Preshared Key(1)
    12-15: 04:11:44:554:7f0 Life type in Seconds
    12-15: 04:11:44:554:7f0 Life duration of 28800
    12-15: 04:11:44:554:7f0 Phase 1 SA accepted: transform=1
    12-15: 04:11:44:554:7f0 SA - Oakley proposal accepted
    12-15: 04:11:44:554:7f0 ClearFragList
    12-15: 04:11:44:554:7f0 constructing ISAKMP Header
    12-15: 04:11:44:604:7f0 constructing KE
    12-15: 04:11:44:604:7f0 constructing NONCE (ISAKMP)
    12-15: 04:11:44:604:7f0
    12-15: 04:11:44:604:7f0 Sending: SA = 0x000EC0A8 to remotelinksyshostname.yourdomainname.com:Type 2.500
    12-15: 04:11:44:604:7f0 ISAKMP Header: (V1.0), len = 184
    12-15: 04:11:44:604:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:44:604:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:44:604:7f0 exchange: Oakley Main Mode
    12-15: 04:11:44:604:7f0 flags: 0
    12-15: 04:11:44:604:7f0 next payload: KE
    12-15: 04:11:44:604:7f0 message ID: 00000000
    12-15: 04:11:44:604:7f0 Ports S:f401 D:f401
    12-15: 04:11:45:556:7f0
    12-15: 04:11:45:556:7f0 Receive: (get) SA = 0x000ec0a8 from 24.5.173.73.500
    12-15: 04:11:45:556:7f0 ISAKMP Header: (V1.0), len = 180
    12-15: 04:11:45:556:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:45:556:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:45:556:7f0 exchange: Oakley Main Mode
    12-15: 04:11:45:556:7f0 flags: 0
    12-15: 04:11:45:556:7f0 next payload: KE
    12-15: 04:11:45:556:7f0 message ID: 00000000
    12-15: 04:11:45:556:7f0 processing payload KE
    12-15: 04:11:45:576:7f0 processing payload NONCE
    12-15: 04:11:45:576:7f0 ClearFragList
    12-15: 04:11:45:576:7f0 constructing ISAKMP Header
    12-15: 04:11:45:576:7f0 constructing ID
    12-15: 04:11:45:576:7f0 MM ID Type 1
    12-15: 04:11:45:576:7f0 MM ID c0a8000a
    12-15: 04:11:45:576:7f0 constructing HASH
    12-15: 04:11:45:576:7f0
    12-15: 04:11:45:576:7f0 Sending: SA = 0x000EC0A8 to remotelinksyshostname.yourdomainname.com:Type 2.500
    12-15: 04:11:45:576:7f0 ISAKMP Header: (V1.0), len = 60
    12-15: 04:11:45:576:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:45:576:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:45:576:7f0 exchange: Oakley Main Mode
    12-15: 04:11:45:576:7f0 flags: 1 ( encrypted )
    12-15: 04:11:45:576:7f0 next payload: ID
    12-15: 04:11:45:576:7f0 message ID: 00000000
    12-15: 04:11:45:576:7f0 Ports S:f401 D:f401
    12-15: 04:11:46:557:7f0
    12-15: 04:11:46:557:7f0 Receive: (get) SA = 0x000ec0a8 from 24.5.173.73.500
    12-15: 04:11:46:557:7f0 ISAKMP Header: (V1.0), len = 60
    12-15: 04:11:46:557:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:46:557:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:46:557:7f0 exchange: Oakley Main Mode
    12-15: 04:11:46:557:7f0 flags: 1 ( encrypted )
    12-15: 04:11:46:557:7f0 next payload: ID
    12-15: 04:11:46:557:7f0 message ID: 00000000
    12-15: 04:11:46:557:7f0 processing payload ID
    12-15: 04:11:46:557:7f0 processing payload HASH
    12-15: 04:11:46:557:7f0 AUTH: Phase I authentication accepted
    12-15: 04:11:46:557:7f0 ClearFragList
    12-15: 04:11:46:557:7f0 MM established. SA: 000EC0A8
    12-15: 04:11:46:557:7f0 QM PolicyName: Host-HostToRemote filter action dwFlags 1
    12-15: 04:11:46:557:7f0 QMOffer[0] LifetimeKBytes 50000 LifetimeSec 3600
    12-15: 04:11:46:557:7f0 QMOffer[0] dwFlags 0 dwPFSGroup -2147483648
    12-15: 04:11:46:557:7f0 Algo[0] Operation: ESP Algo: Triple DES CBC HMAC: MD5
    12-15: 04:11:46:557:7f0 GetSpi: src = 10.0.1.0.0000, dst = 192.168.0.10.0000, proto = 00, context = 0000000D, srcMask = 255.255.255.0, destMask = 255.255.255.255, TunnelFilter 1
    12-15: 04:11:46:557:7f0 Setting SPI 1849049420
    12-15: 04:11:46:557:7f0 constructing ISAKMP Header
    12-15: 04:11:46:557:7f0 constructing HASH (null)
    12-15: 04:11:46:557:7f0 constructing SA (IPSEC)
    12-15: 04:11:46:557:7f0 constructing QM KE
    12-15: 04:11:46:607:7f0 constructing NONCE (IPSEC)
    12-15: 04:11:46:607:7f0 constructing ID (proxy)
    12-15: 04:11:46:607:7f0 constructing ID (proxy)
    12-15: 04:11:46:607:7f0 constructing HASH (QM)
    12-15: 04:11:46:607:7f0
    12-15: 04:11:46:607:7f0 Sending: SA = 0x000EC0A8 to remotelinksyshostname.yourdomainname.com:Type 2.500
    12-15: 04:11:46:607:7f0 ISAKMP Header: (V1.0), len = 300
    12-15: 04:11:46:607:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:46:607:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:46:607:7f0 exchange: Oakley Quick Mode
    12-15: 04:11:46:607:7f0 flags: 1 ( encrypted )
    12-15: 04:11:46:607:7f0 next payload: HASH
    12-15: 04:11:46:607:7f0 message ID: c22f2bc6
    12-15: 04:11:46:607:7f0 Ports S:f401 D:f401
    12-15: 04:11:47:198:7f0
    12-15: 04:11:47:198:7f0 Receive: (get) SA = 0x000ec0a8 from 24.5.173.73.500
    12-15: 04:11:47:198:7f0 ISAKMP Header: (V1.0), len = 300
    12-15: 04:11:47:198:7f0 I-COOKIE 593b334649fe1f50
    12-15: 04:11:47:198:7f0 R-COOKIE b2acc5a80ae7e6aa
    12-15: 04:11:47:198:7f0 exchange: Oakley Quick Mode
    12-15: 04:11:47:198:7f0 flags: 1 ( encrypted )
    12-15: 04:11:47:198:7f0 next payload: HASH
    12-15: 04:11:47:198:7f0 message ID: c22f2bc6
    12-15: 04:11:47:198:7f0 Received commit re-send
    12-15: 04:11:47:198:7f0 processing HASH (QM)
    12-15: 04:11:47:198:7f0 ClearFragList
    12-15: 04:11:47:198:7f0 processing payload NONCE
    12-15: 04:11:47:198:7f0 processing payload KE
    12-15: 04:11:47:198:7f0 Quick Mode KE processed; Saved KE data
    12-15: 04:11:47:198:7f0 processing payload ID
    12-15: 04:11:47:198:7f0 processing payload ID
    12-15: 04:11:47:198:7f0 processing payload SA
    12-15: 04:11:47:198:7f0 Negotiated Proxy ID: Src 192.168.0.10.0 Dst 10.0.1.0.0
    12-15: 04:11:47:198:7f0 Dst id for subnet. Mask 255.255.255.0
    12-15: 04:11:47:198:7f0 Checking Proposal 1: Proto= ESP(3), num trans=1 Next=0
    12-15: 04:11:47:208:7f0 Checking Transform # 1: ID=Triple DES CBC(3)
    12-15: 04:11:47:208:7f0 SA life type in seconds
    12-15: 04:11:47:208:7f0 SA life duration 00000e10
    12-15: 04:11:47:208:7f0 SA life type in kilobytes
    12-15: 04:11:47:208:7f0 SA life duration 0000c350
    12-15: 04:11:47:208:7f0 tunnel mode is Tunnel Mode(1)
    12-15: 04:11:47:208:7f0 HMAC algorithm is MD5(1)
    12-15: 04:11:47:208:7f0 group description for PFS is 2
    12-15: 04:11:47:208:7f0 Phase 2 SA accepted: proposal=1 transform=1
    12-15: 04:11:47:218:7f0 constructing ISAKMP Header
    12-15: 04:11:47:218:7f0 constructing HASH (QM)
    12-15: 04:11:47:218:7f0 Adding QMs: src = 192.168.0.10.0000, dst = 10.0.1.0.0000, proto = 00, context = 0000000D, my tunnel = 192.168.0.10, peer tunnel = remotelinksyshostname.yourdomainname.com, SrcMask = 0.0.0.0, DestMask = 255.255.255.0 Lifetime = 3600 LifetimeKBytes 50000 dwFlags 201 Direction 2 EncapType 1
    12-15: 04:11:47:218:7f0 Algo[0] Operation: ESP Algo: Triple DES CBC HMAC: MD5
    12-15: 04:11:47:218:7f0 Algo[0] MySpi: 1849049420 PeerSpi: 3393993032
    12-15: 04:11:47:218:7f0 Encap Ports Src 500 Dst 500
    12-15: 04:11:47:218:7f0 Skipping Outbound SA add
    12-15: 04:11:47:218:7f0 Adding QMs: src = 192.168.0.10.0000, dst = 10.0.1.0.0000, proto = 00, context = 0000000D, my tunnel = 192.168.0.10, peer tunnel = remotelinksyshostname.yourdomainname.com, SrcMask = 0.0.0.0, DestMask = 255.255.255.0 Lifetime = 3600 LifetimeKBytes 50000 dwFlags 201 Direction 3 EncapType 1
    12-15: 04:11:47:218:7f0 Algo[0] Operation: ESP Algo: Triple DES CBC HMAC: MD5
    12-15: 04:11:47:218:7f0 Algo[0] MySpi: 1849049420 PeerSpi: 3393993032
    12-15: 04:11:47:218:7f0 Encap Ports Src 500 Dst 500
    12-15: 04:11:47:218:7f0 Skipping Inbound SA add
    12-15: 04:11:47:218:7f0 isadb_set_status sa:000EC0A8 centry:000E34E8 status 0

    Either way, look for the:

    Sending: SA = 0x000EC0A8 to remotelinksyshostname.yourdomainname.com:500
    and the corresponding response back from the wrv54G:
    Receive: (get) SA = 0x000ec0a8 from remotelinksyshostname.yourdomainname.com.500

    The final phase of what the quickvpn client does is to show you 'Verifying network'. During this phase it runs a small utility to set your dns server to the lan IP address of the wrv54G, which is 10.0.1.1. It does this using :

    Command 3: ipseccmd -w REG -p FreeSwan -x > NUL:

    C:\Program Files\Linksys\Linksys VPN Client>rw_regedit
    Usage Error: Invalid number of arguments
    Usage: program_name NAMESERVER|SEARCHLIST EDIT|DELETE [VALUE]

    When you disconnect, it calls the ipsec.exe to kill the ipsec connection.

    Good luck and I hope that this small update will help you debug which of the various steps the quickvpn client is failing on.

    One other note. Using the wrv54g firmware of 2.39.2, I have noticed that you can not create two concurrent vpn tunnels if both client PC's are behind a Nat IP address. So if the PC's address starts with 10.x.x.x, or 172.x.x.x, or 192.168.x.x, you are very likely to be behind a NAT box, like another linksys router. Only one vpn tunnel can be created at any one time due to a limitation in the IPSEC software on the wrv54G. I will call linksys one of these days and see if they are willing and wanting to look into this issue.

    Good luck !
     
  5. kingvj

    kingvj Network Guru Member

    seriously, a very good informative posting...!!
     
  6. Toxic

    Toxic Administrator Staff Member

    FYI from v1.0.47 onwards QuickVPN will use Certificates. along with new firmware updates for any QuickVPN featured Router.

    The RV042 RV082 RV016 and WRV200 models have new firmwares to allow certificates now. (available on downloads) more firmwares for other models will come in due time i guess.
     
  7. DocLarge

    DocLarge Super Moderator Staff Member Member

    I just finished a telephone conversation with a user who was having connection problems of the traditional nature (quickvpn hanging at "verifying network") :) Quickvpn "is what it is" unfortunately. Since day one, it either connects and works, connects and stops working, or doesn't connect at all (i.e "verifying network"). Per the "Quickvpn Setup Guide," a general reboot of the router "use" to be the quickfix, but with each new version of quickvpn being released, there's always a new anomaly...

    Regarding today's support call, I initially tried connecting with the latest "certificate" enabled quickvpn client and couldn't connect to a WRV54G he was setting up for a client (neither could he or his client). I switched to an older version of quickvpn I had on my laptop and I connected straight away (I was even able to ping). Once I did that, then all of a sudden, the certificate enable version of quickvpn started connecting; *shrug* go figure... My guess is that something in the routing table was hung and the older version of quickvpn managed to push through.

    My personal approach to continued quickvpn troubleshooting in the future is just to rotate between quickvpn versions 1.0.40 (which I believe I used) and the latest versions to see if it's actually not the client causing the problems. Granted, by doing these things, I've always had a successful quickvpn deployment :)

    Jay
     
  8. cjtechnical

    cjtechnical LI Guru Member

    Negotiating IPSEC can connect but not ping

    I too went through this with the RV042.
    I fixed it though.
    :) The isssue is that you are on a network that is not passing ESP. this is a protocol like tcp/ip.
    If you use a sniffer, isused Etherreal, which is free you will see that after the connection all traffic uses esp. if there is no esp you get no connectivity although the vpn software states connected.

    You would think this would be in the documentation as it is not sending its traffic through upd as it should.

    You would have the same scenario if pptp did not work and your firewall did not allow gre.
     
  9. Kremlar

    Kremlar LI Guru Member

    So, how do you solve this?
     
  10. aviegas

    aviegas Network Guru Member

    After all the investigation I've done with QuickVPN I think there are 2 sources of problems:

    1) The router side of the code still has many bugs. It works differently on different routers. Some problems will require a router reboot, some require the QuickVPN userid to be deleted and then re-created, some will only go away with a full hardware reset (erase the configuration). I've seen this on the RV042, RV082 and I know of some stories with the RVS4000 and WRV54G.

    2) The QuickVPN client is just a shell on top of several other "tools":

    - Authentication, that is a HTTPS (SSL) session is performed by GNU WGET
    (this is used to setup a connection, terminate a connection and to change passwords)

    - SSL/TLS stack as well as the certificate processing is performed by WGET using SSLeay

    - IPSec policy management (policy definition) is perfomed by IPSEC.EXE by Marcus Müeler. QuickVPN will pass the connection information to IPSEC.EXE (in ipsec.conf) that will create the necessary commands to define the IPSec policies for the tunnel.

    - IPSec policy commands (add and remove) is performed by Microsoft tools such as ipseccmd.exe (WinXP) and ipsecpol.exe (Win200)

    - The actual IPSec and IKE implementation is Microsoft's own code, that is part of Windows

    Integrating all these tools is not simple and sometimes the client code fails too (some corrupt files are left in the directory).

    There are also problems related to the way that each "component" handle the local IP address. QuickVPN has to make it's own guess to use in the SSL Authentication. Next IPSEC.EXE will do it again and on some machines configurations (more than one physical/logical adapter) the result may be different.

    Bottom line: there is still a lot to be done on both the client and server side for QuickVPN to become reliable.
     
  11. aviegas

    aviegas Network Guru Member

    Another source of problems with QuickVPN can be attributed to usage error. A configuration/setup know to work from one location may fail from another.

    The most common causes of problems are:

    a) Windows XP SP2 introduced a bug that will cause the Windows Firewall to filter ICMP packets on IPSec tunnels (and therefore it will not work). More details and the fix can be found at:

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

    Symptom: QuickVPN will never connect

    How to test: disable Windows XP firewall and give it a try


    b) User may be connecting for behind a firewall that do not support IPSec passthru or has a limited capability in that respect or even do not allow IPSec and/or IKE.

    Symptom: QuickVPN may connect (if IKE works) but traffic will never flow.

    How to test: connect from another location


    c) The network address of the user may conflict with the remote network. Since most users are roaming, they connect from a different address each time. If the address is public, a conflict will probably never occur as the remote network is normally a private address (defaulting to 192.168.1/24). But if the user is connecting from a private network, then a conflict may occur.

    This one is more common than one may think of as the defaults for most SOHO routers is to assign networks on the 192.68.1/24 network.

    Symptom: QuickVPN will say there is a "error", but no detailed explanation

    How to test: One can use a web browser to check it, but the procedure is a bit complex.
     

Share This Page