Help Running QuickVPN Behind a Router

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by clambert11, Nov 27, 2005.

  1. clambert11

    clambert11 Network Guru Member

    Ok I have a Linksys RTV042 that I would like to connect to remotely through other routers. Currently at home I have a WRT56GS running dd-wrt's v23 firmware.

    I can connect to the RV042 fine if I remove the router from the picture and connect directly from the cable modem.

    The error happens instantly when I try and connect behind my router and reads...

    I have Zone Alarm disabled. Anyone have any ideas what might be going on?

    I called tech support and they didn't help much. They said I needed to forward ports 1723, 500, and 47-50 in my router. I also tried disabling the WRT54GS' firewall per their advice. Still no luck.

    It's worth mentioning again that I can connect successfully if I bypass my router. The error happens instantly when I'm behind it as if it's not even trying.

    IPSec Passthrough, PPTP Passthrough, and L2TP Passthrough are enabled on both routers. I'm unsure if that matters.

    Additionally the router IP for the RV042 is The router IP for the WRT54GS is

    FWIW... The QuickVPN Setup on on is gone right now. Anyone have another link that might help?

    Thanks in advance to anyone that can help!

    -- Craig
  2. TazUk

    TazUk Network Guru Member

    Is that a typo or are both routers using the same subnet i.e. 192.168.1.x, if they are then you'll need to change one of them.
  3. DocLarge

    DocLarge Super Moderator Staff Member Member

    I just emailed the guide to you, Craig. In case anyone else is interested, the issue here is the old "missing NAT/T" function. Short version, you can make the request of the RV, but it won't return the handshake because it "can't" read the encapsulated request due to NAT running on Craig's WRT54GS! Therefore, the request to establish the tunnel is dropped by the RV. Normally, you can connect with quickvpn from behind "any" consumer or high-end router. It's just when you use third party clients (greenbow, ssh sentinel, safenet remote) behind other routers (and the above mentioned) where you can't connect "unless" you bypass the routers and connect directly to your modem.

    I know some of you have heard me say this countless times, but "I" and others feel Linksys did this on purpose to market quickvpn, plain and simple.

    At this stage, it doesn't look like Linksys will ever fix it so here's the solution: put a NAT/T enabled router "in front" as your gateway router and your WRV54G and RV0XX routers will work fine, trust me on this.

    I have an SMCBR18VPN router as my gateway connection with my WRV54G behind it. Forwarding ports 1723, 47, and 50 have absolutely "NOTHING" to do with IPSEC. Ports 443 and 500 are opened "exclusively" on the WRV54G and RV0XX routers to listen for quickvpn connections, period. 1723 is for PPTP, while PORT 47 is for NI FTP and PORT 50 is for tcp/udp remote mail checking:

    The tech was attempting to tell you need port 47 because he confused port 47 with PROTOCOL 47 which is generic routing encapsulation (GRE), which is what port 1723 uses for PPTP encryption. The WRV54G and RV0XX series have built in PPTP servers that "do not" require port 1723 to be opened "unless" you have a vpn server running behind the router. Then "and only then" would you forward 1723; should you have to do this, you'd forward 1723 on your router to the ip address of the device that's hosting the vpn server connection.

    Getting back on track, I have ports 443 and 500 forwarded on my SMC to my WRV54G because a CAT5 cable is running from one of the eight LAN ports to the "WAN" port of my WRV54G. It (WRV54G) has an ip address from the SMC "but" it (WRV54G) has a separate LAN ip address so as no to conflict with the SMC. The result is two distinct subnets passing traffic to the same gateway to the internet. Oh, quickvpn works "perfectly in this configuration.



    Good call Taz, I looked at the identical ip's and forgot to address it earlier because I was blabbering so much...

    Craig, if it turns out you can't connect because of IP misconfig's, great. If changing the IP's still don't work, try another router until you get you're other one up and running with original firmware.
  4. clambert11

    clambert11 Network Guru Member

    Thanks for all this info. So ultimately it's the WRT54GS itself and not the firmware. Why couldn't they just tell me that on the phone?

    This is mainly for a client of mine, although I would like to get it running myself. Is there a list of routers that support NAT-T? I did a quick search and didn't see anything. This VPN world is all new to me. :)

    I'm sure I will have more questions after I read through your Guide.

    Thanks for all your help.

    -- Craig
  5. clambert11

    clambert11 Network Guru Member

    I'm a dolt. I change the subnet to my home network to 192.168.3.x and everything is fine.

    One of my desktops had Sentinel on it at one point and hangs at the "Verifying Network" portion of QuickVPN. I've read that it's a common problem when other VPN aps have been installed. I'll have to do a little searching to resolve that issue. (I see it mentioned in the last section of the QuickVPN Guide that Doc sent me.)

    But it connected great on my laptop.

    Thanks for all your help guys. It was greatly appreciated!

    To double verify, I shouldn't have to forward any ports on the client side running QuickVPN, right? It seemed to run just fine. I'm not interested in mail or anything. Just access to other machines.

    -- Craig
  6. DocLarge

    DocLarge Super Moderator Staff Member Member

    Nope, quickvpn establishes its own tunnel courtesy of ports 443 and 500 already being forwarded based upon factory configuration. You're all clear now...

  7. clambert11

    clambert11 Network Guru Member

    Excellent! Thanks again for all your help.

    -- Craig
  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