Firmware Classic Stable

Classic Stable Firmware Release November 27th, 2015 – Version 2015081830/2015102900

This stable firmware fixes a couple of bugs relevant to upgrading to RuggedVPN. It also contains important bug fixes for anyone using mobile Broadband (UMTS, CDMA, LTE) in their setup, and fixes rare Hub 5010 crashes and issues that can occur with Node stacking.

This firmware release is compatible with both the February 25^th 2015 stable firmware release (Version 2014110730/2015021100) and all cutting edge releases since. We recommend updating each and every Viprinet Hub and Node to this firmware. The firmware release is identical to the October 29^th Cutting Edge firmware.

New features

The license manager available in RuggedVPN is now also available in the classic firmware.
The SupportID that is needed to register a router for the upcoming Viprinet Lifetime Maintenance System is now displayed.
It is now allowed to upgrade from Classic to RuggedVPN without a maintenance license in place. A warning will be shown when doing so. Please note that RuggedVPN still requires a VLM subscription. However, you no longer have to do the VLM registration first before installing RuggedVPN firmware, but can do this after installing it. After installation of RuggedVPN, the router will keep working for 14 days. If no VLM license has been installed (or if the router hasn't been downgraded to Classic firmware) by then, the device will cease operation. This also allows our customers to trial RuggedVPN firmware.
This firmware introduces full support for Northern European LTE 450 modules.

Bug fixes

Using multiple of the new 4G modules could completely block the router in case the module had been unable to read home network information from the SIM.
Network name display for some carriers (e.g. T-Mobile) was broken for the 4G Europe II module.
Under very rare circumstances, corrupted SSL data could cause the Hub 5010 to crash and reboot.
4G modules used in a stacking slave for some mobile networks have been unable to connect.
Under rare conditions WWAN modules may fail to read the IMSI and Home MCC/MNC from the SIM, causing Automatic APN Detection to fail.
APN Database entries updated for AT&T USA, Rogers and Telus Canada.
A rare crash bug on VPN Hubs caused by outdated VPN Clients connecting was fixed.
In a node stacking setup, stacked Nodes would never share LAN routes.
Fix for GPS not updating speed and heading.
All products should be displaying CPU and System core temperature now. Please note that for some products a different temperature sensor deeper inside the CPU is now used. This may cause your CPU temperature to jump up by 10–20°C. This is not a problem and not a defect.
QOS rules only matching on TOS did get ignored in the past.
Updated all warning popups in regards of missing maintenance contract and RuggedVPN. We'd like to apologize for any confusion caused by these nag screens in previous firmware releases.
When a classic router was connecting to a RuggedVPN Hub, under very rare circumstances traffic could have been blocked for QoS classes using BondingTCPOptimizer on the classic node.
In the past, changing “Enabled mobile technologies” sometimes did not work, especially when executed on a module that right now has a data connection open. It now should always work.
After router boot, a stacking master node could fail to bind its communication socket under rare circumstances, causing stacking slaves not to be able to connect to the master, which in turn would cause a split brain situation. In this worst case, the stacking master will now instead reboot to resolve this split brain.
In very rare circumstances two stacking nodes right now being in a split conflict while at the exact same time reconnecting to a Hub with the tunnel previously having been disconnected for less than 3 minutes could cause the Hub to crash.
In SNMP, vpnRouterCPULoad was exported as string instead of integer as it should be.
For VDSL Modules the sync speed reported in the log (“Synched Downstream/Upstream Rate”) was swapped. The actual values used were correct, so this is a display issue only.
In case a VPN Hub had an invalid DNS resolver configuration, doing the DNS reverse lookup for incoming channel connections could take very long. In case of a lot of channels reconnecting, this could delay any connects to complete for a very long time. Now, incoming channel connections are no longer reverse-resolved.
Licenses will now be deleted if instructed by the license server, and the online license deactivation function also is available now.
Fixed bug that caused the device MCC/MNC not getting re-read in case the first read failed. This caused the APN auto detection to sometimes fail.
Resetting or reconnecting an LTE module can cause the router's internal timer to get out of sync for up to two seconds. Due to this, channels will behave strangely – you can see high latency, channel stalls etc. This problem is now fixed. Reconnecting or resetting an LTE module no longer should affect other channels.
Due to the Anti-DDoS connection limiter not being initialized correctly, in all previous firmware releases sometimes the config data transfers between active and Hotspare Hubs could fail with an SSL error.
The maintenance license type “Iron” which will be used in OEM projects is now supported
A pre-existing config file from a previous RuggedVPN install will now be removed when doing a factory reset
There was a way to close SSH CLI connections without the connection limiter knowing. This could cause an IP getting locked out of the CLI forever after too many reconnects.
License manager will now always use the right interface to do license activations and de-activations. Before it only worked if the default route was on a VPN Tunnel.
The connection limiter / DDoS protection has been changed. HTTP, VPN, SSH, Stacking and Hotspare connections are now counted individually per IP.

Classic Stable Firmware Release February 25th, 2015 – Version 2014110730/2015021100

This new Stable release is the final firmware release of the “classic” series bringing new features. After that, new features will only be available in our “Next Generation” firmware platform.

This release will fix any remaining stability problems of our well-tested firmware in order to make it ready for a long use cycle (that means until customers will upgrade their devices to the NG firmware).

In addition, this release is fully compatible with the October 2^nd 2014 stable firmware release. It is therefore OK to keep running the previous Stable Firmware release on VPN Hubs, and only update VPN Nodes that need the improvements listed here. Devices that are already running the Cutting Edge Firmware release 2014110730/2015021100 from February 11^th, 2015, don't have to be upgraded – the firmware images in Cutting Edge and Stable are currently identical.

Customers still running earlier firmware releases than the October 2014 stable firmware are advised to check the release notes of that release in detail before installing this release, due to a high number of improvements and bug fixes.

Please note that you need to install this firmware release for VDSL or 4G Europe II modules to be supported.

New features

It is now possible to configure DNS servers for VPN Client groups. If done so, the VPN Client will use these DNS servers instead of using the Hub's DNS. This allows the VPN Client to be used in combination with a Domain controller, so VPN Client users can become part of a Windows domain.
The new “4G Europe II” module is now supported.
The CLI now supports ping, traceroute and moduleinfo tools (similar to what you can use in the web interface).

Bug fixes

Fixed race condition that caused update scripts to sometimes get called twice when starting them manually.
Very big (100MB+) local update packages are now supported.
Fixed the bug that offline firmware uploads are sometimes aborted, resulting in corrupted firmware uploads getting rejected. This happened if there was just 100ms without data getting sent during the upload. It mostly happened with the new web interface and when doing updates remotely.
The distribution of system load on multi-core Hubs has been improved.
Changed maintenance contract warning start to March 2015.
Several improvements for LTE status reporting.
Fixed a bug that caused OptimalLatencyBelow not to be displayed in monitoring API and -tool.
IP address of a replaced device in Hub hotspare mode is now shown in the new web interface.
Several bug fixes for the channel congestion notification system.
The SIM traffic reporting could end up in a state where it never committed its values to the accounting server.

Classic Stable Firmware Release October 2nd, 2014 – Version 2014093030/2014100200

This new firmware release contains important bug fixes for our August 2014 Cutting Edge and Stable Firmware releases. It also fixes all potential security issues with the embedded Bash shell used internally in our routers (known as “Shellshock”). Although the Shellshock attack is very hard to achieve without local system access in regards to our products, there still is a significant risk that needs to be closed.

We urge all our customers to update to this firmware release as soon as possible.

This firmware release does not bring any new functionality but major bug fixes only. Also, this firmware is identical for both firmware branches, Cutting Edge and Stable.

Customers still running earlier firmware releases than the August 2014 stable firmware are advised to check the release notes of the August release in detail before installing this release, due to a high number of improvements and bug fixes.

Bug fixes:

Since last week, multiple exploits in the widely used bash-shell were discovered. While we don't use the bash shell in any direct way where it would be exposed to the outside world, it is used by the DHCP client service running for the WAN modules. There is an unconfirmed possible attack vector, in that if an attacker would be able to run a compromised DHCP server connected to a Viprinet WAN Ethernet module, and if this Ethernet module would be configured to use DHCP, the router could be made to execute code using manipulated DHCP options.

This release incorporates all published patches to bash and to our knowledge fixes all known vulnerabilities.

Until you have updated, disabling DHCP on WAN Ethernet modules and instead using static IP configured would also close the potential attack vector.

To the best of our knowledge, there is no attack vector for VPN Hubs, and no attack vector with any other of our router or VPN services.
VDSL modules would always return “No answer received from modem” when checking module info
CDMA450 modules had several problems with resetting and switching from/back to power saving mode. All of these issued have been fixed.
In very rare cases, SIM initialization could fail for our LTE modules due to a Qualcomm bug. A work-around makes sure this no longer happens.
By creating invalid port forwarding entries, you could create a port forwarding of doom which would lock you out of the router. You no longer can shoot yourself in the foot this way.
If you would create a routing rule where all options would have been set to “Ignore” you would effectively create a default route, potentially locking yourself out of the router. This way of shooting yourself in the foot also no longer works.

Classic Stable Firmware Release August 18th, 2014 – Version 2014061630/2014080100

This new firmware release brings a couple of new features and a big number of improvements.

This firmware is identical to the Cutting Edge Firmware Release of August 6^th, 2014 (Version 2014061630/2014080100). If you’re already using this Cutting Edge Version, you don’t need to update.

The most important new feature is that with this release, Hubs and Routers are able to notify each other if the other side has rebooted. This fixes a number of problems that originated from certain kind of traffic if only one side of a tunnel got rebooted, and if that reboot lasted less than 3 minutes. The non-rebooted side would expect a re-establishment of the previously existing tunnel connection, keeping all old connection flow states intact while the rebooted device started with empty state. This would cause connections that were running prior to the reboot to get stuck. While for most protocols this is a not a problem, it is for example a big problem for IPSec which always re-uses the same UDP connection parameters (source/destination port). These connections could get stuck for a very long time.

Long story short: This update should fix the problems for all customers running IPSec or similar tunnel protocols (GRE) and had their tunnel inside a Viprinet tunnel stuck if either their Router or Hub had rebooted.

What's also very important news is that this firmware supports a new concept called "Managed SIM": a centralized SIM accounting with shared traffic as well as reporting and monitoring. For now this service is only available for our customers in Germany, but we plan to also offer these services in other countries.

Also, VDSL modules are now fully supported.

And finally, several optimizations for using Viprinet in high-speed vehicles have been made.

While this release is fully compatible with the Stable Firmware released on April 6^th 2014 (Version 2014021430/2014022500), some of the new features only work if both Hubs and Routers are updated. We therefore recommend updating Hubs and Routers at the same time.

This release also contains an important bug fix for 5XX Routers – without this bug fix, these devices may permanently go out of service if power is lost at a certain moment during startup. We therefore urge all customers using models 500, 510, 511, 512, or 513 to update to this release as soon as possible.

Important notes for users upgrading from older firmware releases

If you wish to update from anything older than the last Stable Firmware release (2014021430/2014022500), please consult the release notes of all firmware releases since then, most importantly the release notes of the current stable firmware release.

List of changes compared to the former Stable Firmware release

New features

Hubs and Routers are now exchanging “boot IDs” informing the other side whether the remote end has rebooted, and thus can clear the flow state accordingly.
VDSL advanced settings are now available.
Viprinet Managed SIMs are now supported.
Maintenance contracts are now supported by the firmware.
New channel fine tuning setting “RapidReconnects”: If enabled, channels will very show a very aggressive reconnect behavior which includes restarting the WAN module used if a channel stalls for a longer time. Turn this option on only if the router is going to be used in a high-speed vehicle typically going faster than
100 km/h.
When restoring a config backup, there now is an option “Do not overwrite existing licenses”. If this is set, licenses bound to the router prior to uploading the backup will stay intact.
New function “Clear dynamic leases” inside the DHCP Server settings.
New channel finetuning option “Save traffic when idle”: needed for Vodafone UK not to kick out idle channels out of the UMTS cell into some weird high-latency idle mode. This idle mode causes modems doing very low traffic to constantly getting thrown out of UMTS cell towers, with the need for them to then re-register. This idle mode causes an idle link latency of about 350ms, and a surge in packet loss and/or latency of up to 2500ms each time the channel starts to transmit significant amounts of bandwidth again – after that surge the behavior of the network turns back to normal. All of this can cause lots of troubles with achievable throughput and channel autotuning. We think that what Vodafone is doing here is a terrible idea and a standards violation, but we have to deal with it.
The new “Save traffic when idle” option is enabled by default, which is identical to the behavior in previous firmware versions when this option didn't exist. If you disable the option, more idle ping traffic (about 10–15 KBit/s) will be generated, making sure the modem is not kicked out of the UMTS cell. However, you will burn more data traffic for this. We recommend disabling this option for the Vodafone UK network only.
An alternative solution to the problem is to Disable Latency Autotuning for channels using Vodafone UK networks and inside the channel finetuning settings choose a “Optimal Latency below” value of 400ms, and a “Maximum allowed latency” value of 2500ms. This way the channel stays usable even if Vodafone UK enables the idle mode.
Also 3G monitoring code can now detect this weird idle mode and will properly report it through monitoring tools as registration state “Normal / Idle”.

Bug fixes

If Latency Autotuning is turned off for a channel, the channel no longer will do a ping test when changing from ConnectedStalled to Connected. This way the channel can be used again much quicker after a short stall (e.g. when a vehicle is going through a highway tunnel).
In very rare cases (high-speed trains), LTE modules could crash in a way that they were detected to be still up – forever. New watchdog code now makes sure that such "frozen" modules are automatically powercycled.
Cell IDs are now properly reported with LTE modules (before they typically showed "0" as Cell ID).
The receiving side of a BondingDiversity flow had a serious memory leak which after some time could cause that device to run out of memory.
If power was lost at a specific moment during boot up on 5XX routers, the firmware storage could get corrupted which would cause the router to no longer be able to start up. This could be seen in installations where the 5XX router was used in a car that very often was powered on only for a couple of seconds before getting powered off again.
The SSH CLI no longer listens on WAN interfaces as these cannot be controlled by an ACL.
A couple of objects inside the web interface in previous firmware releases would ignore deletion attempts, e.g. licenses and stacked routers. Now these objects can successfully be deleted.
On 5XX Routers, time zone management had been broken in all previous firmware releases. This caused reports to the traffic reporting server to use wrong timestamps, and also caused web browsers not to cache any elements of the web interface.
Due to a bug, the QoS Class setting “Required Link Stability” has mostly been ignored in all firmware releases during the last year. Therefore, an unstable channel could ruin the throughput for tunnel traffic even if due to the “Required Link Stability” setting the unstable channel was not expected to be used. This fix will bring a significant improvement for setups where unstable links are bonded (moving vehicles).
CDMA450 modules may crash when trying to reset them in a 5XX router. The reset option for these modules therefore now is ignored.
The various forms of download test tools inside the web interface had problems on 5XX routers where they could get stuck or abort.
Rights management for WAN modules has not been persistent and lost during router reboot, and also has not been marked as available in the new web interface. It now works, and therefore it’s possible to grant non-root users access to WAN module configuration.
The download test tool would not abort downloading if you closed the download test tool window inside the new web interface, causing unneeded data traffic to occur.

Classic Stable Firmware Release March 6th 2014 – Version 2014021430/2014022500

In the light of the NSA revelations, this Stable Firmware release takes the security of our products to a new level. We have spent the past weeks to improve pretty much every security-relevant aspect of our products.

In addition, this firmware release includes a finalized and stable version of our new administration web interface, which had been available as a preview for a couple of months.

And finally, this release brings a lot of bug fixes.

This release is fully compatible with the Stable Firmware released on August 12^th 2013 (Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)). A mixed installation of Routers and Hubs using the previous Stable Firmware release therefore is possible. However, many of the improvements in security require support on both sides of the VPN. We therefore recommend updating both the Router and the Hub to this firmware in a timely manner.

Important notes for users upgrading from a previous Stable Firmware Release

Viprinet routers now support access control lists. Using this you can define which IPs and subnets from LAN or WAN/VPN may access services. Upon firmware upgrade, a set of default rules will be created. These are designed in a way not to interfere with existing installations, and it is recommended to tighten them. For example AdminDesk access currently is allowed both on HTTP and HTTPS from everywhere, while we recommend only allowing HTTPS from the Internet.

Due to the new ACLs the AdminDesk SSL certificate settings have moved from “[ AdminDesk ] LAN settings” to “[ AdminDesk ] Integrated services”. Should you have installed your own custom SSL certificate, you will have to re-install it after firmware upgrade.

All SNMP settings also got moved to “[ AdminDesk ] Integrated services”. After firmware upgrade, you will have to re-configure SNMP.

List of changes compared to the previous Stable Firmware Release

New features

The new web interface is now feature complete, and all known bugs are fixed. It is now also used as a default.
HTTPS usage for web interface access is now highly encouraged.
The encryption for the web interface has been highly improved. We are now using 2048-bit RSA key + SHA256 certificated, TLS 1.2 and Perfect Forward Secrecy (Elliptic curve Diffie–Hellman). At SSLabs, Viprinet routers score with an “A” mark.
The encryption for the VPN tunnels has been updated accordingly. In addition, the VPN Routers will now take a fingerprint of the VPN Hub’s SSL certificate, and reject re-connecting to it in case the fingerprint changes. This is done in a way that the fingerprint will neither change when changing VPN Hub Redundancy settings nor if you move over the VPN Hub configuration to a new VPN Hub. The new system prevents a theoretical Man-in-the-Middle attack against our products, where an attacker would place a device in front of the VPN Hub, stealing the VPN Hubs IP and pretending to be that device.
The new improved security features put a higher load onto the Hub when a channel is established. If a very high number of channels would connect to the Hub at the same time, the very high load would result in a kind of DoS on the Hub, and actually could lead to a load feedback loop: Due to the high load, the SSL handshake of the channels would not complete within the timeout range, and therefore disconnect and reconnect, causing even more load.
We have now implemented throttling on both the Hub and the Router. If a channel is aborting during connecting to the Hub, it is now throttled instead of hammering the Hub with connects. On the Hub side, under situations of high CPU load, acceptance of new channels is delayed in a way which does not result in timeouts.
With these changes we are now able to survive a higher channel connection load on the Hub than with the previous stable branch firmware (which has less secure SSL handshake).
For multiple authentication failures on the SSH CLI, further login attempts from the same IP are now throttled. This makes brute force attacks on SSH unfeasible.
The behavior of Routers and Hubs during a DoS attack has been improved. If a source or destination host was doing more than 25,000 flows (TCP Connections), it would get blocked. However, if it was the Hub IP being attacked, this would result in the Hub IP itself also getting blocked, making for example the web interface of the Hub unreachable until for example a TCP SYN flood DoS was over. Now, locally bound router IPs are no longer blocked. Also, logging amount during DoS attacks caused significant CPU load. This has been reduced. A blocked host is now only logged once, and again once it is unblocked (which happens if the number of active flows goes below 24,000 again).
Channel Bandwidth Autotuning by default will no longer generate log messages. This highly reduces the number of log lines generated on busy VPN Hubs with lots of Tunnels/Channels. Logging can be turned back on a per-channel basis.
Channel and WAN bandwidth reports now are only logged every 10 seconds, and if the link speed of a WAN device is unknown, it is no longer reported instead of reporting “0/0”.
Our new VDSL modules are now fully supported (including VLANs and RFC1483)
Multichannel VPN Router 200 is now supported (to be first displayed at CeBIT 2014).
Complete overhaul of the LTE module monitoring code. This firmware now for the first time fully supports our 10-01031 and 10-01032 modules designed for USA and Canada. It also is much better at analyzing used technologies, and will also report the current frequency/Band that is used.
The logic on which a config coming from a different router is marked compatible with which product has been rewritten. Now project routers are marked as compatible with themselves (another router of same model and project number) or with the standard model of the exact same product. Example: 50-00300 is compatible to 50-00300 and 01-00300, but incompatible to 51-00300.
The three different types of LTE modules will now automatically rename themselves to “LTE 700 AWS/UMTS/HSPA+/GPRS/EDGE” / “LTE/UMTS/HSPA+/GPRS/EDGE” / “LTE 700/CDMA/EV-DO” once the chipset model has been identified.
VPN Clients connected to the Hub will now use Hybrid autotuning on the Hub instead of Heuristic. This reduces the amount of test traffic in situations where the PC's WAN connectivity is very unstable (say, a Laptop user sitting in a moving train).
For all local services (DNS, AdminDesk HTTP/HTTPS, SSH CLI, SNMP), there now are access control lists. Using this you can define which IPs and subnets from LAN or WAN/VPN may access services. Upon firmware upgrade, a set of default rules will be created. These are designed in a way not to interfere with existing installations, and it is recommended to tighten them. For example AdminDesk access currently is allowed both on HTTP and HTTPS from everywhere, while we recommend allowing only HTTPS from the Internet.
PLEASE NOTE: Due to the new ACLs the AdminDesk SSL certificate settings have moved from “[ AdminDesk ] LAN settings” to “[ AdminDesk ] Integrated services”. Should you have installed your own custom SSL certificate, you will have to re-install it after firmware upgrade.
PLEASE NOTE: All SNMP settings also got moved to “[ AdminDesk ] Integrated services”. After firmware upgrade, you will have to re-configure SNMP.
There is now a fully automated diagnostics tool available, which will test throughput, packet loss etc for all interfaces. For VPN Nodes, local modules and also all modules from stacked routers are measured, as is VPN performance. For VPN Hubs, only the throughput of LAN and WAN interfaces are measured.
Using this tool doing first diagnostics in all kinds of “I'm not getting the performance I've expected” kind of cases becomes far easier. We highly recommend you make good use of this tool.
You can find the “Connectivity diagnostics tool” inside the “Logging & Maintenance” settings (old web interface only, not yet available in the new Web interface beta).
If you wish to test optional router features, you may now generate a free 30 days trial license at https://license.vipri.net/trial.php using the Trial Token listed inside the router’s “Product features License Manager”.
This web service will generate an activated license file that you then add inside the web interface. The generated license will activate all optional features of the router for a period of four weeks. It may be extended once using the web server, but afterwards the license remains locked for a month. Please note that at the end of the trial phase, the router will automatically reboot.
Please note that Viprinet support will no longer manually issue trial licenses for router features. Please use the self-service system instead.
The total of current Bandwidths from/to WAN of all channels is now available as a data source for the tunnel in the Monitoring API.
Some performance improvements, which result in all products roughly being able to have 5–10% more bonding capacity.
The Viprinet router startup code has been optimized. Starting a Viprinet Hub that has tons of Tunnels is now much quicker than before.
The routers now have a maximum number of Tunnels that can be configured.
PLEASE NOTE: This doesn't mean the router will actually be able to serve this many tunnels at the same time at acceptable performance – this also depends on the number of Channels per tunnel and complexity of QoS rules.
Here are the maximum numbers of tunnels per product:
- 300: 25
- 500: 25
- 1600/1610/2610/1620/2620: 50
- 1000/1020: 100
- 2000/2020: 150
- 5000/5010: 500
Until now, the Hub redundancy system was exclusively using Ethernet broadcasts for the Hubs to communicate with each other. Due to a technical limitation in the used communication protocol, Hubs could only share configuration files if their compressed size has been below 64k. Sadly there was no way for the user to judge on how big the current configuration would be. If the compressed config was above 64k, the Hub Redundancy system would fail syncing configuration files. For some Hub 5010 installations with a high number of tunnels and QoS configs this limitation was hit in real life.
In addition the broadcasting protocol had a design problem – with a lot of VPN Hubs operating at the same time, it was possible for multiple Hubs to send their configuration to the Hotspare at exactly the same time. In this case due to fragmentation this could result in no config being received by the Hotspare. This problem got worse if multiple Hotspares were running for a single redundancy group.
We have improved the Hub redundancy system in that the main communication still runs over Broadcasts, but that for config transfers now a direct TCP connection to the Hotspare is established. Due to this, the size of Hub configs to be synched now is unlimited. The new protocol has been designed in a way that is downward-compatible. This means that Hotspare Hubs running the current firmware can still serve productive Hubs that run the previous stable firmware and don't yet are able to sync configs using TCP. We still recommend having all Hubs in a redundancy group using the same firmware release, though.
Until now, Viprinet routers would sometimes mark traffic flows as unroutable if the tunnel was down while the flow got established. Since the last stable firmware release, this got even stricter: Any traffic flow that was established before the tunnel was up would be marked unroutable forever. This was not expected to be a problem – most sane protocols would abort and reconnect. This isn't the case for e.g. ISAKMP of IPSec, which is a brain dead protocol – it always uses UDP source and destination port 500 by convention. This makes it impossible to differentiate these ISAKMP flows, and obviously causes also huge problems with NAT gateways. In Viprinet, if an IPSec Gateway would establish an IPSec tunnel before the Viprinet tunnel was up (for example because the Viprinet router got rebooted, but the IPSec gateway didn't), this would cause the ISAKMP flow to be marked unroutable forever. This is because the IPSec Gateway would never “abort“, and even if it would, a new IPSec setup would look like the old one – as UDP source and destination ports would never change.
Due to this, if the IPSec Gateway didn't use sane timeouts, this could lead to IPsec tunnels through a Viprinet tunnel to get stuck forever.
This didn't cause any problem with IPSec gateways we have tested internally because with these, if the ISAKMP handshake fails, they wait a couple of seconds before retrying. By then, in the Viprinet router the UDP port 500 flow will have timed out, and the new ISAKMP setup will be regarded as a new flow, which due to the Viprinet tunnel now being up is marked routable.
As we have learned, that's not how all IPSec gateways behave – some are hammering without any back-off in case the ISAKMP handshake doesn't work. That's a stupid design, but it is what it is.
We have changed the routing design inside the Viprinet router to cope with these kinds of problems, while still getting optimal performance. Traffic flows marked as invalid/unroutable will now be rechecked every 2 seconds if in the meantime it became possible to route them. This way we neither have high load caused by systems flooding the router with unroutable destination IPs (which would enable some form of DoS), nor do we have a problem with protocols that hammer with always the same flow while the Viprinet tunnel is not up yet. It is impossible to test with all available IPSec gateway combinations, but with those that we have tested IPSec tunnels now typically get (re-)established within a couple of seconds after the Viprinet VPN Tunnel has come (back) up.

Bug fixes

We have fixed a potential VPN Tunnel protocol downgrade attack. In a man-in-the-middle-attack, an attacker could force a VPN Router to fall back to an outdated Viprinet VPN Tunnel protocol version where the Tunnel password would be sent over in clear text over the SSL connection. This way the tunnel password could be stolen, and a rogue VPN Router operated by the attacker could be connected to the VPN Hub instead of the real one, gaining access to the VPN. We would like to thank Portcullis Security for their research and advisory on this issue. The old VPN Tunnel protocol versions are now disabled.
Both inside the old and new web interface, input filtering wasn't done properly, enabling all kinds of cross-site-scripting attacks (XSS) for logged in users. All known attacks are now properly filtered.
From this release, you can no longer create objects (Tunnels, Channels etc) that contain illegal characters. Existing objects will still load. Check your log files for critical warnings on this, and rename all objects with illegal special characters in them – in the next firmware release, these objects will no longer be loaded.
Hybrid autotuning had a bug that could lead to MaxBandwidthToWAN being set to “0” and staying there.
If multiple users with the same user name were logged in to the web interface (new or old one, doesn't matter), every user would only receive a part of the log messages.
If Channel Bandwidth Autotuning was turned off for a connected channel and MaxBandwidthToWAN manually set to “0” (as it is sometimes done on the VPN Hub to not use the downstream of an expensive UMTS/LTE link, but only use it as an upstream booster), various weird effects could occur. If the channel had the lowest latency, best LinkStability or lowest Cost, QoS classes could select this channel as the preferred one to use while not being able to actually transfer any traffic through it. Due to this, these QoS classes would no longer transport any traffic. Channels that have zero bandwidth now are ignored by the QoS system.
In a Node Stacking setup, sometimes on the Slave device a DHCP service would be running while it should not.
The CLI now correctly should be supporting int64 and float values. Therefore, you now should be able to read GPS position data using the CLI.
For LTE modules, the “Expected link capacity” value was wrongly set if the module used HSDPA. This was rarely seen in the EU, as here you typically get HSPA+ instead (=HSUPA and HSDPA+). If the combination has been HSUPA+HSDPA, you would end up with an expected link capacity of 384 kbps downstream, which would affect autotuning. However, the issue was frequently seen with AT&T and T-Mobile in the USA.
On the 300 router, we have seen buffer overruns on the LAN interface in situations where there was a big spike of packets going out to the LAN. For instance, this happened when bonding unstable links, where data was released in huge spikes after a situation of packet loss / retransmissions. The problem would cause lost packets on the LAN. And these lost packets would result in application-layer TCP retransmissions, which with high latency links could limit the achievable throughput quite a lot. The problem would automatically improve after a couple of hours. However, this often meant that 300 routers in demo situations (just powered on to demo bonding of UMTS/LTE) would show unstable download speed.
This problem should now be fixed.
To validate, go to “[ AdminDesk ] LAN settings -> Ethernet interface info tool”.
There, the “overruns” counters for TX and RX now should always stay at 0.
A bug in BondingTCPOptimizer has been fixed – certain devices when sending a zero window could get stuck as the Linux-style of window probing that Viprinet used was ignored. We now also randomly do a Windows-style window probe (trying to send data which is out of the window). This fixes video streams getting stuck on Samsung Smart TVs.
This release contains preliminary experimental support for the upcoming new VDSL modules.
There have been problems both with Hubs 5000 and Hubs 5010 that under certain circumstances the LAN interface could block, no longer receiving any packets. These problems have been fixed.
There have been multiple bugs in regards of the Hub Redundancy system. If you would run a big number of VPN Hubs in a LAN segment in a data center, sometimes config file sharing would not work. Also, running multiple Hotspare Hubs for the same Hotspare group (which is a good idea) could sometimes (rarely) cause two Hotspare Hubs to take over the identity of a dropped out active Hub at the same time, causing an address conflict. All these bugs have been fixed, and running multiple Hotspares for a Redundancy group now works fine.
Sometimes under rare circumstances, IP flows running through a VPN Tunnel could get stuck. In this case you would see “10001 packets in WANPacketHeap” in the log. This sometimes was seen with flows that run “forever” (like IPSec tunnels through a Viprinet tunnel) on systems where the Viprinet VPN Tunnel would often disconnect due to unstable WAN links. Flows no longer should get stuck in this case now.
If BondingTCPOptimizer was used, certain corrupted TCP packets could cause a memory leak. A very high stream of these packets (for example in a DoS attack) sooner or later could make the router reboot.
Small bugfix for BondingTCPOptimizer – with very slow servers, retransmissions of SYN packets could cause weird behavior. Seen in real-life with Samsung TVs and German VOD service Maxdome.
Conflict resolution while restarting of stacked routers got improved.
A bug was fixed which could in rare situations cause a tunnel channel to abort connecting to the VPN Hub with an SSL handshake error.

Classic Stable Firmware Release August 12th, 2013 – Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)

This new stable release brings a big number of improvements. Most of these fixes have been available as a "cutting edge" Firmware release since early July and have proven themselves in the field. We recommend all customers to upgrade to this stable firmware in a timely manner.

Focus for this release have been the following features:

Lots of improvements on the channel autotuning
Stability fixes for Node stacking
VLAN support on Nodes (no license required)
Metric tons of fixes for Ethernet auto-negotiation. Turning off auto-neg and setting fixed parameters now finally works for all products, all LAN and WAN interfaces, and all Ethernet modules.
Addition of Required Link Stability to QoS classes which allows you to exclude unstable channels for QoS classes where packet loss or jitter is critical (for example VoIP)
Much improved HTTP download test tool, integrated test traffic generator into Hubs/Routers
Protection against DNS Amplification attacks
If VPN Clients would connect/disconnect from VPN Hubs in a certain time pattern, sooner or later the VPN Hub could crash and reboot.

Here is the list of changes in detail:

Improvements

Highly improved channel bandwidth autotuning. You will now get much better results for all kinds of lines, especially Sat links. Hybrid autotuning will now get much better results on its initial tests on VPN Tunnels that are idle. Congestion on the channel will much less drastically slash down Max Bandwidth To WAN, which means you will see better performance on WAN links that have surges of packet loss.
VLANs on Nodes are now supported in the following way:
- In the LAN settings, there is now a "Allow route-back" option. If enabled, traffic coming in from a VLAN can be routed back to the same or a different VLAN – in other words, VLAN segments may talk to each other. If disabled, traffic coming in from the LAN with a destination on the LAN instead will be dropped, so the VLANs are completely separated in this case and all may only talk to the VPN Tunnel.
- On the Node, you have the option “Allow all VLANs to talk to tunnel”. If that is enabled, all VLANs can talk to the tunnel; if disabled, only VLAN0 can.
- In the WAN/VPN Routing settings on the Hub, you also have an “allow route-back” option. If disabled, traffic coming in from the Tunnel which would go back to the same tunnel (see above) again will be dropped.

Using these features, you can implement both a Node which has a local VLAN that is not allowed to talk to the VPN but to the remaining LAN, and you can also have a setup where you have multiple VLANs that really should be separated from each other but be able to speak to the VPN (for example, both a corporate network and a public visitor WLAN).

Please note that VLAN tags are NOT transported through the tunnel. On the Hub side, all traffic still will come out of a single tunnel with a single Tunnel Segmentation ID. If you need to deal with the networks routed separately, you need to create a VLAN on the Hub and route all traffic from the tunnel to a next-hop in this VLAN, where you separate the traffic according to their source IPs into different multiple VLANs again.

All Routers and Hubs now have an integrated HTTP test traffic generator which can be enabled at [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads

If enabled, HTTP test downloads can be done from this router without requiring any sort of authentication. This should only be enabled while you are running tests yourself and turned off for production systems.

If enabled, a stream of random data can be downloaded from this router using the following URL:

http://[your router IP]/exec?module=download&speed=Speed&size=Size

Speed is in Bits per Second, 1K means 1 Kbit/s, 1M means 1 MBit/s, 1G means 1 Gbit/s. The speed parameter is optional. If this parameter is not given, the maximum possible link speed will be used. The maximum allowed value is 1G.

Size is the Size to download in Bytes, 1K means 1 KByte, 1M means 1 MByte, 1G means 1 GByte. The size parameter is optional, if not given, 16 GByte is assumed, which is also the maximum allowed value.

Viprinet routers now contain a security feature to protect against the most common form of the DNS amplification attack – a single IP now is only allowed to do 2 ANY requests within 60 seconds. We still recommend implementing more advanced DNS Amp attack protections in your core firewall.
The download test tool available in the LAN settings and module settings has been extended and improved a lot. It can now download test files from a world-wide content delivery network provided by Viprinet, which will automatically chose the Edge server nearest to you, or – if the Hub is using this firmware – download from the Hub traffic generator. You now therefore have a tool which you can easily use to test for connectivity and throughput problems with WAN interfaces, and can easily check where your bandwidth bottleneck is. Use it!
In the channel fine tuning settings, you can now define a minimum Link stability a channel is expected to have, with a warning getting sent to the log system in case the link stability goes lower than this value. For non-moving installations, a non-broken link should have more than 90% of stability, for moving vehicles it depends on the typical coverage. Using this setting, you can make it easier to automatically get notified of link problems (for example, a SIM card running into the traffic limit).
The monitoring API used by the Viprinet Monitoring tool caused quite a lot of CPU load on the monitored router. That load has been decreased.
In the past, the configuration system (both web interface and CLI) would use a global lock which could lock up the routing core for several seconds – for example, while you were applying LAN settings, the router would not route packets. This global lock now has been removed, and working in the web interface should no longer have drastic effects on the routing performance of Viprinet routers.

Bug fixes

If VPN Clients would connect/disconnect from VPN Hubs in a certain time pattern, sooner or later the VPN Hub could crash and reboot. This would most likely happen if a VPN Client connected to a VPN Hub, then disconnected and reconnected immediately, and then disconnect for at least 3 minutes before reconnecting. The problem is now fixed, VPN Clients no longer can crash VPN Hubs.
Fix in heuristic Autotuning: In theory (not seen in real life) autotuning could be stuck in an endless loop, causing lots of test traffic.
A high number of SNMP bugs has been fixed. Most importantly, Hot spare Hubs that take over / replace a Hub now will correctly report normal full Viprinet SNMP on the IPs taken over, and give Hotspare SNMP replies on the Hotspare IP.
SNMP no longer will change OIDs of other Tunnels if a Tunnel got deleted.
SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature are now implemented.
Due to a race condition, Node Stacking would sometimes crash in failover situations. Also, the “Failed to open slot for stacking” bug is fixed, as is the internal error 23239482394811Aa.
Turning off configured stacking would result in the wrong error message “[Stacking] This router does not have the stacking featured licensed. Can not start stacking!”
A Node Stacking slave would not stop the internal DHCP server in some cases. This would cause two DHCPs to run on the LAN, which caused problems.
The firmware online updater always required you to click “check for updates now” TWICE to get an actual result. Now the first click works.
ADSL modules sometimes have problems to get the module info read. We have increased the timeout for waiting for the modems diagnostics report reply. Please report to Viprinet in case you still get error messages trying to read module info from an ADSL module.
Everything related to “Ethernet speed and auto-negotiation settings” has been reworked. There had been bugs that turning off auto-negotiation didn't work for some products and some Ethernet modules, bugs that turned off auto-negotiation was ignored on next router reboot, and tons of more bugs. All of these have been fixed, and we have validated that manually setting Ethernet parameters now works with all products and modules, also across reboots.
The “Reconnect” function of Fast/Gigabit Ethernet modules no longer causes a PHY Reset / Ethernet Autonegotiation to restart. If you want that, reset the module instead.
Using VLANs and an MTU of 1500 didn't work with Fast Ethernet Modules (but it did with Gigabit Ethernet modules). It now works with both.
In reality, the routing core often would send more average bandwidth on a Channel than the Maximum Allowed Bandwidth to WAN would allow due to rounding errors. On some link types, this resulted in the link getting overloaded and the latency going up despite of perfectly correct autotuning results. These rounding errors have been fixed.
In the last stable firmware release, changing anything about LAN settings including LAN Aliases will become effective even before you hit “Apply Settings”. This could also cause unclean state if you were in the middle of creating a LAN Alias.
If “Allow remote service connections” was turned on, then turned off, remote service connections actually still were possible until your rebooted the router. Turning this off now will have immediate effect as expected.
The download test tool very often would abort “due to high CPU load”, even if the CPU load wasn't that high.

Classic Stable Firmware Release June 24th 2013 – Version 2013051031/2013062100

This firmware release builds upon our stable firmware released June 6th, which brought lots of new features, and fixes one important and a few more remaining bugs to bring this firmware generation to the quality level it should have been on.

For new features, see the release notes of the June 6th release.

Bug fixes

Important: All our recent firmware releases (stable and cutting edge releases since April 2013) contained a critical bug: If a VPN Tunnel got established, then disconnected, then reconnected, then disconnected with then keeping it disconnected for more than 3 minutes, both the Router and Hub could crash and reboot.
We are sorry for any inconveniences this may have caused to customers, and like to thank those of our partners who have spotted and reported the bug.
Due to this bug, we’ve decided to withdraw all firmware releases since April 2013 from our servers. If you are using one of the affected releases, please update immediately.
The download test tool inside the web interface would crash the router if the test file downloaded was using HTTPS.
Sometimes, Tunnel Channels on connect would disconnect and reconnect due to an SSL handshake error, and it would take a while until they would finally connect. This no longer happens; this random handshake error is fixed.
Passive and Hybrid autotuning, which are recommended to be used for mobile links (UMTS, LTE, Sat), had a tendency to optimize the Max Bandwidth To WAN to a value slightly above the actual optimal value. This would cause buffering on the channel, to be seen in the monitoring as a “sawtooth” like shape on both Latency and actual traffic through this channel. The autotuning has been improved to increase speed more slowly in cases where it is close to the “Optimal Latency Below” cut-off value.
This optimization improves stability of latency-critical applications like VoIP over unstable links a lot.
The 1020 and 2020 Hubs would sometimes report one or two of the fans to be turning too slowly, and would alert that those probably are broken. This isn’t actually the case, the minimum RPM of the fans had been lowered for these products compared to other products.
The download test tool quite often would abort due to too high CPU usage. It now is a bit more relaxed about that.
The Hub redundancy system now correctly marks the 1000, 1020, 2000 and 2020 Hubs to be compatible to each other. In previous releases, 1020 and 2020 were marked incompatible to the previous product generations.

Classic Stable Firmware Release June 11th 2013 - Version 2013060730/2013061001

This firmware release fixes an important bug which exists in multiple previous firmware releases, namely in:

Version 2013021930/2013042305 (Cutting Edge Firmware Release April 23th 2013)
Version 2013051031/2013060600 (Stable Firmware Release June 6th 2013)
Version 2013051031/2013061001 (Stable Firmware Release June 10th 2013)

Sometimes during power-up of the router or after doing a power reset of a WAN module, the internal references of the router could become confused and mixed up. In this situation, running a channel over the module in Slot 1 would in reality establish the channel over Slot 2 and slot IP assignments also would be mixed up. However, when looking at the modules inside the web interface, they still would appear to be in the right slot. This is a very confusing situation and hard to detect as an end-user. In real-life this bug has only been seen in routers that have multiple Gigabit Ethernet Modules installed. Routers with other modules have not been seen affected. However, in theory the bug could also appear with other module types.

All modular Viprinet routers (Multichannel VPN Router 300, 1610, 2610) running one of the firmware versions above are affected by this bug. All Viprinet Hubs and the Multichannel VPN Router 500 are not affected.

We highly recommend all customers who are currently running one of the firmware versions listed above to update their routers. There is no immediate need to update non-affected products (Multichannel VPN Hubs or Multichannel VPN Router 500).

However, all customers running a firmware older than June 6th 2013 (2013051031/2013060600) are recommended to update during their next maintenance schedule to make use of the various product improvements and new features that the current firmware generation is bringing.

(Note: The most current and recommended release for Multichannel VPN Router 500, Multichannel VPN Hub 5000 and Multichannel VPN Hub 5010 still is 2013051031/2013061001, released June 10th 2013; the most current release for Multichannel VPN Hub 1000, 1020, 2000 and 2020 is this release, which however does not have any changes to the previous 2013051031/2013061001 release).

Classic Stable Firmware Release June 10th 2013 - Version 2013051031/2013061001

This stable firmware release contains 2 important bug fixes for our stable firmware released on June 6th. For further information about what's new in the firmware, please check the release notes for the 2013051031/2013060600 release from June 6th.

Bug fixes

A couple of bugs existed in a Stacking setup with more than 2 routers. A slave switching from an old to a new master could crash, alternatively some of the shared modules of the slave would no longer work after the switch.
The "Download Test Tool" inside the web interface could crash / reboot the router.

We recommend all customers who have previously updated to the 2013051031/2013060600 release to update their routers a second time. All other customers are recommended to also update to the current firmware release to make use of the various improvements the June 2013 stable release has brought.

Classic Stable Firmware Release June 6th 2013 – Version 2013051031/2013060600

This stable firmware release brings a bunch of new features, and a high number of improvements and bug fixes. The most important new feature is that stacking of node routers is now supported. Using stacking, multiple routers can be joined into a stack, forming a big virtual router, allowing you to bond a virtually unlimited number of WAN links, and also providing hardware redundancy. Stacking is available using an optional add-on license. In addition, a new, modern web interface is now available for administration of the routers, and GPS functionality is now provided by routers (if one of our new LTE/GPS modules is used). And often requested feature now also is available: Tunnels and Channels may be assigned "Backup scores" – if your main channel goes down (say a high-capacity DSL link), the router can now bring up multiple backup channels (say two UMTS links) to compensate for that. Also, a cost value may now be assigned to channels. In this case links which have lower cost will be used first if bandwidth demand does not require all channels to be used.

We recommend all customers to update to this latest stable firmware release.

Improvements

Channels now may have backup scores, and the tunnel can have a minimum required backup score. This allows you to do setups where if one master channel goes down, multiple backup channels are brought up at the same time until the loss in "score" is compensated for. The router will bring up more backup channels until the tunnel's minimum backup score value is reached. The backup score of a channel also is multiplied with the Link stability value of the channel, which results in unstable channels not getting the full score. This way, a protection against link flapping is also provided.
Using Stacking, multiple node routers can form a stack, becoming one big router. One of the routers will be the designated master router, using the other routers who are acting as slaves. If a slave router breaks, only the channels running over the slave router will go down. If the master router breaks, a slave router will automatically become the new master. If the designated master router comes back, an automatic failback takes place. For all of this to work, the current master router is constantly synching most parts of the router configuration with the slaves. Also, the current master router carries at least one dedicated IP address in the LAN which is also taken over if another slave becomes master. This shared IP is used as the gateway in the LAN. Detailed instructions on how to setup stacking are available. Stacking requires an add-on software license to be used.
If the router is equipped with a GPS receiver (for modular router that means that you are using at least one LTE/GPS module), the router may now report its current position. With the new web interface, a Google Maps integration is also available.
Channels now have a "Cost" setting. Channels with lower cost will be preferred if not all available bandwidth is used right now. You therefore now can have e.g. ADSL channels which are cheap to take most of the load, and use UMTS/LTE channels for traffic spikes.
This feature still has issues if you define more than 2 different cost levels.
A new modern looking web interface is now optionally available in parallel to the old one. The new web interface speeds up administration of routers dramatically. For example, you can edit multiple similar objects at the same time (for example all channels of a tunnel). The new web interface requires a current web browser (IE9+, Firefox 3.6+).
In future firmware releases, we will limit the allowed characters in object names and string properties. Only the following characters will be allowed:
'a'..'z', 'A'..'Z', '0'..'9', '-', '+', '.', '_', ' ', '#', '(', ')', '/'
If you are currently using other characters anywhere (tunnel or channel names, routing rules, router names, etc), please change them. Starting with this firmware release, a warning will be put to the log every time illegal characters are used.
The reason for this change is to work against injection attacks on various levels.
User-created objects like tunnels and QoS classes now should use only about 1/4 of the memory they used before. This should allow for a much higher number of configured tunnels and QoS objects on Hubs than before.
The used root servers for the DNS service have been updated.
This release for the first time fully supports our new CDMA 450 MHz modules to be used in Northern and Eastern Europe. The support previously released in the stable firmware released in February was incomplete. Use this firmware if you want to use CDMA 450 MHz modules. *)
Highly improved LTE monitoring support, highly improved support for having multiple LTE modules in a single router. If you are using LTE, upgrade to this release. *)
Hub 1020 and 2020 are now fully supported. This firmware release is required to run 1020/2020. *)
CPU load is now monitored and reported through the web interface and SNMP. *)
Several Ethernet auto-negotiation fixes. Auto neg now works for the 500 LAN port and the Gigabit Ethernet Modules. *)
Until now, fully using the up- and downstream of a channel at the same time would overload the channel and cause high latencies because the downstream would cause ACK traffic on the upstream for the tunnel channel connection and vice versa. This is improved now. *)
Changing QoS classes that were in use (for example by executing "Copy QoS templates to here" on a running tunnel) could crash the router or cause it to get stuck. This no longer happens. *)
It was possible to get internal errors or crashes if you deleted the Default QoS class. This is fixed. In worst-case situations where the Default QoS class no longer exists, the first available class instead will be used. *)
There now is a "reconnect" function available for tunnels. *)
If a tunnel was moved from one Node to a different one, sometimes the Hub would report the error "A channel of this tunnel is already connected to a different VPN Node" even if no channel from the old node was still connected. This is now fixed. *)
If an LTE module was idle (module connected, but no tunnel channel going through it), it would first go "dormant", then disconnect, then reconnect, with this cycle going on forever. This is now fixed, LTE modules will no longer disconnect for being dormant. *)
If tunnel segmentation on the Hub was used, TCP connections that had been established coming from a tunnel on Seg 0 going to some other Segment tunnel would time out after 30 seconds if unused. This would cause for example idle SSH connections between these segments to hang. *)

*) These improvements already had been available in the "cutting edge" Firmware released in April 2013.

Bug fixes

The dreaded Internal Error Code 513791371A2237AE should be gone – it was a bug in Heuristic auto tuning.
There has been a race condition on the Hub. If two nodes would connect channels to the Hub exactly at the same time, the Hub may have entered an inconsistent state where one Channel of Node A was connected, but the Hub's tunnel believed it was connected to Node B. This caused the Node A then to not be able to connect further channels. This situation could happen in larger stacks when routers were rebooted or power-cycled, and briefly two masters existed and connected to the Hub, before detecting and resolving this split brain situation.
The CLI for setting properties only checked if the user had the permission to change a property, but did not check if the property actually supports setting or is a read-only property. Setting read-only properties could lead to all kinds of weird issues. You now no longer can modify read-only properties.
No tool in the old and new web interface required user write permissions for changes. Now all of them do.
The download test tool (old web interface only) got improved so it uses far less CPU. No more "download test aborted due to too high CPU load" messages anymore.
When re-enabling a disabled fan, on some router models the fan would not start up, as the fan speed was set too low.
During router startups CPU load is no longer monitored and reported to get rid of annoying warnings when there is nothing to warn about.
Some production runs of the 300 router have an issue where the reset button does not always work quickly. This is now solved, pressing the reset button shortly will reset the system again even on those devices.
In the module settings by CLI and new web interface in past releases you could select invalid configuration types. You no longer can.
"Expected Internet link capacity" was broken for some LTE carriers, causing internal errors and negative autotuning speed results. This is now fixed.

Firmware Release February 6th, 2013 - Version 2013012301/2013020600 (Multichannel VPN Router 500: 2012112320/2013020600)

This firmware update is based on our last Stable Release from December; it rectifies some partly very important mistakes. In addition, the new CDMA 450MHz module types are supported for the first time by this firmware release. The command line interface (CLI) is now ready for production use.

We recommend all customers to update to this stable firmware release as soon as possible. Please note that all Hubs and Routers should be updated to this release. Routers with this current firmware are able to talk to Hubs with older firmware (and vice versa), but performance may be degraded.

Improvements

This release for the first time fully supports our new CDMA 450 Mhz modules to be used in northern and eastern Europe.
Channel congestion detection is slightly changed to be more aggressive.
The CLI has been completed and is now ready for production use. A scripting toolkit to automate router administration and deployment is available on request.

Bug fixes

IMPORTANT: The previous stable firmware released on December 10th has a very dangerous bug: If you have references in the VPN & Routing object to a Tunnel, and then in the Tunnellist remove a Tunnel previous to such a referenced Tunnel, all routing references would break, potentially killing all of your routing configuration. The same happened with QoS rules references. Do not delete any Tunnels before upgrading to this firmware release!
If channels were completely idle (traffic less than 20 kbit/s for a while), they were supposed to only send the internal pings for latency and loss management every 1000ms instead of the default 100ms. This was meant to reduce idle traffic usage over expensive links like UMTS. This feature always has been broken due to a rounding error. Once you ever on a connected channel had more than 24 Kbit/s, it would never go back to this idle-traffic-saving mode. This now works as expected and will reduce idle traffic usage by a factor of 10.
In Hotspare mode, the license manager now displays a note that licenses are not checked in this mode.
A rare timer overrun on the 500 could cause short hangs of the routing.
The Ethernet info tool for the LAN interface of the 500 now actually works.
Multiple BondingTCPOptimizer bugs were fixed. Those could cause a BondingTCPOptimizer TCP connection to hang if the bottleneck in bandwidth has not been the tunnel, but on the LAN instead (e.g. if you had a traffic shaper behind a Viprinet router).
Ethernet Autonegotiation settings for Ethernet WAN Modules were not saved across reboots. This is now fixed. Known issue: Gigabit Ethernet Modules right now do not support turning off Auto Negotiation at all due to a NIC driver bug. You can only turn off Auto Negotiation for Fast Ethernet modules.
A memory leak in regards of Tunnel objects was fixed. If you created and deleted a huge number of VPN Tunnels using scripting, the router could run out of memory with previous firmware releases. This no longer happens. Also, performance of this kind of mass additions/removals has been improved.
In the previous stable firmware release, it was changed that after a big number of critical errors in the log, the router would automatically reboot. However, if one of the two redundant fans breaks, this is logged as critical error. This caused routers with a broken fan to constantly reboot every few minutes. This issue is now fixed - a single broken fan is no longer reported as critical, but as an alert. Only both fans failing is now critical.
An "invalid floating point error" could appear when using the download tool with "Measure & discard" setting.
When using e.g. plink to supply a file of commands that are to be executed via the CLI, carriage returns were ignored and no command separators existed.

Example:
plink -pw -batch -ssh -P 22 root@ -m commands.txt -v ERROR 140 ←[1m←[31mThis object does not exist←[0m

This now works with CR or CR/LF as command seperator.
The CLI now allows to delete items using their object index instead of object names only, e.g. "execute DELETEITEM OBJECT__2".
The CLI now properly supports closing the SSH connection, and closing/reopening SSH subchannels to issue multiple commands in a way that some SSH scripting toolkits (e.g. Paramiko) do it.
Multiple typos have been fixed in the web interface.
The timing of Hubs placed in a redundancy group probing to check if they are replaced on boot has been modified to be more robust.
BondingTCPOptimizer connections seeing packet loss on the WAN with unstable high-bandwidth links could, after internal retransmission of lost segments, have queued up a very big amount of packets on the LAN side (multiple megabytes). This could cause huge traffic spikes when those were released to the LAN, potentially causing problems on the LAN which could be seen on the routers as "XX packets have been dropped reading from LAN" messages. These packets will now be released more slowly to reduce these spikes.

Firmware Release December 10th, 2012 - Version 2012091701/2012121005 (Multichannel VPN Router 500: 2012112320/2012121005)

This firmware release brings a huge number of improvements to our customers. For all products, the performance and achievable throughput have been improved for various Bonding modes. There is a high number of fixes for the Multichannel VPN Router 500, which improve both stability and performance. The command line interface (CLI) while still in beta has improved a lot and now actually is usable. A scripting toolkit for the CLI will be made available soon to help with mass deployment. This release also improves real-life performance and user experience of routers used in moving vehicles a lot - you will now be able to go hour for hour without having connections through your tunnel ever getting reset, even if you go through areas where there is no mobile data signal coverage at all. We've also extended VLAN options on Multichannel VPN Hubs, and also are providing an improved set of default QoS rules.

Improvements

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.

Bug fixes

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.

Firmware Release 09/25/2012 - Version 2012091701/2012091800 (Multichannel VPN Router 500: 2012091720/2012091800)

This firmware release adds two more fixes to our major stable firmware released on September 7th. An update from that release to the current one is only required if your setup benefits from the two additional fixes:

Bug fixes

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.

Firmware Release 09/07/2012 - Version 2012081500/2012090600 (Multichannel VPN Router 500: 2012082420/2012090600)

This firmware release brings a huge number of quality and stability improvements. On the Multichannel VPN Router 500, the improvements are very significant. We recommend that all customers update all products to this firmware release.

Bug fixes

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.

Improvements

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.

Firmware Update 06/19/2012 - Version 2012061200/2012061200 (for all products other than Multichannel VPN Hub 5000 and Multichannel VPN Router 500) / 2012032610/2012061200 (for Multichannel VPN Hub 5000 and Multichannel VPN Router 500)

This is a maintenance update for the firmware released on April 13th 2012.

This update is of importance to all customers who are using SNMP monitoring with routers and for all customers using the “Passive” and “Hybrid” channel auto-tuning modes. These customers should update quickly. For all other customers, this is still a recommended update.

Bug fixes

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.

Firmware update 04/13/2012 – Version 2012032600/2012041000

The latest firmware version for the Multichannel VPN Routers and Multichannel VPN Hubs constitutes no less than a revolution of functionality. The new release offers a vast number of new features, many of which have been desperately requested by partners and customers. Moreover, the firmware contains a number of bug fixes that provide higher system stability and throughput

Changes compared to the previous cutting edge firmware release 2012020100/2012030101:

LTE modules are now supported and stable. Various issues that existed in the previous cutting edge release are now fixed, including hot-plugging issues, monitoring problems and module info errors. Hand-over between UMTS ↔ LTE now also appears to be working in real-life scenarios with moving vehicles.
Modules on the Multichannel VPN Router 500 may now be configured even while they are powered off due to the SIM card holder being opened.
On previous cutting edge firmware release 2012020100/2012030101, connections using BondingTCPOptimizer would sometimes hang on channel disconnects. This is fixed.
Due to an issue with SNMP encoding on previous cutting edge firmware release 2012020100/2012030101, you would sometimes get wrong values for 64 bit counters.
The Hub WAN link speed detection used as a parameter for channel autotuning was broken – it only detected the speed when the WAN did not have an Ethernet link. Therefore, Hubs were always reporting 0 MBit/s.
The "Enabled Mobile Technologies" was displayed for all module types. It's now only displayed for LTE modules.

Changes compared to the last stable firmware release 2011020901/2011051700:

New features:

Extended SNMP now uses its own, dedicated Viprinet MIB. To use extended SNMP, you need to have the extended SNMP feature licensed. MIB is available here: http://www.viprinet.com/downloads/viprinetmib.zip
A command line interface for the router is now available via SSH on port 22 if enabled inside the web interface. Usernames and passwords are used as defined inside the web interface. This is a beta feature; the CLI will be improved in upcoming firmware releases.
You may download the router's configuration using SFTP/SCP.
You may now view the ARP table of Ethernet devices (LAN, WAN, WAN modules) inside the web interface.
Gigabit Ethernet modules are now supported.
UMTS/HSPA, UMTS/HSPA+, CDMA and LTE modules now have a web interface tool to manually issue AT commands. This can be used for customization and activation that is required for some countries / mobile carriers.
Ethernet auto negotiation parameters may now be configured for the LAN interfaces, the WAN interfaces on Hubs and for Ethernet WAN modules.
If you have a Streaming Optimization license installed, a new bonding mode called LossyBonding is now available. This mode is optimized for bonding UDP traffic. Unlike all other bonding modes, it does not guarantee IP delivery, so there may be packet loss on the bonded tunnel. The mode uses a self-tuning dejitter buffer on the receiving side. With this mode, extremely low latencies with minimal jitter can be achieved for critical UDP traffic and applications like VoIP and live video conferencing.

Improvements:

A new set of improved QoS rules and classes are deployed with this release. To enable those, you need to use the "Restore Manufacturing Defaults" function inside the "QoS rules and classes templates" object, and then afterwards use the "Copy QoS templates to here" function in each tunnel object with which you wish to use the new QoS classes. Doing this is highly recommended. Take caution in case you have created custom QoS classes, as those would be overwritten by the copy.
Logging in with wrong username/password by HTTP or SSH now causes a random delay before returning an error. This slows down brute force password attacks.
The log format has been changed to always include the VPN tunnel name for channel messages. Until now, it was impossible to find out which tunnel a message was referring to if you had multiple tunnels using the same channel name (which is very common on shared VPN Hubs)
Huge improvements in regards to buffer management and QoS. In situations where the upstream is fully used by traffic, you now will be getting a far better performance for downstream traffic.
For test purposes, link stability checks can now be turned off using a setting inside the "Performance finetuning" object of a channel.
The number of log messages caused by the auto-tuning has been reduced.
Big autotuning improvements for bonded 3G in moving vehicles. Channels will now respond far quicker to short coverage outages, and will reestablish channels much faster. As a result, performance of Viprinet routers in moving vehicles with this firmware is highly improved.
The BondingTCPOptimizer mode had various issues with lots of TCP implementations and applications. Often, BondingTCPOptimizer connections would hang or fail, especially for SSL-based TCP connections. This has been improved a lot. We now recommend using the BondingTCPOptimizer mode for all TCP traffic going over bonded channels that have very high or unstable latencies, for example for bonding combinations of ADSL + UMTS.

Changes:

If you enable remote service connections to let Viprinet support staff access your router remotely, this now uses port 20022 (port 22 previously used in earlier firmware releases is now used by SSH CLI). Please update your firewall rules accordingly.

Bug fixes:

Several memory leaks have been fixed.
If you had 3 channels, with 2 configured as backup, it could happen that on dropout of the non-backup channels, both backup channels were set up on the same time, with both then getting shut down again because there already was a backup channel running.
Ping and Ethernet tools did not show error messages inside the web interface if hostname to test was unresolvable by DNS.
IP_IP and IP_IPV6 tunnels were not routed through the VPN tunnel but dropped.
Until now, all routers could be enabled for factory reset using the setup tool if all modules of the router were removed. This no longer works for all products which have a reset button to do a factory reset. You need to press that instead of removing modules.
If you used the 192.168.1.0/24 network on your router, ADSL modules would not work correctly anymore (internal IP address conflict). This is solved.
Under circumstances, Hub 5000 would see its own packets that it had sent to the LAN and report an "Incoming Packet from.. has incorrect TCP checksum" error message.
Ethernet broadcasts directed at an IP alias network under circumstances could result in an endless loop in routing and cause the router to drop out seeing any traffic for multiple seconds.
The maximum size of a config file backup was increased to 10 MB. Until now, with router installations with a high number of tunnels it was impossible to backup and restore the configuration.
Gratious ARP on WAN interfaces suffered from a race condition. After taking over a WAN IP address, this could make the takeover time take longer than expected with Hubs, because upstream routers did not get notified about the new MAC address for the IP at once.
The guaranteed bandwidth settings inside QoS classes did not fully work until now. The class might have gotten more or less the guaranteed bandwidth. This now works perfectly. Attention: If you have a QoS class configured that has a guarantee that's bigger than the total bonded WAN capacity, it means that your other QoS classes may not be allowed to do any traffic every time the QoS class with the guaranteed bandwidth is using the full capacity of the bonded tunnel!
If you copied a QoS class, the minimum diversity setting did not get copied over.
If on one side of a VPN tunnel channel encryption was enabled, and on the other side disabled, the log messages would not make it obvious that this is a misconfiguration, instead the channel would simply disconnect all the time. There now is a log message that makes it clear what is happening.
Pressing the reset button for factory reset did not work for Hubs that currently were running in Hotspare mode.
ADSL modules were sometimes reporting a wrong message about bandwidth capacity / sync values.
Internal early retransmissions (adjustable using the retransmission multiplier of the channel's fine-tuning settings) could lead to a "meltdown", if multiple links dropped out at the same time (for example 3x ADSL from same carrier, all lines show sudden high packet loss at the same time due to some cable interference). This could cause for not being able to transmit packets, because all channels would try to retransmit using the other channels that also want to retransmit.
Various fixes for SNMP protocol compliance and compatibility.
SNMP was using some amount of CPU per tunnel, not matter if the tunnel was active or not. For Hubs with a high number of tunnels (50+), this was causing very high CPU load and therefore bad router performance.
On the 500, there was a hidden ghost WLAN without an SSID in addition to the one configured. It was no security issue, as you could not connect to this WLAN, but irritating.
On the 500, bridging between LAN and WLAN did not work. This is now fixed; devices on the LAN can see WLAN devices and the other way round.
On the 500, switching the AP mode from 5 GHz to 2.4 GHz or back did not work until you rebooted the router.
The LAN IP configuration did allow CIDR notation, causing the interface to fail.
Hybrid and passive autotuning ignored turning off autotuning.
There have been various problems in regards to stability and throughput, if you had turned off channel encryption on the Hub 5000 product. With the 500, turning off encryption caused the channel to fail.
On Hub 5000, the maximum number of tunnel channels was limited to 200, this limit has been removed.

Known limitations:

Hub 5000 / SNMP: OID for CPULoad will return "" on Hub 5000
Hub 5000 / SNMP: Counter for tunnel channels not yet implemented (OID: 1.3.6.1.4.1.35424.1.6.2.1.9 and 1.3.6.1.4.1.35424.1.6.2.1.10)
Hub 5000: Ethernet auto negotiation parameters cannot be changed

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

Firmware update 07/22/2011 – Version 2011020901/2011062701

This is a maintenance update for the firmware released on May 11th, 2011 (Multichannel VPN Hub 1000: May 16th, 2011)

This update might be of importance to customers who are using a setup where commonly both the up- and downstream of all channels are fully used in combination with high-bandwidth links. The firmware versions released 11.05.2011/16.06.2011 might have degraded performance in these setups - the latency of the links could become much higher than in previous releases, possibly causing suboptimal throughput on the VPN tunnel level.

This has been resolved, the latencies of VPN tunnel channels are much more stable now even with high-bandwidth links.

Other than the former change, this release, which has gone through a long testing phase and is regarded the stable firmware release for the next few months, only brings some minor changes. We therefore recommend all customers to update to this firmware release

Bug fixes

The internal socket buffer tuning of tunnel channels was changed in the release from May, with the consequences outlined above. This has been optimized now, the socket buffer tuning no longer relies on the calculated Maximum Bandwidth to WAN, but instead uses the Current Bandwidth to WAN, optimizing latency for high-bandwidth links.
The log message of a VPN Hub in hot spare mode in regards to comparisons on packet loss have been corrupt. Instead of a percentage, the IP address was displayed. This has been fixed.
If you use the traffic accounting API on a Hub with a very high number of VPN tunnels, "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" messages would appear in the log, with traffic accounting entries getting lost. This is fixed, we now support a much larger backlog.
The log message "Unable to submit traffic accounting data to server with URL..." now actually does output a URL to help with debugging your own implementations based on our traffic accounting API.

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.

Firmware update 05/16/2011 – Version 2011020901/2011051700

This is an urgent update for the firmware released on 11th May 2011 for the Multichannel VPN Hub 1000. Other products are not affected.

We have to inform you that due to an error in our release and certification process, a significant error slipped through - in our firmware release for the Multichannel VPN Hub 1000, the hardware encryption acceleration was turned off. The Multichannel VPN Hub 1000, when using the firmware release 2011020901/2011051001, will show terrible performance when used with encrypted VPN Tunnel channels (which is the default).

If you have already updated your Multichannel VPN Router 1000 to the firmware release 2011020901/2011051001 last week, please immediately update again to the new release 2011020901/2011051700, which fixes this problem. There are no other changes in this firmware release.

For all other products, the issue does not exist, and the firmware release 2011020901/2011051001 is current. The releases 2011020901/2011051001 and 2011020901/2011051700 are 100% compatible to each other.

We are very sorry for any inconvenience caused. We've made sure that such an error cannot happen again in the future by again improving our release testing system.

Firmwareupdate 05/11/2011 – Version 2011020901/2011051001

This is a maintenance release bringing once again small fixes and improvements to our major release from December 2nd 2010. If you are using the "BondingTCPOptimizer" mode in your router setups, this is a critical release.

This maintenance release was designed for providing a long-time highly stable firmware version and therefore does not add new features. We recommend all customers to upgrade to this firmware release.

List of improvements and fixes:

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.

Firmwareupdate 02/25/2011 – Version 2011010901/2011022500

This is a maintenance release bringing various fixes and improvements to our major release from December 2nd 2010. This update brings various bug fixes for problems reported by customers, general performance improvements for most usage scenarios, and new features for "Streaming Optimizations" license holders. For usage scenarios where very unstable WAN links are bonded (like UMTS while on the move), the performance improvements in regards of achievable stable bandwidth are enormous.

Unless you are affected by one of the fixed bugs, it is not critical to update to this release. However, due to the performance improvements, it is still a recommended update for all customers.

List of improvements, new features, and fixes:

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.

Firmwareupdate 01/10/2011 – Version 2011010401/2011011003

This is a maintenance release bringing various fixes and improvements to our major release on December 2nd. This update also fixes an important issue introduced with the December 29th, 2010, firmware update. We recommend all customers to quickly update to this firmware release due to this. This update also introduces the option to configure static DHCP leases (and the ability to view the current lease table) as a new feature.

Hier die Änderungen im Einzelnen:

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.

Firmwareupdate 12/29/2010 – Version 2010112901/2010122800

This is a maintenace release bringing various fixes to our major release that was released on December 2nd. For many customers, this is a non-critical update. However, if you are using SNMP on your routers, the BondingTCPOptimizer mode in your QoS classes, or wish to use the DHCP relay feature, it is highly recommended to update quickly.

The following issues have been fixed:

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.

Firmware update 12/02/2010 - Version 2010112901/2010120203

New features:

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

Firmware Classic Stable

Classic Stable Firmware Release November 27th, 2015 – Version 2015081830/2015102900

New features

Bug fixes

Classic Stable Firmware Release February 25th, 2015 – Version 2014110730/2015021100

New features

Bug fixes

Classic Stable Firmware Release October 2nd, 2014 – Version 2014093030/2014100200

Bug fixes:

Classic Stable Firmware Release August 18th, 2014 – Version 2014061630/2014080100

List of changes compared to the former Stable Firmware release

New features

Bug fixes

Classic Stable Firmware Release March 6th 2014 – Version 2014021430/2014022500

New features

Bug fixes

Classic Stable Firmware Release August 12th, 2013 – ­Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)

Improvements

Bug fixes

Classic Stable Firmware Release June 24th 2013 – Version 2013051031/2013062100

Bug fixes

Classic Stable Firmware Release June 11th 2013 - Version 2013060730/2013061001

Classic Stable Firmware Release June 10th 2013 - Version 2013051031/2013061001

Bug fixes

Classic Stable Firmware Release June 6th 2013 – Version 2013051031/2013060600

Improvements

Bug fixes

Firmware Release February 6th, 2013 - Version 2013012301/2013020600 (Multichannel VPN Router 500: 2012112320/2013020600)

Improvements

Bug fixes

Firmware Release December 10th, 2012 - Version 2012091701/2012121005 (Multichannel VPN Router 500: 2012112320/2012121005)

Improvements

Bug fixes

Firmware Release 09/25/2012 - Version 2012091701/2012091800 (Multichannel VPN Router 500: 2012091720/2012091800)

Bug fixes

Firmware Release 09/07/2012 - Version 2012081500/2012090600 (Multichannel VPN Router 500: 2012082420/2012090600)

Bug fixes

Improvements

Firmware Update 06/19/2012 - Version 2012061200/2012061200 (for all products other than Multichannel VPN Hub 5000 and Multichannel VPN Router 500) / 2012032610/2012061200 (for Multichannel VPN Hub 5000 and Multichannel VPN Router 500)

Bug fixes

Firmware update 04/13/2012 – Version 2012032600/2012041000

Changes compared to the previous cutting edge firmware release 2012020100/2012030101:

Changes compared to the last stable firmware release 2011020901/2011051700:

New features:

Improvements:

Changes:

Bug fixes:

Known limitations:

Firmware update 07/22/2011 – Version 2011020901/2011062701

Bug fixes

Firmware update 05/16/2011 – Version 2011020901/2011051700

Firmwareupdate 05/11/2011 – Version 2011020901/2011051001

List of improvements and fixes:

Firmwareupdate 02/25/2011 – Version 2011010901/2011022500

List of improvements, new features, and fixes:

Firmwareupdate 01/10/2011 – Version 2011010401/2011011003

Hier die Änderungen im Einzelnen:

Firmwareupdate 12/29/2010 – Version 2010112901/2010122800

The following issues have been fixed:

Firmware update 12/02/2010 - Version 2010112901/2010120203

New features:

Classic Stable Firmware Release August 12th, 2013 – Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)