Can't Get IPSec VPN to work WRV54G

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by blankho, Mar 18, 2005.

  1. blankho

    blankho Network Guru Member

    This is a baffling problem.

    Has anyone created their own IPSec policy using Windows XP and got it to work with WRV54G firmware 2.37. I can connect the router to an FVS318 and create a router to router VPN no problems. I can also create a QuickVPN account and get it to connect okay. I cannot create a policy that works with the WRV54G to save my ass. I can create a policy with no problem to connect to the FVS318. The interesting thing is that both the router to router and router to QuickVPN are using IPSec policy.

    I even copied the FreeSwan IPSec policy created with QuickVPN on the machine that worked with QuickVPN and still could not get a tunnel policy on the router to work. I noticed one suspicious thing on the router that points to a bug. When you select ESP parameters on the tunnel page and then go to the advanced page, the encryption algorithm will be correct but the authentication algorithm will be one security level lower. For example, choose SHA and you get MD5. Choose MD5 and you get disabled.

    I even used a third party IPSec policy generator, which works fine with the FVS318, but it will not work with the WRV54G. I am convinced that there is either a bug or a problem with the hardware.

    You cannot rule out the router being bad just because QuickVPN works, because QuickVPN uses IPSec policy that it generates in conjuction with some additional password protection. The router QuickVPN feature defines the policy for you.

    Has anyone tried this?

  2. blankho

    blankho Network Guru Member

    Obviously nobody here has dealt with this issue, or at least they are not sharing. I managed through much persistance and through elevating the issue up the chain at Linksys to finally get an answer. According to Linksys Tech Support, the WRV54G firmware version 2.37 has a bug that prevents IPSec from working if the IPSec machine is behind a firewall. They claim it is not a NAT traversal problem, but I am pretty sure it is. So if you can get QuickVPN to work, and also can get IPSec policy to work, but only if the IPSec computer has a public IP address but you need it to work with a private IP address, you are screwed until Linksys releases a new version. However, they claim that the latest Beta software fixes the problem. Let's hope so.

  3. H2O_Goalie

    H2O_Goalie Network Guru Member

    Learn to use the search function...this issue has been noted and commented on in many threads.
  4. DocLarge

    DocLarge Super Moderator Staff Member Member

    Yo, Beale Street, ease up, brah. :) :) Although frustration gets the best of us, blank is just trying to get some answers (I'm from Milan, TN near Jackson).

    Blank, I haven't been able to use my WRV54G because of being on an ADSL line (I had to buy a WAG54G which works fine for VPN) but I'm looking at changing modems so I can get back up to date with WRV problems. Now, whereas I cannot give direct comment about the new "50 user license" with quickvpn, I can say that TVOS and I have finally got Greenbow Configuration down "cold" should you want to look at that as an alternative for the time being. Check out the attached screenshots:

    The big three things to keep in mind are these:

    1)Remote Gateway: In Phase I where you see "Remote Gateway," this is asking for your WAN address (the IP address provided to you by your ISP); also, it's best to leave "Interface" with the asterik as the designator.

    2) Pre-Shared Key: Make sure your pre-shared key uses a hexadecimal string beginning with 0x (i.e., 0x123456789) From my personal experience, HEX is a perferct marriage with the pre-shared key. This is where a majority of the "holdup" I experienced came from because no matter what I put in for the Key, the logs kept saying "Check Pre-Shared Key." When I changed it to HEX, it picked up immediately!

    3) VPN Client Address: If you are connecting from "behind" a router, make sure IPSEC pass-thru is enabled. Here you should be able to use your local LAN address because the actual connection registers as the NAT'd IP (your ISP provided WAN) when it exits the router on the other side. If you were to just connect through a "direct connection" (i.e., cable/adsl/dsl modem directly connected to your computer) you would input your WAN ip address in the vpn client address.

    Shoot me a note if you find this to be an acceptable solution for the meantime...

  5. H2O_Goalie

    H2O_Goalie Network Guru Member

    You're right Doc. Jeff, sorry for my snappy reply...but really, do use the search function, you'll often find commentary (note I did not say answers...sometimes there just aren't any, as in this case) regarding your exact problem.

    I've used firmwares 2.37.7 and 2.37.9 (.9 from the China site) and neither of them allowed me to successfully establish IPSec tunnels from behind a NAT using XP's embedded IPSec functionality. QuickVPN is not an acceptable workaround for me unfortunately.

    Luckily I have a BEFVP41 sitting around...that was my router prior to the I was able to put it back in place. It works just fine with the XP IPSec implementation and NAT.

    There's just nothing better than doling out $180 for a product that doesn't work...
  6. ne1r

    ne1r Network Guru Member

    I have QuickVPN working in numberous locations. One of the problems with VPN is the setting of the MTU. Try getting the MTU setting on your client network card to the poing of no defragging. Look for a program called TCPOptomizer. It is a big help.
  7. blankho

    blankho Network Guru Member

    Hey guys!
    You know I tried to find what I thought were relative discussions on this issue using the search tool. Perhaps I used a too refined search string "WRV54G IPSEC 2.37 NAT-T", but I was unable to find what I thought was a relavent thread. But, I will try harder next time, particularly if I am not overly frustrated.

    It is not surprising the hear that I may have been misled by Linksys that the latest firmware will supposedly fix the problem. What else is new? Thanks for the info on GreenBow, but here is some background on my situation that makes that and QuickVPN an unworkable solution. I was actually developing some code to create an IPSEC VPN manager, something similar to both QuickVPN and GreenBow, but with special features that are beyond the scope of this conversation. Let's just say that it could dynamically assign policy to allow my customers to more effortlessly switch between VPN sites without requiring a multi-tunneled router. Essentially I need to use Windows XP IPSec policy to connect these VPNS to fulfill the tasks.

    Here are the Facts as I know them (WRV54G with 2.37 firmware):

    1. The WRV54G router can create a VPN tunnel between itself and a Netgear FVS318 just fine (router to router).

    2. It can create a VPN using QuickVPN just fine, even if the VPN client is NAT'd behind a firewall (hybrid IPSEC to router), but you have far less tunnels available. I refer to this as a hybrid because it involve usernames and passwords as well as IPSEC policy.

    3. It will allow connections to an FVS318 using Windows IPSEC when the Windows PC is on the backside of the WRV54G (IPSEC passthrough).

    4. It will even allow tunnel creation to the WRV54G using Windows IPSEC policy, as long as the Windows PC has a public IP address.

    5. But as we all know, it will not allow Windows IPSEC to connect to the WRV54G if the Windows PC is remote and behind another router. This what I believe to be a NAT traversal issue.

    Linksys support insisted at first that 2.37 did support NAT-T and that it must be a setup problem. That is why I posted this very specific thread. I was not looking for people who could not get it to work, I was hoping to reel in someone who had gotten it to work. I may have sounded poorly when I suggested nobody was sharing info.

    Linksys has since held to the line that the router supports NAT-T but the firmware does not. They now claim that firmware 2.39?, or whatever the next beta version is called, will fix the problem. However they have not sent it to me as promised. If version 2.39 is the version that they are referring to, it sounds like you guys may have already proved them wrong. I feel that something is up though because they still have not sent me the beta copy and I have been put on hold. Perhaps beta 2.39+ is in the works.

    For now I have a work around, it is called a Netgear FVS318 router. My software works fine with that configuration.

    I will keep you posted on my results

    Thanks again

    Jeff (Indianapolis, IN USA)
  8. H2O_Goalie

    H2O_Goalie Network Guru Member an aside, the Linksys BEFVP41 works perfectly with the native XP implementation of IPSec. I actually bought the WRV as an upgrade from the VP41, imagine my surprise (and anger) when I found that I had to go backwards in order for the VPN tunnels to work properly.

    I can tell you from experience that 2.37.9 still doesn't solve the problem, so whatever new firmware they're promising needs to be a greater revision than that if we're to have any hope.
  9. chris547

    chris547 Network Guru Member

    Jeff, I've had exactly the same response from Linksys. At least when you got to Linksys they finally worked out what NAT-T was ! The outcome of my support incident was that they admitted that there wasn't NAT-T support on the WRV54G. They said they'd look into adding it in a future release, I'm just hoping they put it in a beta before the offical release.

    Not sure on point 2 though, that was one of the solutions that Linksys suggested for the NAT-T problem. Although there's reports that even it doesn't work behind a NAT. I'm trying to connect with a pocket pc, with a third party client and there isn't a version of QuickVPN for the pocket pc. I get a feeling that Linksys believe QuickVPN is the answer to everything.
  10. DocLarge

    DocLarge Super Moderator Staff Member Member


    I posted on the wrv54g yahoo group about the x-modem ce from adsl nation. This device takes care of the NAT-T/IPSEC problem Linksys can't seem to figure out. I've been posting to all of the places I go to just to put the word out that "one" alternate fix (until Linksys/CyberTan gets their sh!t right with the firmware) is the x-modem ce hardware solution ( TazUK got me shopping for an ADSL to ethernet "standalone" modem and this is what I came back with. Here's the post from another group below (slightly edited):

    Basically, this is a "true" standalone modem (no routing functions inside) that has a processor that converts the ADSL signal to ethernet (PPoE) thus allowing you to connect to your WAN port on your router (in this case WRV54G) and have all of your functionality over PPoA! The "Live IP" function ADSL Nation refers to is just likening the router to having a similar "direct" connection (based on the aforemention processor functionality) to the internet (such as a computer connecting through a cable modem or dial-up connection) and having the ISP provided single IP address available to all of your devices via the router! The best thing about it is when you connect using vpn, your WAN IP is what's actually displayed in the logs; the issue of NAT/NAT-T/IPSEC (per comment by the support tech) is gone!!


    Ironically, I've never had a problem with users behind a router connecting to either my Linksys WRV54G or Linksys WAG54G using linksys quickvpn or greenbow vpn.

    Still, if this product is as good as mentioned, it makes not having the firmware to do the job properly bearable.
  11. chris547

    chris547 Network Guru Member

    As posted on the other group, this doesn't take care of the NAT-T/IPSEC problem. If you have a setup like:

    Client -> NAT -> Internet -> Cable modem -> WRV54G

    it's this....^....this that's going to be causing the problems.

    The X-modem is a ADSL modem, it can't solve a software problem in the WRV54G.

  12. DocLarge

    DocLarge Super Moderator Staff Member Member

    It's not supposed to, my man (my bad if I ever so "slightly" got the context wrong in my eagerness to share). It's merely another experiment (and a worthwhile one I might add) in finding a solution for the issue. Incidentally, I just finished posting quickvpn connection success shots and corresponding wrv54g configuration shots on yahoo's wrv54g forum.

    *Shrug* Hey, connecting with quickvpn and hosting quickvpn connections from my wrv54g works for me. :) :) Pop over there and take a "gander" if you get a minute...

  13. Solutions

    Solutions Network Guru Member

    got a link to the forum? luck. would love 2 see the config screenies
  14. JohnBima

    JohnBima Network Guru Member

    I have been testing the WRV54G by myself and with Linksys Tech Support for over 50hours, and have tried every firmware version ever developed. All I can say is this product is the biggest piece of shitt I ever bought. Linksys has escalated all these matters I brought up to the development team, and I will await a reply... or not! I'll have to wait and see. This product should have never been released to the public without strick Quality Control. Now everybody is paying for it. I would hate to see Linksys toll charges for all the support calls on this.
  15. Solutions

    Solutions Network Guru Member

    I'm thinking about taking this issue up with the
    Better Business Bureau... Obviously Linksys didn't know what the hell they were doing when they designed the WRV54G's Box to say "VPN Router".

    Such a shame... I was so stoked when Cisco took over Linksys (I'm a Cisco employee) but now I feel ashamed to be invloved with a company that would sell this P.o.S. Did they even test the product before clearing it for production??

    I have worked on the VPN function off-and-on for a few months now. I have gotten the QuickVPN software to actually connect and give a green light ONCE. Unfortunately after being connected for about an hour the software disconnected and I haven't been able to get it going again. grrr, I am even using TWO WRV54G units (one at each site).

    LMFAO @ Linksh!ts
  16. DocLarge

    DocLarge Super Moderator Staff Member Member

    What's happening my fellow frustrated, pissed off, had enough of this shit, won't go to bed until I see it working wrv54g purchasing suckers!!!

    I've been helping some folks get their quickvpn connections up and running and I've come up with a 6 step starter checklist that seems to be doing some good, so I thought I'd put it over here and see if it helps anyone get a quickvpn tunnel going:

    1) Disable pptp and L2tp
    2) Disable all vpn port forwarding (500, 1701, 1723, 4500)
    3) Disable all vpn settings (tunnel, gateway, IKE)
    4) Make sure quickvpn is the "only" client loaded on your machine
    5) Enable Ipsec
    6) Check under services and make sure Ipsec is running

    These are just baseline settings to start out with, by the way. Once I finally started getting connections, I started varying the configurations to see when it "would" and "would not" connection based upon the changes I made. Also, you should subribe this user group ( for another informational meeting of the minds. One of the guys has come up with a way to use the quickvpn protocol inside of greenbow to allow you to connect "from behind a router" to the WRV54G. I haven't got this configuration to work as of yet, but he's posted the instructions on Yahoo.

    I'll try and post some shots later because I can't get in at the moment.

  17. chris547

    chris547 Network Guru Member

    Over at the WRV54G yahoo group I've been working on the connection behind NAT problem and I think I might have cracked it.

    First thing I've confirmed. there's absolutely no NAT-T support in the WRV54G, this is strange since the WAG54G does have NAT-T support. If you download both the WAG54G and WRV54G GPL code your see the obvious obmission on in the WRV54G.

    But what I've found is that you can get round the NAT-T problem if you use the same functions that Quickvpn does. All you need is the GNU wget command.

    I've seen this tried on this board before but previously it's been tried using Internet Browsers and unfortunately a Microsoft patch stops you requesting But you can request this file with wget !

    What you need to do is as follows:

    Issue the following command "wget https://<user>:<pass>@remotegateway/StartConnection.htm?version=1?IP=<localIP>?USER=<user>"

    user and pass are your user id and password stored on the vpn client page and localIP is the local IP address that your connecting from. Remember don't use the WAN IP address.

    This should automatically setup a tunnel on the WRV54G which you can get the settings from the file that's saved with the wget command. "StartConn ...."

    The extra settings you'll need are 3DES, MD5, DH1024

    When your finished with the tunnel issue the command:


    It's not perfect but I've managed to connect three times using this way.
    It does improve things slightly but I've still got devices that even wget won't run on, let along Quickvpn. If anybody knows anything similar to wget on the pocket pc I'd like to know.

    What we really need is NAT-T support, what I suguest is everybody who's needs NAT-T support log a issue here with Linksys and hopefully they should pull their finger out and do something about it. It doesn't take a whole firmware rewrite as some have sugguested, if it can be done on the WAG54G it shouldn't be a problem to do it on the WRV54G !
  18. DocLarge

    DocLarge Super Moderator Staff Member Member


    If you were offered a NAT-T fix for the wrv54g, what would you be willing to pay for it if a third party provider said they could make it? There's a reason I'm asking this question because I was told by some developer friends of mine if they thought there was a market for providing a fix, they'd make it. I've just spent damn near the entire afternoon convincing one of the guys there are plenty of interested parties.

    If I can show them there is an interest, a fix might be in the works...

  19. chris547

    chris547 Network Guru Member

    The problem is if you did provide a fix, 100 to 1 linksys would probably come out with the fix themselves. Looking at the code myself the fix doesn't seem that hard to do, comparing the WAG54G it just seems to be a case of applying the NAT-T patch and recompiling. The problem is the GPL code for the WRV54G isn't in such good shape and I've only just managed to setup the toolchain for it.

    If I do actually manage to get it up and compiled I post a fix for free :)

    One thing I would like to know is does anybody know how to brake a linksys release up into it's constituant parts. It's been done for the first release but I'm having problems breaking up 2.38.

    But I suguest anybody who needs NAT-T support raise a support issue with Linksys and hopefully with enough customer complaints they should do something about it !
  20. DocLarge

    DocLarge Super Moderator Staff Member Member


    I'm putting money on you to fix it first, that being the case (FREE is the operative word here...)

  21. chris547

    chris547 Network Guru Member

    Well I'm going to have a go, so far I've got freeswan from version 2.03 compiled. There's a problem with compiling the kernel in that it fails compiling ipsec_hwaccel.c with the error "storage size of `ips_errs isn't known` Hopefully if I can get past that and get a package that compiles completely I'm going to see if I can apply the NAT-T patch.

    The only thing is I'm sure Linksys or who ever wrote the firmware for them has version 2.08 setup ready to compile, otherwise they wouldn't beable to come out with all these beta versions. I'm sure it would be easiler for them to patch it than me to get to the same stage their at.

    If anybody who's having problems due to the lack of NAT-T register a support issue at Linksys Support and hopefully they might either get overloaded with complains or fed up and put the patch in themselves.
  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