• The integrated system bootloader of the 500 router now uses error correction for its flash memory. In the past, we have seen RMA-ed 500 routers that had recoverable errors on the bootloader. Such a router would on power-on only have the power led going on, with nothing else happening besides that. With this improvement, these total failures will be a matter of the past.
• The Routers/Hubs will now keep state of all connections including NAT state if a tunnel disconnects. If the tunnel reconnects within 3 minutes, all state is restored. In previous firmware releases, a full tunnel disconnect (all channels disconnected) would often cause connections going through the tunnel to hang after tunnel reconnect; now it no longer does so if the tunnel comes back within 3 minutes. That's a huge improvement especially in moving vehicles that enter a "dead zone" with no mobile network reception at all. We were now able to do test drives for hours through forests etc. without ever having our connections going through the tunnel getting reset.
• The BondingTCPOptimizer mode has been improved a lot. Before, it had compatibility issues, especially if a connection went through multiple BondingTCPOptimizer tunnels (site-to-site VPNs). Also, the performance of this mode has been improved a lot. We now recommend to use BondingTCPOptimizer for any TCP traffic when bonding links with very high latencies, even for site-to-site VPNs, as it will improve achievable throughput a lot.
• Performance for the 500 router has been optimized a lot. In most situations, the maximum amount of bonded throughput is increased by over 30%.
• VLAN IDs may now be configured for additional LAN routes.
• LAN Aliases if a VLAN ID is assigned now may optionally have a default GW. If this is configured, then for traffic coming from the respective tunnel, segmentation ID will go to that default gateway, while the LAN interface (VLAN 0) will no longer be used (and that tunnel will no longer be reachable from VLAN 0).
• The two new features above together allow ISPs/BSPs to have a dedicated VLAN on the Hub per customer, a feature requested by multiple service providers.
• Webconfig system now logs user logins/logouts/errors.
• A new set of QoS rules and classes has been created. Web surfing by default still used Bonding, for high-latency bondings this should be changed to BondingTCPOptimizer. RTMP stream always uses BondingTCPOptimizer by default. The rules for RTP/VoIP have been changed to match on ToS and therefore generate less false positives, and to also support video conferencing. The VoIP QoS class now uses Lossy Bonding if a license for that is available. To use the new rules, you need to go to "QoS rules and classes templates" and execute "Restore Manufacturing Defaults", then go to each tunnel and select "Copy QoS templates to here". You need to do this on both, the Hub and the Router!
• There have been several buffer tunings going on. In many setups, throughput will improve, especially for connections using the "Bonding" mode. Also, performance for high-latency links and links with a high bandwidth-delay product (Satellite) has been improved.
• Configuring ethernet auto-negotation settings is now supported for Fast & GigabitEthernet modules.
• For high latency links (GPRS, Satellite), the passive and hybrid autotuning modes will now increase speed much slower so that the link is not overloaded without noticing it late.
• The Router may now be reached from the LAN using the hostname "viprinet.router".
• The "Resource Reservation Protocol" (RSVP) can now be routed through Viprinet Routers.
• Min and Max commands inside CLI now work.
• CLI is now displaying nicer datatype names on LIST.
• LTE module signal info inside the monitoring tool is now updated more constantly.

• Crash bugs in CLI have been fixed in regards of disconnects while still having a response in the pipeline.
• Tab completion in CLI now works for VALUES, MIN, MAX commands.
• Changing the WAN IP address on the VPN Hub with the Hub redundancy system enabled could cause the web interface to hang afterwards.
• Hubs in Hotspare mode would display Hub features always as unlicensed. Now it gives a hint that licenses are not checked in Hotspare mode.
• The 500 router would neither correctly output link information for the LAN port nor would it allow Ethernet parameters to be configured. Both now work.
• Early retransmissions started by the "Retransmission multiplier" setting would cause channels to never go to stalled mode. This could cause these channels to continue being used. This bug was especially affecting performance in moving vehicles.
• The 5 Ghz channel selection mechanism for the 500 WLAN AP was broken, only the first channel could be correctly selected.
• In the previous stable firmware, the Hub redundancy system did not listen on the WAN interface. This could cause a split brain situation in Hub redundancy setups where the original Hub was fine, and only the LAN interface link was down. Now, the redundancy system uses both the LAN and WAN interfaces again.
• If a value for 'Reset after minutes of downtime' for a module was configured, this was executed in this interval even when the module was disabled.
• Configuring enumerations/references (QoS rules targets, WAN modules inside channels etc.) inside the CLI now works correctly.

• The new LossyBonding mode which became available in recent firmware releases to users of the Streaming Optimizations license has been faulty in all prior firmware releases. In many cases with the LossyBonding mode the receiving side of IP packets would see reordered packets, which caused a lot of performance troubles for many applications. LossyBonding with the release now brings the expected performance, and is recommended to be used whenever low-latency UDP traffic needs to be sent over instable bonded links (like UMTS/3G). It is especially recommended for live video streaming and conferencing.
• Fixed: Under certain (rare) circumstances a power loss of the router while it was in progress of saving the configuration could cause corruption on the internal flash memory module. After a router reboot the router then would report a serial of "XX-XXXXX-XXXXX" and no longer function correctly.
• On the Multichannel VPN Router 500 it was possible that suddenly all WAN modules "disappeared" and no longer had been usable. This problem could not be fixed with a router reboot, instead a full power cycle of the router was needed to get the WAN modules displayed again.
• The NAT engine had several problems with some ICMP protocols. This could traceroutes from NATted IPs not to always work properly.
• The IP broadcase detection has been improved. If in previous firmware releases a router was connected to a LAN where an IP network existed that wasn't also configured on the router, broadcasts from these IP networks were picked up by the router and forwarded to the VPN Tunnel. This unintended behaviour also causes "PacketHeap" error messages inside the router's log.
• Previous firmware releases for the Multichannel VPN Router 500 contained a memory leak error. This error could cause the router to automatically reboot after several days of operation.
• The BondingTCPOptimizer bonding mode contained a bug which under rare circumstances (for 0.25^12% of all packets) would cause the router to crash and reboot.
• For the Hub redundancy system removing a test IP address did not cause the Hub router to actually stop pinging this IP, instead it continued to ping it until the next restart.
• Traffic accounting features did not work properly on Multichannel VPN Router 500
• On the Multichannel VPN Hub 5000 incoming VPN tunnel channel connections did not work correctly anymore once over about 200 channels had been connected.
• Several bug fixes for SNMP, mostly for users of the extended SNMP license
• If multiple WAN modules received a power reset at exactly the same moment (for example due to automatic timed reset being configured), sometimes not all of these modules would come back but instead got stuck powered off. Those modules were unavailable until the next router reboot.

• The time zone to be used by the router may now be configured under "Logging & Maintenance"
• The internal configuration system received a 20x speed boots. Especially with Hub setups containing a very high number of VPN tunnel channels changing a setting inside the webinterface in the past caused delays of multiple seconds. Even in this situations the configuration system now will respond promptly.
• The Hybrid autotuning mode has been improved a lot and has received several bug fixes. Using the hybrid autotuning mode is highly recommended for any 3G/4G based channels, as it combines good tuning results with only very low test traffic overhead. The passive autotuning mode also has received similar improvements.
• The ARP implementation now also uses IP packets coming in from the LAn to update the ARP cache. For devices on the LAN who haven't sent anything for a long time, this means that the first packet they send will already make them reachable on the LAN again, without a further ARP request. This brings an improvement for embedded devices with crippled TCP/IP stacks.

• With the previous stable release, all SNMP counters may stop counting every 50 days. The next time SNMP counters will stop is expected to happen on June 20th 2012. If you are affected by this problem, you should update as soon as possible.
• Hubs 5000 were reporting a CPU temperature of 0°C through SNMP. This is fixed.
• In the previous stable firmware, the experimental SSH CLI running on port 22 by default was turned on. Now the factory default is for this service to be turned off and for port 22 to be closed.
• In the previous stable firmware release, congestion detection had been added that would reduce the MaxBandwidthToWAN whenever congestion on the link due to packet loss got detected. This quick reducing the available bandwidth improved the latency of the channel. However, as we learned, for many installations, it also caused far more auto-tuning tests to happen, resulting in a strong increase in generated test traffic. This especially was the case if congestion happened while a speed test was running. This has now been optimized; the amount of test traffic should be back to normal. If traffic is costing you money, you should update soon.
• The driver for our new Gigabit Ethernet modules had several issues. If you used static IP configuration with the Gigabit Ethernet modules, problems with link detection occurred. This release improves the stability of the Gigabit Ethernet modules a lot.
• In all previous firmware releases, the “Passive” and “Hybrid” auto-tuning mode had a bug which could cause the speed auto-tuning to stall when it was started at very low speeds (200 kbit/s and below). In this case, the speed would be stuck therefore and never increasing again. This especially could be seen in moving vehicles with bonded UMTS, due to frequent cell changes including GPRS/EDGE cells. This bug is now fixed, and “Passive” and “Hybrid” auto-tuning modes perform as intended in these situations. If you are using the “Passive” or “Hybrid” auto-tuning modes, you should update soon.

We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

• Fixed: Recently, a third-party vendor has released products with a broken TCP/IP stack, which is sometimes sending broken TCP packets. Sadly, our BondingTCPOptimizer was sent into an endless loop if such a packet was transferred through a Viprinet router. This would basically make the router go out of service. If you are using BondingTCPOptimizer, this is a critical issue. The problem has been solved, and the BondingTCPOptimizer is now unsusceptible against all known kinds of TCP exploits.
• Fixed: The new channel autotuning modes "Hybrid" and "Passive" still did do autotuning even if bandwidth autotuning was turned off for a channel.
• Fixed: Under rare circumstances (particularly with the VPN Client), bandwidth autotuning could result in a negative bandwidth value.
• Fixed: There was a very high load of ARP packets on the LAN interface. For many setups, far more ARP packets were sent than needed.
• Improvement: The performance and latency of channels that are under 100% load have been improved, especially for slow channels with <500 KBit/s bandwidth.
• Improvement: The monitoring API has been updated to v3. If you use the current monitoring tool from our website, in addition to channel information you will now see summary information for the tunnel. The previous monitoring API version v2 is still supported, old tools will continue to work as before.
• Improvement: Summary information for bandwidth is now part of the tunnel's object inside the web configuration system.
• Fixed: The web interface would sometimes log an "Internal Error".

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

• Improvement: Performance Improvements for high-bandwidth setups. For Nodes and Hubs under high bandwidth load (>50 MBit/s) minimal packet loss could occur on the LAN board due to an Ethernet NIC issue. This could limit the achievable throughput especially for high-latency transfers through the VPN Tunnel. Packet loss will no longer occur in these situations.
• Improvement: In past releases, the test data traffic generated by the bandwidth autotuning would limit the achievable throughput of real data traffic while a channel was under test. Every time a channel was doing speed tests, the total throughput that could be achieved through the bonded Tunnel would go down. This was especially an issue for situations where very unstable WAN links were bonded that needed re-testings often. Often in these cases, a bundle of 2x ADSL and 1x 3G/UMTS would give a lower real throughput than 2x ADSL alone, due to the unstable 3G link causing test data traffic very often. This has been completely changed: Now autotuning test traffic never will eat away real data traffic bandwidth, real traffic always will have a higher priority. Especially for setups where some or all bonded WAN links are unstable, the achievable constant throughput now will be much more stable than ever before.
• New feature: In the past, when a channel was going down, depending on the "Maximum allowed Latency" settings of the channel data traffic using this channel could stall for 100-1500ms. This was because that internal re-transmissions were only triggered the moment a channel switched to "ConnectedStalled" status. In addition to that, these internal retransmissions now can also be triggered long before a channel stalls. The default now is that if a channel latency goes over 4 times the optimal latency, such a "speculative retransmit" is internally issued. The default multiplier should be fine, can however be adapted inside the "Performance finetuning" settings of the channel object.
• New feature: For all channels and tunnels there are now internal statistics about the stability. The number of times a channel went down recently is taken into account, as is the number of times a channel stalled, as is the number of times and amount of packet loss seen. The stability value is displayed inside the Monitoring tool and inside the web interface.
• New feature: The BondingDiversity bonding mode has been improved a lot. With older firmware versions, no matter how stable or unstable the channels were, redundant diversity copies were always sent as long as unused bandwidth was available. This caused a lot of traffic overhead, which especially was a problem whereever traffic is expensive (UMTS). The new BondingDiversity mode now offers a "Minimum diversity" and a "Maximum Diversity" setting, which allows you to configure the min/max number of copies of packets that should be sent. The actual number of copies now is automatically tuned between those min/max settings depending on the overall stability of the tunnel. If channels are unstable (for example because you are inside a moving vehicle, with frequent 3G cell changes), more copies of the packets will be sent, if the channels are stable, less copies will be sent. We highly recommend using the BondingDiversity mode for all applications where stable/low latency bandwidth (Streams, VoIP, Cloud Computing) should be done over highly unstable WAN links. Usage of this feature requires a valid "Streaming Optimizations" license for each router where it is going to be used.
• Feature removed: The "Bestchannel" bonding mode has been removed, as it always has been a far worse choice than for example the default "Bonding" mode. The "LatencyPriority" setting also has been removed, because it only was used for the "Bestchannel" bonding mode
• Feature removed: The "Minimize AutotuningTraffic" option has been removed. If traffic cost due to autotuning traffic is an issue, please switch either to "Hybrid" (recommended) or "Passive" (if you do not want to waste a single byte) autotuning methods, they work much better.
• Improvement: The documentation of the Channel Finetuning settings inside the web interface has been improved, it should be now much clearer which parameters are dangerous to change.
• Improvement: Hubs using our Hub redundancy system now start up much faster. There also have been lots of bug fixes in this area.
• New feature: Inside the tunnel object, there are now statistics about the current total up- and downstream bandwidths available for the tunnel. There also is a set of statistics on how much bandwidth of that is regarded stable (currently available bandwidth from channel which are regarded as unstable is not counted in). We will be offering an API to use these values for streaming codec manufacturers soon. Contact our support team if you are interested.
• Fixed: After a power-cycle, ADSL modules sometimes would not be correctly detected. Instead an empty slot was shown. This issue has been fixed.
• Fixed: The traceroute tool inside the web interface didn't correctly work for the LAN interface.
• Fixed: A very rare bug that in theory could result in router reboots has been fixed.
• Fixed: The combination of doing a port forward at a VPN Hub pointing to a host behind a VPN Node could lead to issues in regards of reachabilty if multiple LAN aliases or VLANs were used at the Node. The router was issuing incorrect "ICMP redirect" messages.
• Fixed: The LAN-Interface ARP implementation was having a lot of issues. If an IP inside the LAN was transferred from one PC to another (MAC address change), this could result in unreachability of this IP from the Node. All reported problems in regards of ARP have been fixed.
• Fixed: Static DHCP entries didn't work if more than one entry was created.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

• Fixed: Both the December 2nd and the December 29th release contained a serious memory leak issue. For routers under high load (several thousand concurrent traffic flows going through a VPN Tunnel) this could cause the router to misbehave and/or reboot after a couple of days/weeks. This issue is now fixed.
• Fixed: The December 29th release puts out the full VPN Tunnel setup dialogue between a VPN Hub and VPN Node / VPN Client to the log file. For connections between a VPN Hub with a firmware release older than December 2010 and for connections from VPN Clients this means that the VPN Tunnel password is written in clear text into the Log file. This is a security issue. The problem has been fixed, the dialogue no longer is logged.
• Fixed: VPN Hubs did send back multiple ICMP replies when pinged at the LAN interface (not visible with Windows ping tool).
• New feature: It is now possible to configure static DHCP leases at VPN Nodes.
• New feature: It is now possible to view the current DHCP lease table at VPN Nodes.
• New feature: The DHCP lease time is now configurable.
• Fixed: The VPN Hub redundancy system had a number of problems and bugs. The redundancy system is now far more stable than before even in critical situations.
• Fixed: A VPN Hub in "Hotspare" mode was unable to use DNS (and therefore also unable to do online firmware updates).
• Fixed: All file upload dialogs (QoS config restore, config restore, firmware upload) allowed files of unlimited size to be uploaded, causing the router to reboot in worst-case. There now exists a file size limit.
• Improvement: The SSL error messages are now easier to understand than before.
• Fixed: The download test tool had various issues, especially with HTTP servers using Chunked Encoding. This is fixed. The download test tool will now automatically abort if the test download is causing a CPU load so high that VPN tunnel performance would be affected.
• Fixed: The new autotuning methods "Hybrid" and "Heuristic" could result in Up-/Downstream values of 0/0 KBit or cause an Internal error after being run for a few days.
• Fixed: It was possible to restore configuration files to router types which are not compatible with the source router. Routers that are treated compatible to each other for configuration restore are now Multichannel VPN Hub 1000/2000/5000 and Multichannel VPN Router 1600/1610/2610. The Multichannel VPN Router 300 configuration is not compatible with any other model.
• Fixed: VLANs needed by external VDSL modems connected to an Ethernet modules didn't work correctly.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

• New Feature: All routers now fully support the new CDMA/EV-DO modules available to customers in North America.
• The SNMP service had an issue that if enabled, a malformed SNMP query could cause a denial of service. This is now fixed.
• If DHCP was configured to act as DHCP relay, the service would not come up automatically after a reboot, DHCP relay had to be restarted manually from the webinterface. This is now fixed, DHCP relay will automatically start up after a reboot.
• Quite a lot of HTTP/HTTPS attacks to the webinterface did cause Internal Error messages in the logs. These were and are non-critical. The number of attacks that can cause these Internal Errors has been reduced.
• The new "Heuristic" Autotuning method could result in Internal Errors when used with unstable links. These internal errors could potentially result in lowered performance or in worst-case, unresponsive VPN Nodes. This issue is now fixed.
• SSL connection error messages will now more clearly state if they are related to VPN Tunnel connections or web interface connections.
• Several "Debug"-class log messages have been removed.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

• Huge performance increase: Compared to previous releases, the total bonded VPN throughput a router/hub can do has increased by about 30%.
• User rights management system in AdminDesk - you now may create groups and users who only have read/write rights for certain objects. This can be used to enable customer access to their tunnel's settings only.
• VPN Hub: You now may create port forwardings mapping destination IPs at the VPN Hub to private IPs behind VPN Tunnels
• WAN VLAN Support: The Ethernet WAN modules now can use VLAN tagging. This is useful e.g. for external VDSL modems that require tagged Ethernet frames
• VPN Hub: LAN/LAN alias VLAN support. You now may use multiple VLANs at the LAN interface of a VPN Hub. The main IP configured in LAN Settings always will be sent untagged (VLAN0) and serves as access to the public internet. Traffic going there from the Tunnels matching a NAT rule will be NATted. In addition, LAN aliases may use tagged VLANs. This way it becomes possible to have dedicated networks
• "Tunnel segmentation" - similar to VLANs, you may group multiple tunnels by assigning them the same tunnel segmentation ID. Internally, all tunnels with a different segmentation ID are completely separate. This makes it possible to have multiple customers with multiple sites each terminated on one VPN Hub, where all sites per customer can see each other, but customers can't see other customer's networks. It is even possible to have multiple customers use the same private IP network - e.g. two customers that both use 10.0.0.0/8. If the tunnel segmentation ID chosen is the same as a VLAN ID assigned on a LAN interface, then traffic from all tunnels with this ID may exchange traffic with these VLANs, with all other customers not being able to reach the VLAN. Using this in combination with a VLAN-enabled switch at t

• In all previous releases, there have been stability issues with hot-plugging LTE modules. Unplugging or power resetting an LTE module until now could cause the router to automatically reboot. This was especially inconvienient as the LTE technology on the carrier side is still rather unstable, and having automatic LTE module resets inside the Viprinet router would help here. With the current release, the issue is now fixed: LTE modules are fully hotplugging capable.
• With the availability of the new Hub 5010, this product now has been marked compatible to the Hub 5000 inside the firmware. Should you wish to run a mixed setup of Hub 5000 and Hub 5010 using the redundancy system, you need to upgrade the Hub 5000 to this firmware release.