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

RV082 v1.3.3.8 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

    RV082 Firmware v1.3.3.8 Release Note

    There are two firmware systems used by RV082. One is firmware v1.3.x which uses the newer Intel CSR1.2.2. The other is firmware v1.1.x which uses the original Intel CSR1.1. The look and feeling are quite similar, however, the v1.3.x firmware provides more features and better performance than v1.1.x. For example, the NAT firewall throughput has reached 200Mbps (bi-directional wire speed) and the IPSec throughput (3DES) has a maximum over 90Mbps. You can upgrade or downgrade the firmware on your RV082 device whenever you want. But be warned that downgrading firmware will restore the configuration to factory default. Users have to manually configure the router after firmware downgrade.
    ***Importing configuration file exported from firmware 1.3.x into firmware 1.1.x will damage the router.***

    ENHANCEMENTS:

    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.

    2. Added the support for Windows Workgroup (NetBIOS broadcast) over a QuickVPN (VPN Client Access) tunnel.

    3. The maximum number of Static IP entries on DHCP->Setup page was increased from 100 to 253.

    4. Added the support for the SNMP link-up/link-down traps on all of the WAN and LAN ports. In the previous firmware, the link-up/link-down traps were supported on WAN ports only. In a snmp-trap frame, the port number is indicated in the field "specified trap type" which was defined as the following.

    Specified Trap Type Specified Port
    1 LAN port 1
    2 LAN port 2
    3 LAN port 3
    4 LAN port 4
    5 LAN port 5
    6 LAN port 6
    7 LAN port 7
    8 LAN port 8
    129 (0x81) WAN port 1
    130 (0x82) WAN port 2 /DMZ


    ISSUES FIXED:

    1. Fixed the "TCP Window Scaling" issue with Windows Vista.

    2. The help page of the DHCP->Setup page has been updated to include the instructions to enable "MAC Filtering" using the DHCP->Static IP list.

    3. 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.)

    4. Fixed the issue that the local DNS Server's IP address does not get passed to DHCP clients.

    5. Added a pop-up message on the Dual-WAN page to inform the administrator to change the NSD host to IP address if the host field was configured with a domain name rather than an IP address.

    6. The description about maximum number of the protocol-binding entries on the help page was changed from 30 to 100.

    RV082 v1.3.3.8 Beta Firmware + 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. heidnerd

    heidnerd LI Guru Member

    I have downloaded and installed 1.3.3.8 beta.... And rebooted the router. It doesn't look like the snmp mib has been corrected yet. I use PRTG and I do not see the local ports... just the "lo" (loopback), ixp0, ixp1, ixp2, ipsec0 and ipsec1. More precisely if I use a GETIF type tool to walk the MIB subtrees for the interfaces. The RV082 only reports six interfaces (the ones I've listed above).

    ifNumber.0 = 6
    ifDescr.1 = lo
    ifDescr.3 = ixp0
    ifDescr.4 = ixp1
    ifDescr.5 = ixp2
    ifDescr.6 = ipsec0
    ifDescr.7 = ipsec1

    I have cables plugged in ports 3,5,6,8 and WAN1, WAN2....

    As I walk the trees, I see the appropriate OID strings for the six interfaces noted above. The information includes ifType, IfMTU, ifSpeed, IfPhyAddress, ifAdminStatus, ifOperStatus, ifInOctets, ifInUcastPkts, ifInDiscards, ifInErrors, ifOutOctets,ifOutDiscards, etc...

    In all cases the data for ipsec0 and ipsec1 is 0. (VPN not enabled when I dumped the mib).

    Perhaps I'm reading the MIB wrong... but I really think this is a case where it is not working as expected. I saw same with 1.3.3.6 and 1.3.3.7...:frown:
     
  4. heidnerd

    heidnerd LI Guru Member

    I've tried the Quickvpn agent and it works for me... documentation is sparse. And it took me two tries to get a keys I generated and exported from the RV082 to be accepted on the client. (I still don't know why). (Certification generation does work...yea).

    Also while checking out the problem I discovered that the openssl.exe that is included with the quickvpn zip is an already vulnerable version 0.9.8c! The fixed version is 0.9.8d was released in September.

    http://www.openssl.org/news/vulnerabilities.html

    I haven't had time to look at the rv082 source files to see if that is also a vulnerable version...

    I think I may have discovered a strange side effect from binding specific ports to specific WAN interfaces. Here is what I have... and what I think is happening with the QUICKVPN connection.

    WAN1 DSL -- also incoming port for QUICKVPN
    WAN2 Cable -- all outbound port 80 bound to WAN2

    When I quickvpn to the router... I can see the router itself by referencing the router address and using the web interface -- all this over the quickvpn connection from a remote host.

    However if I try connecting to any other device that serves up port 80 inside RV082 firewall (via vpn)... it fails -- times out.

    I have tried connecting to ftp, https, mail servers, etc.. inside the vpn (RV082 firewall). Only the ports bound to WAN2 failed...

    I think failed login attempts to a RVxxx router using the quickvpn client should result in an entry being recorded in the incoming or system log file on the router. Even when I deliberately failed I did not see any error messages being recorded. Logging the errors would allow network adminstrators ensure that valid creditials are truly being used.

    Twice will trying to get the correct RV082 certificate loaded on the client side... I told the quickvpn agent to continue connecting even though the creditials didn't match the server. That should have also resulted in an entry on the vpn server being logged!!!

    AND finally... why is wget.exe included with the quickvpn agent? If exe's are needed don't distribute them - because that is just another possible vector for a hacker attack. I am some what concerned because if quickvpn client is compromised.... the wonderful wget utility is all set and ready to download content from any nasty website it is instructed to visit.
     
  5. heidnerd

    heidnerd LI Guru Member

    Ugh, wget apparently is needed. Renaming it breaks quickvpn... and the version of wget.exe that is distributed with this beta is also a vulnerable copy of software:

    http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6719

    No fix currently available for wget :frown: and exploit code has been published.
     
  6. Gitsum

    Gitsum LI Guru Member

    I'm still having issues with DNS on the client computers using a dual wan setup.
    All of a sudden, you just can't get web pages anymore. I have finally just set up one DNS server address from each of my two internet providers in the computers TCP/IP settings to get it to work.
     
  7. BigHusky

    BigHusky LI Guru Member

    Since upgrading to the new version if we use the load balancing feature the download speeds are about 30% slower and the upload speeds about 75% slower.
    We have a T1 on WAN1 and a 10Mb Cable connection on WAN2.
    We bind all http traffic to WAN2 and all ssh traffic to WAN1.
    Running the speed tests from broadband reports we get the following results:

    Within the RV082 with load balancing on http traffic going through the comcast line: Download 7200K - Upload 240K

    Within the RV082 with load balancing off: Download 1356K - Upload 1342K

    Outside the RV082 on T1 similar numbers as just above

    Outside the RV082 on Cable: Download 10234K - Upload 982K

    Even reverted to factory default and the results remain the same.

    Once most people have gone home I will retest this with the previous firmware 1.3.3.5 but I remember that with load balancing on upload speed was definitely not this crippled.

    BH

    Addendum:

    So I just downgraded to 1.3.3.5 and the same first test as above results in these numbers:

    Within the RV082 with load balancing on http traffic going through the comcast line: Download 13804K - Upload 906K

    So I hope this speed crippling won't be a permanent item with 1.3.3.8beta and forward.
     
  8. WmArnold1

    WmArnold1 LI Guru Member

    BUG: RV082 v1.3.3.8 ==> still logging SYN-FLOOD's

    Hello everyone! - v1.3.3.8 resolves everything for me, except my main issue [sigh]

    Background: I'm enjoying P2P software that incorporates a Distributed-Hash-Table (DHT) ==> The problem; DHT is done via UDP, and, lots of UDP packets are delayed or blocked by the RV082 as a SYN-FLOOD denial-of-service attack - a typical message from my RV082 is:

    ratelimit: 20 messages of type block-synflood reported 1 second(s) ago

    My Firewall-option-page settings are:

    Firewall - enabled
    SPI - disabled
    DOS - disabled <=== !!!
    Block WAN request - disabled
    Remote Mgmt - disabled
    HTTPS - enabled
    Multicast pass-through - disabled
    MTU - Manual - 1500

    (no Web features are restricted)

    Especially note that the RV082 DOS (denial-of-service) feature is supposed to be disabled above - and, it clearly isn't!

    Anyone can easily reproduce my issue by installing http://www.BitComet.com - version 0.81 now - No file transfers are required; the Dynamic-Hash-Table network will bring UDP messages that are blocked as a SYN_FLOOD attack most of the time.

    Btw; you may have to manually forward a port for bitComet to work properly - their UPnP feature is still not working.

    Can anyone reproduce my SYN_FLOOD issue?

    William Arnold ~ Indianapolis, IN
     
  9. heidnerd

    heidnerd LI Guru Member

    FYI --- bitcomet often has elements detected as spyware... just a reminder...

    "Despite the official BitComet website claiming BitComet is, "Clean and free, without any adware or spyware," [1] the current stable release, version 0.70, shows a single advertisement when using the video preview functionality. [2]Although the advertisement is removable, BitComet is still considered adware since the ad is automatically displayed without the consent of the user." From wikipedia http://en.wikipedia.org/wiki/BitComet

    Explanation of DHT -- http://en.wikipedia.org/wiki/Distributed_hash_table

    In earlier (many releases ago?) of bitcomet - they had problems with their implementation of DHT. Is it possible that they have re-introduced a problem also? Have you tried another downloader?

    If in the end you have to disable DoS, SPI and other features of the RV082 in order to use Bitcoment or another DHT downloader -- that perhaps you may be giving up as much as you gain...

    Had you tried adding a firewall rule to allow the inbound bitcomet udp traffic? Perhaps that would fix the problem? Just a suggestion....
     
  10. pablito

    pablito Network Guru Member

    I have this beta on one RV8 and using the stable version on another one. My trouble is a Net-Net VPN using NAT-T, the beta RV is behind a main router. Strangely I can easily create a VPN to an Astaro firewall but not to the other RV8. I get Phase one but not phase two. I've tried aggressive mode (that worked previously) but that no longer works.

    The VPN to the Astaro (linux based pc firewall) works no matter if I'm running single or dual NAT but I can't get VPN to come up against another RV.

    It appears that NAT-T is working since the Astaro sees the NAT and accepts the connection. The RV I'm trying to connect to reports the NAT'd IP but won't setup phase two. I might try applying the beta release to the other RV (production) but that isn't the most desirable option right now.

    I'm not seeing any useful error messages.
    [update]: I'm not sure if this message tells a story but I get different values for the cookies. After a establishing phase one I get this:
    "[Tunnel Negotiation Info] Responder Cookies = xxxxx"
    "[Tunnel Negotiation Info] Initiator Cookies = yyyy"
     
  11. pablito

    pablito Network Guru Member

    another update.
    I was able to get NAT-T to work RV-RV.
    I added a firewall rule to allow UDP port 4500 on the WAN port. it is already in the service list and is called "Cisco_VPN". The VPN came right up after I did that.
     
  12. WmArnold1

    WmArnold1 LI Guru Member

    Thanks for writing, Heidnerd! :)

    Inbound DHT gets through most of the time - Version 1.3.3.X is just delaying and/or blocking excessive UDP packets while exclaiming SYN_FLOOD.

    BitComet works just fine no matter how I set DoS and SPI. I just think it's funny that my Syn_Flood issue continues even when DoS is disabled..

    Note that version 1.1.6.11 had no trouble re: BitComet nor Syn_Flood

    That's how my posts got started; issues I didn't have before - Here; the only device complaining is the RV082 itself.

    I only hope someone at Linksys will duplicate my Syn_Flood issue and say whether it's the new firmware's fault or not.

    Warmest Regards, William ~ Indianapolis, IN ~ USA
     
  13. d__l

    d__l Network Guru Member

    Simple browsing triggers the block-synflood messages in 1.3.3.X firmwares so you don't have to run BitComet to seee them in your logs! I doubt that browsing is invoking a REAL synflood attack. Disabling SPI or DoS does not stop these bogus messages.

    I believe that these synflood messages may be related to the failure of the Line Quality Test at DSLReports: http://www.dslreports.com/linequality. The test reports nearly total packet loss from a ping streams of 40 byte and 512 byte packets and there is no way to enable these tests to properly work.

    Apparently the RV082 refuses to continue responding to the ping stream after a brief interval so the test reports consistent packet loss of 90-99% on various aspects of the test procedure. The same packet loss percentages are reproduceable in test after test indicating that the RV082 is stopping its ping response at the same point in the test.

    While the LQ test is in progress, the logs report numerous synflood messages.
     
  14. WmArnold1

    WmArnold1 LI Guru Member

    Thanks for publishing that alternative, D__L :)

    I'm truly relieved that something besides bitComet & DHT envokes Syn_Flood reports from the RV082 - Hopefully, Linksys/Cisco will address it now..

    Best Wishes for you and yours' ~ William ~ Indianapolis, IN ~ USA
     
  15. Jbob

    Jbob Network Guru Member

    And to add to what d_l mentioned the LQT issue only occurs with the 1.3.x firmware. If I install the earlier 1.1.6.14 firmware the LQT does not display this behavior and displays normal results.
     
  16. DDogg

    DDogg LI Guru Member

    Hi, I have a replicable problem using QuickVPN. When a gateway to gateway tunnel is enabled (not connected), even if it has no corresponding endpoint, QuickVPN will not connect. I have replicated this several times. As soon as I dis-enable the tunnel, QuickVPN connects properly. When I go back and enable it, I or my other users cannot connect via QuickVPN.

    Don't know if this is specific to RV082 v1.3.3.8 Beta Firmware + QuickVPN v1.0.47 Beta combo. But, I am sure it is a problem that needs looking into.

    Happy to provide additional info if needed for others to replicate.
     
  17. pablito

    pablito Network Guru Member

    ^^may or may not be related but I have a client-net VPN problem. I have net-net VPNs running between two RV8s and the RV8 and a standard linux based firewall. That works fine.

    But I can't get a QVPN or PPTP VPN to route past the RV8 to the internal network. For PPTP I get connected and can see the far end RV8, and can load the RV interface using the internal IP. But I can't see anything past (the machines on the internal network). However, I can create a static route to a network that is on one of the IPSEC nets over my PPTP tunnel.

    I can connect via QVPN but can't see anything on the internal network.

    I'm not concerned with name based browsing or other Windoze nonsense. Just trying to connect via IP. A PPTP from the same machine connects to my pc based firewall no problem.
     
  18. heidnerd

    heidnerd LI Guru Member

    Additional change request for firmware.... since many of us are seeing performance problemw when using Dual-WAN, perhaps setting the MTU by interface should be made available through the web interface in the next go round of the firmware. Currently you have to enable telnet and then change settings with ifconfig.

    I am also wondering if selective acks didn't get disabled in this version...
     
  19. pablito

    pablito Network Guru Member

    ^^Indeed that would be beneficial. I set my MTU to what the DSL needs and for a few months now the cable modem is still happy and reaches the maximum speed (10Mbs). Did this get worse with the beta? My dual WAN RV is still on 1.3.5

    VPN... Is anyone running a PPTP server along with IPSEC? I have no problem with a net-net VPN but I can't get a PPTP tunnel to work. I get connected and get an IP. I can see the remote RV but I can't see anything else on the inside network. I can even see a remote LAN over one of the IPSEC VPNs, I just can't see the network behind the RV.

    The RV I'm trying this on is on 1.3.5 and I hesitate upgrading to the beta since this RV is production. My other RV isn't in a state that can test PPTP (IPSEC works fine).

    RV082, 1.3.5
    Dual WAN set to Load Balance mode. <<might this be an issue?
    Inside users set protocol bind to WAN1
     
  20. whiny

    whiny Network Guru Member

    ^^ Count my vote for that!
     
  21. pablito

    pablito Network Guru Member

    I updated my RV to the new 1.3.4.
    I don't see any mention of protocol binding changes but have noticed some differences. I use the router in load balance mode but use bindings to force users over WAN1, SMTP over WAN2, and the VOiP adapters over WAN2. This allows me to use both ports but avoids the flip flop issues of normal load balance mode.
    This has worked fine for several months. But now the SMTP started going over WAN1 which would then fail (cable modem) and the VOiPs would malfunction.

    I had originally set SMTP with a 0-0 IP range assuming that meant all IPs but that doesn't work now. I changed it to be IPs 1-254 and that fixed the problem.

    I have a binding for IPs 1-254 to go over WAN1 and another binding for 10-16 over WAN2. It now appears that the 1-254 binding is overriding the 10-16 rule.

    Rearranging the rules has me back in business. So just an FYI if you notice odd behaviour.

    Another thing I noticed is that Auto MTU is working better now. I had previously set MTU to 1492 so that the DSL functioned well even though the cable modem likes 1500. I was dropping upstream packets today until I went back to Auto MTU. So far so good.
     
  22. frangus

    frangus Network Guru Member

    I recently updated to 1.3.4 from 1.3.3.8 beta and everything seems to be the same between the two versions. The only difference is a slight drop in upload speeds in the new 1.3.4. My 1 mbit/s upload rate which usually registers around 970-980 kbits dropped to 800 kbits. MTU settings are the same on both versions, both routers have been reset to default configurations and then configuration files imported.

    Today, I went back to 1.3.3.8 beta and the upload speeds are back to normal.

    Download speeds are not affected at all.
     

Share This Page