RV016 v2.0.15 Beta Firmware + QuickVPN v1.0.47 Beta

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

  1. Toxic

    Toxic Administrator Staff Member

    RV016 Firmware v2.0.15 Release Note


    1. Enhanced the security of QuickVPN by supporting self-generated certificate on the router. Several functions (buttons) were added to the Certificate Management section on the VPN Client Access page. Administrator can generate new certificate, export certificate for admin backup, export certificate for QuickVPN clients, and import certificate for admin. The router's certificate needs to be delivered to all QuickVPN users and placed in the install directory of QuickVPN Client, e.g. C:\Program Files\Linksys\Linksys VPN Client\. This way the QuickVPN client will only trust these certificates placed in its local directory and will not be deceived by a hacker in the middle to connect to a hostile computer. With QuickVPN Client v1.0.47, when the client encounters a certificate that is not trusted, the client will pop up an warning message, suggesting the user quit the connection attempt. The export and import functions can be used when the admin wants to reset the router to factory default, but does not want to re-distribute the certificate to all of the QuickVPN users.


    1. Fixed the TCP Window Scaling issue with Vista.
    2. Fixed an issue with NetBIOS over a gateway-to-gateway tunnel.
    3. Fixed a known issue that the local DNS Server's IP address does not get passed to DHCP clients.
    4. Added a pop-up message to inform the user to change the NSD host to IP address if the host field was configured with domain name rather than IP address.
    5. Added the support for the new PeanutHull DDNS service. On the DDNS configuration page, the option, PeanutHull, was renamed as Oray.netPeanutHullDDNS. (Note: In China, the specification of PeanutHull DDNS service was changed on Oct. 1st, 2006. Old PeanutHull DDNS client will no longer work after Oct. 1st.)

    RV016 v2.0.15 Beta Fimware + QuickVPN v1.0.47 Beta
  2. Toxic

    Toxic Administrator Staff Member

    If you do find any bugs relating to this firmware or compatability with QuickVPN v1.0.47 please give indepth findings. this will help Linksys fix issues resulting in this new beta.
  3. adisor19

    adisor19 Network Guru Member

    Still no news on whether load balancing was improoved at all... I got rid of my RV016 due to its abyssimal load balancing performance and the continuous connection resets when Bitttorrent was involved. I used to average 2.5Mbit/s with the RV016 and now with the Xincom XG-502 i easilly go to 8Mbit/s and no connection resets. I'm still interested however if anyone can confirm whether the new firmware improoves loadbalancing and stability under BT.

  4. Toxic

    Toxic Administrator Staff Member

    If you look at the Changelog you will see there is no mention of Load Balancing fixes. obviously not enough complaints to Linksys Tech support got through.

    I wouldn't be if you fixed the issue with a new router:)
  5. adisor19

    adisor19 Network Guru Member

    I still am cause my new router only has place for 2 WAN connections and i have 3 for the moment..

  6. mlai

    mlai Network Guru Member

    Just loaded the firmware on my RV016 when I saw that it is supposed to fix the TCP Window scaling problem on Vista. (I am running Vista x64 RTM....)

    Everything seems to be working and I re-enabled the TCP Window scaling in Vista (btw, that is "netsh int tcp set global autotuninglevel=normal"). Guess what? All the sites work pretty well and I can even RDP to my office server which I wasn't able to before with TCP Window scaling enabled on Vista.

    Now, ready for the irony? The only site which I have intermittent trouble going to now is www.linksys.com......
  7. Pinchy

    Pinchy Network Guru Member

    Me too, but I found it's due to something in IE7 not liking their site. :)
  8. giffordj

    giffordj LI Guru Member

    I'm seeing something interesting with this new firmware. I have one to one NAT setup to bring people to my webserver. The issues is that sometimes it works sometimes it doesn't. If I go and enable forwarding under setup to forward to the server, everything works.

    Any ideas?
  9. luv2chill

    luv2chill Network Guru Member


    I am having an issue with the RV016 that's in a production environment (so I am not sure I should flash to beta firmware--I am running the latest official version 2.0.13). The problem I am having I have never seen addressed anywhere, so if it instead belongs in a new thread instead of this one, please let me know.

    Anyway, I am using the one-to-one NAT feature to give my Windows SBS 2003 server its own public IP, separate from the one that all other computers use. This works fine in conjunction with the UPNP, which the SBS 2003 setup wizard was automatically able to use to open the necessary ports for SMTP (25), VPN (1723), RDP (3389), FTP (21), HTTP (80), HTTPS (443), plus a couple of SBS-specific IIS ports (444 and 4125). I can see these UPNP port rules in the UPNP page of the RV016's setup screen.

    In terms of the Firewall->Access rules section of the RV016, the default rules are in place, that is:


    The problem? The public IP I assigned to the SBS server via one-to-one NAT is wide open. Unless I put in a specific rule to deny a service/port to that specific lan IP then all ports I have tried (including dangerous ones like NetBIOS) are wide open and accepting connections from the outside. Yikes!

    Has anyone else seen this behavior (or could try duplicating it). I cannot imagine that this would be by design. Why don't the firewall default rules seem to apply to the one-to-one NAT address I set up?

    It seems to me that no matter how many IPs you have going through the router, they should all obey the entire list of rules in the firewall. And since the default rules cover any source and any destination then the one-to-one IPs should be included in that.

    Yes, I can set up a specific deny rule for all traffic headed to that single IP, but that seems to override all of the UPnP port rules, so then all incoming traffic is blocked.

    Can anyone shed some light on this? It seems like a bug to me, but I guess it's possible that this is intended behavior when using one-to-one. Seems like a glaring deficiency which ought to be documented in the help in any case.

    Help is much appreciated.
  10. pablito

    pablito Network Guru Member

    You are correct but it isn't a bug. As with any One-One, port forward, DMZ, and UPnP rule there are hidden autogenerated Allow All rules added. If this didn't happen then the feature wouldn't work at all unless rules were manually added. I'd prefer the manual way but that isn't the case with any SOHO router. By default you would have to rely on the internal server's security.

    What you should do is to add your specific Allow/Port/Ip rules followed by Deny All rules.

    an example ruleset for One-One or UPnP might be:
    Allow Service[Port] WAN1 (source IPs or All/server IPs)
    Allow Service[Port2] WAN1 (source IPs or All/server IPs)
    Allow Service[Port2] WAN2 (source IPs or All/server IPs)
    Deny All WAN1 All All
    Deny All WAN2 All All
    [auto gen rule] Allow All WAN1 All
    [auto gen rule] Allow All WAN2 All
    Allow All Traffic [0] LAN
    Deny All Traffic [0] WAN1
    Deny All Traffic [0] WAN2
  11. luv2chill

    luv2chill Network Guru Member

    Thanks for the info pablito. It's good to know, but hope you don't mind if I vent a little (or a lot) here:

    1. I had a Sonicwall (not an enterprise one either--SOHO3 was actually its model number) that did not exhibit this behavior at all. The access rules listed applied to the one-to-one NAT as well as the router's public IP address, which is intuitive and makes sense. No hidden and/or default-allow rules were ever created when setting up one-to-one addressing. I guess that's one of the few things Sonicwall did right.

    2. The feature would work just fine without any autocreated rules. Just as you need to open ports to get incoming access in any router you purchase, why should one-to-one be any different? By setting up one-to-one you're not turning off NAT, you're just tying one private IP with one public one. You would then manually (or via UPnP) open up the specific ports you need for each IP using rules, with the knowledge that any other ports would be covered by the default-deny rule that exists on every gateway router in existence. One-to-one NAT should not automatically mean "I want this computer wide open by default". It has many uses... maybe you want to be able to run two different FTP services on port 21, maybe you want to isolate your workstation traffic from each of your servers, or maybe you do want a wide-open box, but the point is that they shouldn't assume that you want any of those things. If you're smart enough to be setting up one-to-one NAT you should know how to draft proper rules to open what you need (whether that be nothing, everything, or just port 21) without Linksys implementing the least secure option automatically.

    3. Even if I'm wrong about #2, why does this autocreated rule need to be hidden? That, to me is outrageous. SOHO or not, if this thing is giving me an access rules list, EVERYTHING it's doing should be on it. Otherwise they are giving end users a completely false sense of security (especially since this is marketed to businesses). Until I looked at my SBS server logs (seeing all the failed logins coming in from over the internet) I had no idea that all traffic was being allowed to my server. Had I been able to see a default allow rule in the access list I would have understood what was going on. But since Linksys chose to hide it then I was completely in the dark. Which leads me to...

    4. Why in the hell is this not documented better? Never mind the fact that no where does it say that one-to-one is incompatible with UPnP rules (which it is), but to not put this fact in red, bold print at the top of the manual/help screen is, to me, astoundingly negligent because it effectively disables the firewall for that IP address. That should be the very first thing they tell you when you go to turn that functionality on (or at the very least, go the help file to read about it). As of now there is only this ambiguously-worded paragraph in the help file (at the very bottom):

    Note: One-to-One NAT does change the way the firewall functions work. Access to machines on the LAN from the Internet will be allowed unless Network Access Rules are set.

    Well, I looked at my network access rules and saw that they were set. There was a default deny rule for incoming access to ANY IP on the LAN from ANY IP anywhere else. The UPnP rules were successfully created and I was getting traffic in on the ports I opened. I had no inkling from that paragraph that UPnP rules would not be in effect for a one-to-one mapping and that there was a hidden default-allow rule in effect.

    I hope you don't think I'm off base here. Doesn't this seem wrong to anyone else? For one, the way they've implemented this "feature" creates a gigantic security vulnerability, and two, they fail to even make adequate mention of it in their help file/documentation. I struggled with this for weeks before coming here and finally asking for help, because I (thought I) knew the way firewalls were supposed to work--and that is that they deny incoming traffic by default. It should take a specific intention to allow all traffic to a PC on the LAN side. Isn't that what we have DMZs for anyway?

    If anyone feels they can refute my reasoning here, by all means do so. I really don't see any excuse for this though.

    Bone-headed, just bone-headed.
  12. luv2chill

    luv2chill Network Guru Member

    Sorry to reply to my own post, but I feel this bit of info deserves its own post because it makes an already bewildering situation even more confusing (and now that I think back on it, is the reason why I never suspected this was happening). In the user manual for the RV016 (on the CD that came with the router and also freely downloadable on Linksys' web site right now) the paragraph says on page 29, PDF page 40 (bold mine):

    One-to-one NAT does not change how the firewall functions work. Access to LAN devices from the Internet will not be allowed unless the appropriate network access rules are established, the appropriate forwarding entries are enabled, or the appropraite authenticated user sessions are established.

    Nice going, Linksys. This is what I get for $400?
  13. pablito

    pablito Network Guru Member

    holy cow. I can't even read all of that and fail to see what you're trying to accomplish with it. We're not Linksys and can't do a damn thing about it. What I can do is to figure out how to make the device do what I want it to do. I understand how a firewall is supposed to work and is why I was able to figure out what this one does and how to make it do what I needed. problem solved.
  14. luv2chill

    luv2chill Network Guru Member

    pablito. Notice how I made very clear in my post that I was venting about the way Linksys implemented this, not asking you to to defend them. Actually my hope is that someone from Linksys (or someone with clout over there) might read that and give a second thought to their decision to implement something that is insecure by default on a business firewall product.

    I also thought I would point out errors in the manual and broken functionality because, you know, maybe someone else having this same problem will then know that they're not doing anything wrong--it's Linksys that did.

    What I didn't need was your snide attitude and your little thumbs down icon--not at all. Notice I thanked you for the info, but at this point I'm not looking for a crude workaround--I want Linksys to fix their damn product.

    And yes I did notify them directly as well.
  15. pablito

    pablito Network Guru Member

    If you want to vent at Linksys then make a separate post. Then I won't respond since I have zero influence. I think you're wasting your time but at least I won't be wasting mine. If you want to ask a question then I might respond if I have an answer. That's what I did originally.

    Call it snide if you wish but that's how I feel. Your gripes have been discussed before (myself included)and if anyone is listening they have heard.

    Bottom line, the so called workaround works just fine for me. I expect to have a complete set of firewall rules even if there are redundant hidden rules. Not ideal but it works as desired in the end. I also know that if the unit functioned as I would hope then there would be millions of clueless people asking why their plug and play rules don't function. That's life in the cheap lane.

    I'm tired of being so careful about what posts I should respond to or not. I've answered these same questions several times in the last week. But you're welcome none the less. I too want to see the RV fixed properly but in the meantime I need it to work and with my methods it does.
  16. luv2chill

    luv2chill Network Guru Member

    Not everything in my post has been discussed before. I know you felt it was too long for you to read, but had you done so you would have found the following revelations, both of which I've never seen discussed before (and I did search):

    1. The user manual for the one-to-one NAT feature on the RV016 is 100% wrong in describing the way the device functions. But my hunch is that it was supposed to operate the way the manual describes, but Linksys couldn't make that happen so they changed their tune instead and say it is working as intended.

    2. UPnP port forwards are completely incompatible with one-to-one NAT. I know because I tested them. When doing a port scan, the RV016 reports that the ports are open an accepting connections, but the packets go nowhere. UPnP only works with ports forwarded on the router's own public IP address. That isn't stated anywhere in the manual nor on this web site.
  17. DocLarge

    DocLarge Super Moderator Staff Member Member


    allow me to interject...

    I'm sending this link over to the developers to see if they can weigh in on this. There's a conference this week so they may be late getting back with a response...



    I did read through your entire post, luv2chill :). My take is that the RV016 has "implicit" rules similar to the CISCO IOS, such as the "implicit deny" statement that is at the end of every firewall rule. I'm hoping the developer I have in mind can shed some light on how the RV016 implements its firewall policies.
  18. kspare

    kspare Computer Guy Staff Member Member

    One way to get around this problem for now, would be to take the sbs server off of the dmz and simply forward the specific ports that you need coming in. I'm not sure I follow the logic in why you have it setup on a dmz anyway? All you should need opened on a sbs 2003 server is 25, 80 and 443. You shouldn't ever need 110 open for pop3 because of the fact that you can use outlook 2003 and do outlook over https. Also seeing that you have an rv you have no use for the sbs vpn server so you can use the rv. Ditch the dmz and port forward those 3 ports and you will be fine, barring some other reason why you want to have it on a dmz.
  19. pablito

    pablito Network Guru Member

    kspare, the reason for using One-One instead of port forwards is to have the forwards assigned to a unique public IP instead of the main WAN IP. One-One is the way to do that and if you have extra IPs then it is wise to use them this way.

    The problem comes with Linksys's decision to place an Allow All rule for each One-One IP and the associated internal IP. The Deny All rule has no effect since the packet has already been allowed. This no doubt is to avoid the endless support calls if people didn't add Allow rules. But it does leave the IPs wide open.

    However for me it isn't a problem because I would always place individual firewall rules for what I want to pass and follow those rules with a Deny All rule. This is how I discovered how it really works despite the manual. It happens that the "hidden" Allow All rule is placed after your manualy added rules if using One-One, DMZ, and UPnP but not for Port Forward. The manual isn't clear about this.

    The other issue is port forwarding. It too adds an Allow All rule for each port forward you add. That is usually ok unless you intended to only allow specific IPs access. The Allow All rule is at the top (hidden) and you can't override it. For that reason I won't use port forwarding.

    If you want some control over filtering then you should use UPnP rules (instead of port forwarding). I keep UPnP itself turned off and only use the rules. DMZ and One-One also allow you to use firewall rules since the hidden Allow All rule comes after your manual rules.

    The manual is out of date and can lead you the wrong way. But with testing and these forums it can work as required.

    If I could ask Linksys for a change it would be to never hide any of the rules and to allow me to modify them and re-arrange the order as I need them. I'm also for a "Pro" version of firmware that allows this but removes my ability to call support about using it.
  20. luv2chill

    luv2chill Network Guru Member

    Thanks for the additional replies and discussion folks. In doing more searching I managed to find a USENET post from two years ago discussing this very problem with the RV082. Thought it might help to post it here if the RV developers are going to be investigating:


    I agree with pablito that there should never be hidden rules created on a product that actually tries to show you the list of access rules. When I see that access list I expect that should contain all the rules the govern access through the firewall.

    I still disagree with pablito's logic that it is expected behavior to open up all ports automatically when creating a one-to-one relationship, but if you're going to do it, at the very least do not hide it from the end user. Make all rules appear in the list and allow their priority to be set.

    And the documentation (both user manual and http help files) need to describe in depth how this works. Even disregarding the error in the PDF manual, the complex relationships between Port Forwards, Port Triggering, UPnP, One-to-one NAT, DMZ, and the Firewall Access List are never described.

    My open port problem was easily solved by creating the extra DENY ALL rule and the ALLOW rules for each port I wanted to open. But the true problem is that I had no idea that I needed to do that. Since the default DENY ALL rule was in place, the user manual was in error, and the UPnP rules were successfully created I had no reason to suspect that my SBS server was wide open.

    Anyway, blah blah blah. I'll stop explaining, but I hope Linksys takes this under serious advisement. It should take an explicit action to open up all ports on an IP for a business class firewall (this may not be enterprise grade but it's not a home unit either). Anyone intelligent enough to set up one-to-one NAT should have the knowledge to open up ports on their own.

  21. kspare

    kspare Computer Guy Staff Member Member

    Could you take a screen shot of your rules so everyone can see exactly what you are talking about? Might help?
  22. dspete24

    dspete24 Guest

    Same Crap But Worse

    I have been reading everyone's post here and I have to say its not just the requirement of the deny rule needed for the port u want open as the router does not protect the device at all when 1-1 nat is enabled. In the rv042 firmware (Latest one - I think thats the number) the firewall with a simple 1-1 nat policy and the imlicit rules is wide open to the internet with NO protection what so ever - NONE. So, instead of making deny for the ports - you have to make another DENY all rule on top of the implicit rule - come on thats not by design otherwise the engineer is an absolute retard. In Cisco - you have 1 Rule - In Sonciwall you have 1 rule - etc. Linksys is special it needs 10 deny rules to be protected? What a Joke.

    So you all know - I am removing all my Linksys Routers due to this issue and going 100% Sonicwall. This issue caused several stores I know of to have open systems to the internet resulting in full access to the systems - from databases - to credit card information - and MS vulnerabilities. System got fully hacked because of this and now Visa is involved about to research Linksys and possibly fine them separately for a faulty product. This is not in any manuals nor stated nor warned about when setting up the 1 to 1 nat so its stated as a bug - Linksys is Liable. Good luck Linksys cause as you know Visa has more clout than Cisco and More Money and they are pissed about Credit Card fraud especialy when caused by faulty equipment. Pretty Sad but their loss....Go Sonicwall - So much more secure and less cumbersome - and Cybertrust audits prefer them. LuvDude - you were right on.....
  23. Toxic

    Toxic Administrator Staff Member



  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