Firmware Release Notes

Our team of developers is keen to continuously improve our products. Hence, we periodically release firmware updates to not only eliminate errors and raise product quality but also provide new additional features. We base the development of new product features strongly upon our customer's feedback.


Since 2015, Viprinet uses RuggedVPN. RuggedVPN constitutes the next generation of Viprinet firmware and is regularly developed further. From the beginning of 2017, the "Classic" firmware that was used until 2015 is no longer supported. Existing installations should therefore be switched to RuggedVPN in a timely manner in order to profit from all the latest and newest features.

Online update

All our routers provide the option of a simple online update for the "stable" firmware branch in the web interface at [ AdminDesk ] [ Logging & Maintenance ] [ Router Firmware Update ]. The device will automatically check for firmware updates for this specific router model and - if applicable - download and install them. Configuration settings permit that firmware updates will be downloaded without any administrator support when available. However, the installation should always be run with an administrator present.

Offline update

As an alternative to an online update, an offline update is available. To do an offline update, please download the correct firmware image for your product and then use the manual update function inside the router's web interface to upload that image. The firmware images are available on our Update server.

If you need any help or further information concerning firmware updates, please contact our support team.

Viprinet Lifetime Maintenance

Usage of RuggedVPN firmware requires a "Viprinet Lifetime Maintenance" contract being in place. The old Classic firmware is available without having such a maintenance contract. Support for both firmware generations requires a VLM License.

RuggedVPN Stable Firmware Release October 10, 2018 - Version 2018091860/2018100300

This firmware release is bringing a number of product quality improvements and critical stability fixes for VPN Hubs. We recommend all customers to update to this release in a timely manner.

An updated firmware image will be available on Amazon AWS as soon as their approval process is finished.

If you wish to upgrade from Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be active. For more information, please check It is possible to have Routers and Hubs running on the latest version of Classic firmware connect to a device running RuggedVPN firmware. However, in this case a compatibility mode will be used, which limits performance and features. It is therefore not recommended to permanently use such a setup, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading.This is the final firmware version that still supports connecting old devices running our Classic firmware generation (2015 and prior) and upgrading from such a firmware release.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 201805236/2018070900 released on July 12 2018). 

Bug fixes

  • In the stable release 2018070900 we had prepared support for the web interface to be able to use Unicode (for localization) in the future. The implementation contains a bug that if a certain URL formatwere included in a HTTP/HTTPS request, it would make the Hub/Router silently reboot without giving any message.

  • Sadly this bug is triggered by automated exploit scans searching for web application vulnerabilities. This means that any Viprinet device which has its web interface open to the Internet (which is fine and expected) without having it protected by an ACL will be affected.This is a very critical bug. This update fixes this problem, and makes the code involved much more robust.

  • In some rare cases, updating a 51x router to the stable release 2018070900 could make it hang during the boot process. For some customers this has never happened, for some it happened on a lot of devices. The exact reasoning why this is happening only for some customers are unclear, but with those who had seen the problem we have verified the bug is fixed.

  • With the stable release the "Minimum guaranteed bandwidth/maximum allowed bandwidth" features of QoS did not longer work as expected. This is now fixed, they fully work as expected again. (Bug ticket #1391)

  • For 200/5xx routers an optimization for reading packets going to internal router services (web interface, SSH CLI) was introduced in the stable release 2018070900. This has now been removed, as CPU cache bugs were causing packet loss and reordered packets when accessing router services. From our tests we have not seen any significant impact in performance.

  • Viprinet routers contain a connection limiter making sure you can not overload the router's services with simple single-IP DoS attacks. It makes sure only a certain amount of connections per IP can be established per service. However, in the 2018070900 stable release this was broken on two counts: For HTTP/HTTPs and SSH the limit was not enforced at all.

  • But there was another bug that was present for a long time already: If at any given moment any single IP had hit the maximum connection limit on a service, this service would die and no longer respond to anyone. This was the case for example for the VPN WAN interface on Hubs - if a single IP once managed to open 100 concurrent HTTPs connections (which is hard to do), no channel would be able to connect to the Hub's WAN port until the Hub was rebooted.

    Executive summary: both bugs are resolved. In addition, we have lowered the maximum number of concurrent established connection from a single IP for the following services

    • Web interface: 25
    • VPN Channels: 25
    • SSH Connections: 3
    • (all of this is per-IP!)

  • The code that decided on how many concurrent WAN Optimizer connections to allow was basing it decision on how much free RAM was left on a router. However, it did not take into account that RAM it already uses itself should also be counted as "free". This caused a router after running for a long time or having used a lot of WAN Optimizer connections to reduce the maximum allowed WAN Optimizer connections, effectively resulting in at some point the WAN Optimizer hardly being used at all anymore.

  • The TCP Option 254 originally used for RFC3694-style experiments according to IANA is illegal and should not be used, however customers have reported that they have broken equipment in their network that improperly uses this option in shipping products. We therefore are now allowing this TCP Option as requested by a partner.

  • If you had flapping channels on a Hub (channels constantly reconnecting), this would cause a small memory leak that over time would grow large until the Hub ran out of memory. (Bug ticket: #1399: Memory leak with flapping channels)

zum Anfang