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

WRV54G, QuickVPN, Verifying network...

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by vfervers, Jan 4, 2006.

  1. vfervers

    vfervers Network Guru Member

    Hi!

    I'm rather near to the solution, only a small little step, I think, is missing. "Verifying network" ist the last message (appr. 15secs) before QuickVPN tells me that the remote network is not responding.

    Client side
    WXP (on VMware on Linux)
    Linux 2.6.11 with iptables/masquerading
    DSL-Modem
    ...
    Server side
    WAG54G (DSL-Modem/Router)
    WAN-IP from ISP/dyndns
    LAN 192.168.115.254
    ...
    Cat5
    ...
    WRV54G
    WAN 192.168.115.252
    LAN 192.168.116.252

    syslog of a connection attempt shows two errors; see below:

    1.) Error resolving hostname: ""
    2.) Error resolving hostname: "0.0.0.0/0"

    Could the firewall on the linux box cause the failure? (I thought using QuickVPN would use SSL, so a firewall shouldn't be a problem)

    I forwarded 443 and 500 from WAG to WRV and enabled IPSEC passthrough on the WRV. (But the passthrough is a VPN-client option, isn't it?)

    ipsec.conf and vpnserver.conf in the QuickVPN directory on the client are initialized correctly, as far as I can tell.

    Thank you for any suggestions what I could try next.

    Volker

    syslog:
    ======
    Jan 4 12:31:30 wrv54g 2006 wrv54g Jan 4 11:31:29 pluto[33]: added connection description "ips50"
    Jan 4 12:31:30 wrv54g 2006 wrv54g Jan 4 11:31:29 pluto[33]: listening for IKE messages
    Jan 4 12:31:30 wrv54g 2006 wrv54g Jan 4 11:31:29 pluto[33]: forgetting secrets
    Jan 4 12:31:30 wrv54g 2006 wrv54g Jan 4 11:31:30 pluto[33]: "ips50": cannot initiate connection without knowing peer IP address
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:46 pluto[33]: forgetting secrets
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:46 pluto[33]: "ips50": deleting connection
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:50 pluto[33]: added connection description "ips50"
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:50 pluto[33]: listening for IKE messages
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:50 pluto[33]: forgetting secrets
    Jan 4 12:31:50 wrv54g 2006 wrv54g Jan 4 11:31:50 pluto[33]: "ips50": cannot initiate connection without knowing peer IP address
    Jan 4 12:32:05 wrv54g 2006 wrv54g Jan 4 11:32:05 pluto[33]: packet from 217.187.171.204:500: ignoring Vendor ID payload
    Jan 4 12:32:05 wrv54g last message repeated 3 times
    Jan 4 12:32:05 wrv54g 2006 wrv54g Jan 4 11:32:05 pluto[33]: "ips50"[1] 217.187.171.204 #5: responding to Main Mode from unknown peer 217.187.171.204
    Jan 4 12:32:05 wrv54g 2006 wrv54g Jan 4 11:32:05 pluto[33]: "ips50"[1] 217.187.171.204 #5: OAKLEY_SHA is disabled. Attribute OAKLEY_HASH_ALGORITHM
    Jan 4 12:32:07 wrv54g 2006 wrv54g Jan 4 11:32:07 pluto[33]: packet from 217.187.171.204:500: ignoring Vendor ID payload
    Jan 4 12:32:07 wrv54g last message repeated 3 times
    Jan 4 12:32:07 wrv54g 2006 wrv54g Jan 4 11:32:07 pluto[33]: "ips50"[1] 217.187.171.204 #6: responding to Main Mode from unknown peer 217.187.171.204
    Jan 4 12:32:07 wrv54g 2006 wrv54g Jan 4 11:32:07 pluto[33]: "ips50"[1] 217.187.171.204 #6: OAKLEY_SHA is disabled. Attribute OAKLEY_HASH_ALGORITHM
    Jan 4 12:32:11 wrv54g 2006 wrv54g Jan 4 11:32:11 pluto[33]: "ips50"[1] 217.187.171.204 #5: discarding duplicate packet; already STATE_MAIN_R2
    Jan 4 12:32:11 wrv54g 2006 wrv54g Jan 4 11:32:11 pluto[33]: "ips50"[1] 217.187.171.204 #5: IP address 217.187.171.204 was added to block-IP list
    Jan 4 12:32:12 wrv54g 2006 wrv54g Jan 4 11:32:12 pluto[33]: "ips50"[1] 217.187.171.204 #5: Main mode peer ID is ID_IPV4_ADDR: '192.168.138.24'
    Jan 4 12:32:12 wrv54g 2006 wrv54g Jan 4 11:32:12 pluto[33]: "ips50"[1] 217.187.171.204 #5: sent MR3, ISAKMP SA established
    Jan 4 12:32:12 wrv54g 2006 wrv54g Jan 4 11:32:12 pluto[33]: "ips50"[1] 217.187.171.204 #5: IP address 217.187.171.204 was removed from block-IP list
    Jan 4 12:32:15 wrv54g 2006 wrv54g Jan 4 11:32:15 pluto[33]: "ips50"[1] 217.187.171.204 #7: responding to Quick Mode
    Jan 4 12:32:16 wrv54g 2006 wrv54g Jan 4 11:32:16 pluto[33]: "ips50"[1] 217.187.171.204 #7: discarding duplicate packet; already STATE_QUICK_R1
    Jan 4 12:32:28 wrv54g 2006 wrv54g Error resolving hostname: ""
    Jan 4 12:32:28 wrv54g 2006 wrv54g Jan 4 11:32:28 pluto[33]: "ips50"[1] 217.187.171.204 #7: IPsec SA established
    Jan 4 12:32:30 wrv54g 2006 wrv54g Error resolving hostname: "0.0.0.0/0"
    Jan 4 12:32:30 wrv54g last message repeated 2 times
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: "ips50"[1] 217.187.171.204 #5: received Delete SA payload: deleting IPSEC State #7
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: "ips50"[1] 217.187.171.204 #5: received and ignored informational message
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: "ips50": cannot initiate connection without knowing peer IP address
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: attempt to redefine connection "ips50"
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: listening for IKE messages
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: forgetting secrets
    Jan 4 12:32:56 wrv54g 2006 wrv54g Jan 4 11:32:56 pluto[33]: "ips50": cannot initiate connection without knowing peer IP address
    Jan 4 12:33:12 wrv54g 2006 wrv54g Jan 4 11:33:10 pluto[33]: forgetting secrets
    Jan 4 12:33:12 wrv54g 2006 wrv54g Jan 4 11:33:10 pluto[33]: "ips50": deleting connection
    Jan 4 12:33:12 wrv54g 2006 wrv54g Jan 4 11:33:10 pluto[33]: "ips50"[1] 217.187.171.204: deleting connection "ips50" instance with peer 217.187.171.204
    Jan 4 12:33:12 wrv54g 2006 wrv54g Jan 4 11:33:10 pluto[33]: "ips50" #6: deleting state (STATE_MAIN_R1)
    Jan 4 12:33:12 wrv54g 2006 wrv54g Jan 4 11:33:10 pluto[33]: "ips50" #5: deleting state (STATE_MAIN_R3)
     
  2. DocLarge

    DocLarge Super Moderator Staff Member Member

    I'm going to write another quick guide on setting up a WRV54G behind another router, because this type of configuration is becoming a common thing now :)

    Ports 443 and 500 are automatically (and statically) open on the WRV54G, so unless you're a programmer with the code, you "can not" shut these ports off. They're designed this way in order to listen for quickvpn connection attempts.

    So, I'd suggest turning off the Linux firewall and any other firewall you may have running "until" you can get a connection. Additionally, you should turn off the firewall on the WRV because the double NAT'ing is sometimes a problem for the quickvpn to receive the acknowledgement back from the WRV54G...

    Last but not least, if you haven't looked at the "Quickvpn Setup Guide" in the sticky area, check and see if you have any other vpn clients running; ensure the pptp server "does not" have a tunnel enabled because you can't do both (PPTP and Quickvpn) at the same time; "one" or the "other" has to be running.

    I've got my WRV54G behind an SMCBR18VPN router and I have no problems connecting with quickvpn, so you're setup is right, just knock out the small problems in between and you'll be connected..

    Doc
     
  3. I am in a very similar state, but have found a very odd behavior. I setup the system and would get the error "router not responding ....). So I had my boss try it thought maybe it was my laptop. Yep he is on no problems. So for the fun of it when I got the msg since I noticed the green icon on in the tool bar I thought what the heck try my shared drive. It works. As long as I don’t click the ok on the error. My thought is something on my computer is causing the problem but have no idea how to figure it out. Any suggestions? Also is there a way to forward the workgroup names over the VPN so I can see all computers in the workgroup?

    Thanks, Very close to having this all work. BTW I have Flash 2.38
     
  4. vfervers

    vfervers Network Guru Member

    Good morning!

    This is ok. I understand, that these ports are forwarded and caught by the WRV in this "chained" setup. I realized it (for 443) when I was able to call the setup of the WRV (with disabled WRV-firewall) allthough the remote configuration was disabled.

    I'll try this and report.

    This firewall was already switched off; only the one on the WAG was active serversided.

    Thanks a lot!
    Volker

    PS.: Linksys support answered on this subject and gave me the advice to additionally forward ports 1723 and 43. Can somebody comment on this?
     
  5. DocLarge

    DocLarge Super Moderator Staff Member Member

    No, you do "not" need to forward ports 1723 and 43, which actually they meant 443. 1723 would be forwarded if you were running a vpn server (which you are not) "behind" the wrv54g, and 443 is already enabled by default from the linksys factory.
     
  6. vfervers

    vfervers Network Guru Member

    And I was wondering about the reason for "whois" in this scenario ;-)

    I switched off the firewall. No go. Same error "The gateway is not responding...". I have the same state posted above by silver2k1cobra: a green dot in the taskbar, the DNS server is set (ipconfig/all) and the WRV shows on the Status/VPN page the user as connected.

    On monday I will go to the server side of the game and see what I can do over there. Maybe at first directly connect the WRV to a DSL-modem; this was the setup I successfully tested in the beginning.

    By the way: why is this called _Quick_VPN...
     
  7. DocLarge

    DocLarge Super Moderator Staff Member Member

    If you've ever configured greenbow vpn client or ssh sentinel vpn client, you spend a little bit of time putting in your configuration. Quickvpn (under ideal situations or "excellent" configuration) is "click and shoot." I've been using this tool for a little while and , yes, it does work when you figure out the litte nuances...

    So, yes, it is quickvpn once you understand the ideal configuration of the computer that it will reside on...


    Doc
     
  8. vfervers

    vfervers Network Guru Member

    After two days of trying with the WAG-WRV setup without positive result I decided to take the easy way out and connect the WRV directly to a DSL-Modem on the server side. The expected result occured: "Verifying Network....".

    To exclude funny things happening with my VMware setup on the client side I used the WAG to connect to the internet and installed a fresh copy of QuickVPN on a Laptop wirelessly connected to the WAG. IPSec passthrough enabled. Surpringly "Verifying Network...." occurred. (Different errors on the WRV: "Error in RNAT configuration bla").

    May be I'm a stupid white man or this is a stupid silverish box. I just wanted to give my users a simple tool to access their resources on the intranet. Just install, enter username, password and FQDN and let go.

    Doc, is there some guide on building a VPN "manually"? PPTP with MSChapV2 or alike?

    Volker
     
  9. DocLarge

    DocLarge Super Moderator Staff Member Member

    But of course!!! I'm all over this here technology they call VPN!!

    Here's a link to a video I put together showing how to configure a 2003 Microsoft VPN PPTP server. This will get you by until you find out what's happening with your quickvpn connection. Quickvpn is "fickle" as Hell. Yes, it should work right out of the box, but because a lot of people have various software configurations, this plays Hell with quickvpn, and if it doesn't like an application on your box, quickvpn "ain't starting."

    http://www.dslreports.com/forum/remark,15190829

    You can download a free 6 month trial version of 2003 Enterprise server from microsoft. Make sure you downlod the codec from Techsmith.com so you can watch the video.

    LITTLE KNOWN FACT:

    If you want to establish a gateway between a WAG and a WRV, make sure the preshared key has an "x" in the key. Example given: toycarx1234 or 0x12345

    I set up a tunnel between a WAG54G and a WRV54G daily and always connect (the WAG54G is running 1.01.6 firmware). Hell, I had the WAG54G running two tunnels; both tunnels were routing to WRV54G's!!

    But forgive me, I boast... :)

    Doc
     
  10. vfervers

    vfervers Network Guru Member

    Doc,

    thanks for your answer! I let Linksys support remotely test the WRV. They added new users for VPN access ("tester", "vpnuser2" and "LINKSYS") and had success in connecting via QuickVPN. I checked it and could at least connect as "LINKSYS". After this connect the other accounts worked also.

    Slowly I am running out of black chickens and bat blood...

    OK. Now that I am successfully connected in 5 out of 10 times I began to test copying files to and from. The result were intermittent well known popups "The remote gateway is not responding..." from QuickVPN and something like "Delayed write failed...Data lost" from our beloved Windows (TM) OS when I used Total Commander to copy the files.

    Setting the MTU an XP and the WAG (both client side) to 1492 (tested with ping -f -l 1464...) didn't have influence on the error messages.

    The "Remote gateway" thing seems to be a hoax, klicking it away doesn't do any harm to the connection. The only time the connection dies is when my client-sided WAG becomes upset about the tunnel and decides that this is a reason to reboot.

    My users and I am not very amused about this tricky hard/soft combination. I would not be able to give any support to them when they have connection problems, because there is no known working standardized setup like: "take WinXP Home, SP2, Hotfix 123 and then click and connect". I would only be able to tell them: try this, no?, try that, I don't know either.

    I'll give this four more years, eh, one more week and then may look for a different solution.

    Again, Doc: Thank you for your help!
    Volker
     
  11. DocLarge

    DocLarge Super Moderator Staff Member Member

    FYI, the best working point when running the MTU test is set either the MTU on the router to Manual/1350 "or" set your machines to 1350.

    I ran into the MTU issue and using one of the two mentioned settings above fixed my problem. It's easier to set your systems by using "DR TCP", which you can download, and it's free.

    Just in case you didn't know, you "can't" run a tunnel between your WAG and your WRV and expect quickvpn to work. It has to be either quickvpn "or" a "router to router" configuration.

    Doc
     
  12. vfervers

    vfervers Network Guru Member

    At kb.linksys.com I found the advice to set the MTU to 1428 and decrementing (Answer ID 2736):

    http://linksys.custhelp.com/cgi-bin...nMuc2VhcmNoX25sJnBfcGFnZT0x&p_li=&p_topview=1

    MTU=1428 on the client (WinXPH), the client WAG54G and the WRV54G showed no effect. Will try 1350 on the client and AUTO on WAG and WRV.

    Volker
     
  13. DocLarge

    DocLarge Super Moderator Staff Member Member

    80% of the information you see on this Linksys page came from the "Quickvpn Setup Guide" copy I sent to them this past summer. So, not to sound cocky, you might want to follow my lead :)

    Here's the page I used to reference some information regarding how to check the mtu setting, followed by using Dr TCP to make the final registry setting on your computer:

    http://www.zdnetasia.com/insight/network/0,39044847,39089320-1,00.htm

    The linksys techs are "outsourced flunkies," so on any given day, one of them will tell you some shit like, "Oh, you need to open port 47 for VPN." The 47 they are referring to is actually the "Generic Routing Encapsulation (GRE) Protocol and "not" a port, because the actual port (47) runs NFTP, or something along those lines...

    The standard ethernet setting (maximum) on all windows OS's is normally 1500 (the maximum for ethernet). What I've found is by taking down to 1350 (or lower), it allows for packets to make it through while still giving you adequate web page refresh while surfing...

    Give it a run and see for yourself :)

    The worst that can happen is it doesn't work, and something else has to be tried...

    Doc
     
  14. vfervers

    vfervers Network Guru Member

    I tried and I was successful in having a 4 1/2 hour connection with the WRV! (MTU=1350 on the XP client, auto on client sided router and server sided router. The reason for the abort of the connection was my client side WAG router, which reconnected to my ISP and got a new IP adddress; but this is another story) Minor inconveniences: The well known "Remote gateway not responding" popup and some connection attempts failed.

    But I think, I will give it a try in the field. Thank you, Doc, for your valuable support!

    Volker
     

Share This Page