Firmware Release Notes

Unser Entwicklungsteam ist kontinuierlich bemüht, unsere Produkte zu verbessern. Für unsere Router erscheinen daher regelmäßig Firmwareupdates, die nicht nur Fehler beheben und die Produktqualität verbessern, sondern oft auch zusätzliche, neue Features enthalten. Bei der Entwicklung neuer Produktfeatures richten wir uns dabei stark nach Kundenfeedback.

RuggedVPN

Seit 2015 setzt Viprinet auf RuggedVPN. RuggedVPN stellt die nächste Generation der Firmware dar und wird kontinuierlich weiterentwickelt. Die bis 2015 verwendete "Classic"-Firmware wird hingegen seit Anfang 2017 nicht mehr unterstützt. Bestehende Installationen sollten daher zeitnah auf RuggedVPN umgestellt werden, damit sie von allen neu entwickelten Features profitieren.

Online Update

Unsere Router enthalten im Web-Interface unter [ AdminDesk ] [ Logging & Maintenance ] [Router Firmware Update] die Möglichkeit, ein bequemes Online-Update eines "Stable"-Firmware-Releases durchzuführen. Hier kann automatisch geprüft werden, ob für das Routermodell ein Firmware-Update vorliegt, dieses ggf. heruntergeladen und installiert werden. Es kann auch konfiguriert werden, dass Firmware-Updates ohne Zutun des Administrators bei Verfügbarkeit heruntergeladen werden. Die Installation sollte aus Sicherheitsgründen aber immer in Anwesenheit eines Administrators durchgeführt werden. Das Online Update ist sowohl für die Classic- als auch die RuggedVPN-Firmwaregenerationen verfügbar. In der Classic-Firmware existiert eine gesonderte Option, um den Router auf RuggedVPN upzugraden.

Offline update

Als Alternative zum Online-Update steht auch ein Offline-Update zur Verfügung. Um ein Offline-Update durchzuführen, müssen Sie das für Ihr Routermodell bestimmte Firmware-Image herunterladen und dann über die entsprechende manuelle Updatefunktion im Web-Interface des Routers hochladen und installieren. Die Firmware-Images sind auf unserem Update-Server verfügbar.

Sollten Sie Hilfe beim Firmware-Update benötigen, so wenden Sie sich bitte vertrauensvoll an unseren Support.

Viprinet Lifetime Maintenance

Die Nutzung der RuggedVPN Firmware erfordert einen laufenden "Viprinet Lifetime Maintenance"-Vertrag. Die alte "Classic"-Firmware ist hingegen noch ohne einen solchen Wartungsvertrag verfügbar. Supportunterstützung hingegen erfordert in jedem Falle einen VLM-Vertrag.

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

Diese Firmware-Version bringt eine Reihe von Verbesserungen der Produktqualität sowie kritische Stabilitätskorrekturen für VPN-Hubs. Wir empfehlen allen Kunden, zeitnah auf diese Version zu aktualisieren.

Sollten Sie von einer älteren Classic-Firmware umsteigen wollen, müssen Sie zunächst Ihren Router auf die letzte Classic-Firmware (Version 2015081830/2015102900, veröffentlicht am 27. November 2015) aktualisieren. Anschließend steht das Upgrade auf RuggedVPN zur Verfügung. Bitte beachten Sie, dass ein Upgrade der Firmware von Classic zu RuggedVPN eine aktivierte und installierte Viprinet Lifetime Maintenance Lizenz erfordert. Weitere Informationen hierzu erhalten Sie unter https://www.viprinet.com/vlm. Router und Hubs, die die letzte Version der Classic-Firmware verwenden, können zu Routern und Hubs verbinden, die mit RuggedVPN-Firmware laufen. Allerdings wird in diesem Fall ein Kompatibilitätsmodus verwendet, der den „kleinsten gemeinsamen Nenner“ verwendet und daher keine gute Performanz oder Features liefert. Ein solches Setup sollte also nicht dauerhaft, sondern nur während einer Migrationsphase verwendet werden. Der Software VPN Client ist derzeit verfügbar mit einem Kern, der entweder auf Classic- oder auf RuggedVPN-Firmware basiert. Beide Versionen werden weiterhin unterstützt, wir empfehlen aber den Einsatz des RuggedVPN-Clients.

Folgend eine Auflistung aller neuen Funktionen und Bugfixes im Vergleich zur vorherigen stabilen RuggedVPN Firmware Version (Version 201805236/2018070900 vom 12. Juli 2018):

Bug fixes

  • In der stabilen Version 2018070900 hatten wir die zukünftige Unterstützung für die Weboberfläche vorbereitet, um Unicode (zur Lokalisierung) nutzen zu können. Die Implementierung enthält einen Fehler, der dazu führt, dass der Hub/Router neu gestartet wird, ohne eine Meldung zu geben, wenn ein bestimmtes URL-Format in einer HTTP/HTTPS-Anfrage angegeben wird.

  • Leider wird dieser Fehler durch automatisierte Exploit-Scans ausgelöst, die nach Schwachstellen in Webanwendungen suchen. Das bedeutet, dass jedes Viprinet Gerät, dessen Webinterface von dem Internet aus erreichbar ist (was in Ordnung und zu erwarten ist), ohne dass es durch eine ACL geschützt ist, betroffen sein wird. Dies ist ein sehr kritischer Fehler ist. Dieses Update behebt dieses Problem und macht den beteiligten Code wesentlich robuster.

  • In einigen seltenen Fällen könnte die Aktualisierung eines 51x-Routers auf die stabile Version 2018070900 dazu führen, dass er während des Bootvorgangs hängt. Dieser Fehler ist nicht bei allen Kunden aufgetreten. Wir konnten jedoch bei den Kunden, die Probleme damit hatten, verifzieren das mit der neuen Version dieser Fehler nicht mehr auftritt.

  • Mit dem stabilen Release funktionierten die Funktionen "Minimum guaranteed bandwidth/maximum allowed bandwidth" von QoS nicht mehr wie erwartet. Dies ist nun behoben. (Bug-Ticket #1391)

  • Für 200/5xx Router wurde mit dem stabilen Release 2018070900 eine Optimierung zum Lesen von Paketen an interne Routerdienste (Webinterface, SSH CLI) eingeführt. Dies wurde nun entfernt, da CPU-Cache-Bugs zu Paketverlusten und Neuordnung von Paketen beim Zugriff auf Routerdienste führten. Bei unseren Tests haben wir keine signifikanten Auswirkungen auf die Leistung festgestellt.

  • Viprinet-Router enthalten einen Verbindungsbegrenzer, der sicherstellt, dass Sie die Dienste des Routers nicht mit einfachen Einzel-IP-DoS-Angriffen überlasten können. Es stellt sicher, dass nur eine bestimmte Anzahl von Verbindungen pro IP pro Dienst aufgebaut werden kann. In der stabilen Version 2018070900 war dies jedoch in zweifacher Hinsicht unvollständig: Für HTTP/HTTPS und SSH wurde das Limit überhaupt nicht durchgesetzt.

  • Ein weiterer bereits seit längerem bekannte Fehler wurde behoben: Wenn zu einem Zeitpunkt eine einzelne IP die maximale Verbindungsgrenze für einen Dienst erreicht hätte, würde dieser Dienst abstürzen. Dies war beispielsweise bei der VPN-WAN-Schnittstelle auf Hubs der Fall - wenn es einer einzelnen IP einmal gelang, 100 gleichzeitige HTTPS-Verbindungen zu öffnen (was sehr unwahrscheinlich ist), konnte kein Channel mehr eine Verbindung zum WAN-Port des Hubs herstellen, bis der Hub neu gestartet wurde. Beide Fehler sind behoben. Darüber hinaus haben wir die maximale Anzahl der gleichzeitigen Verbindungen von einer einzigen IP für die folgenden Dienste reduziert:

    (Jeweils pro IP)

    • Weboberfläche: 25
    • VPN-Kanäle: 25
    • SSH Verbindungen: 3
  • Der Code, der darüber entschied, wie viele gleichzeitige WAN-Optimiererverbindungen erlaubt sein sollten, basierte auf der Entscheidung, wie viel freier RAM auf einem Router übrig blieb. Es wurde jedoch nicht berücksichtigt, dass RAM, welcher durch den WAN Optimizer bereits selbst alloziiert wird, auch als "frei" gezählt wird. Dies führte dazu, dass ein Router nach längerem Betrieb oder nach vielen WAN-Optimiererverbindungen die maximal zulässigen WAN-Optimiererverbindungen reduzierte, was dazu führte, dass der WAN-Optimizer kaum noch genutzt wurde.

  • Die TCP-Option 254, die ursprünglich für Experimente nach RFC3694-Stil gemäß IANA verwendet wurde, sollte nicht verwendet werden, jedoch haben Kunden berichtet, dass sie Geräte in ihrem Netzwerk haben, die diese Option verwenden. Wir erlauben daher diese TCP-Option nun auf Wunsch eines Partners.

  • Wenn Sie Channel haben, die ständig neu verbinden, würde dies zu einem kleinen Speicherleck führen, das mit der Zeit groß werden würde, dass sich der Speicher eines Hubs füllt. (Bug-Ticket: #1399: Speicherleck mit neu verbindenden Kanälen).

zum Anfang