Firmware RuggedVPN

RuggedVPN Stable Firmware Release 21. Dezember 2018 – Version 2018091860/2018111900

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.


Ein aktualisiertes Firmware-Image wird auf Amazon AWS verfügbar sein, sobald der AWS-Genehmigungsprozess abgeschlossen
ist.


Wenn Sie von einer Classic-Firmware upgraden möchten, aktualisieren Sie bitte zuerst den Router auf die letzte stabile
Classic-Firmware-Version (Version 2015081830/2015102900 vom 27. November 2015). Bitte berücksichtigen Sie, dass
für die Aktualisierung Ihrer Firmware von Classic auf RuggedVPN eine Viprinet Lifetime Maintenance Lizenz erforderlich
ist. Weitere Informationen finden Sie unter https://www.viprinet.com/vlm. Es ist möglich, Router und Hubs auf der
neuesten Version der Classic-Firmware mit einem Gerät mit RuggedVPN-Firmware zu verbinden. In diesem Fall wird
jedoch ein Kompatibilitätsmodus verwendet, der die Leistung und den Funktionsumfang einschränkt. Es wird daher
nicht empfohlen ein solches Setup dauerhaft in der Produktion zu verwenden, aber es ist in Ordnung, wenn ein Classic-
Firmware-Gerät mit einem RuggedVPN-Firmware-Gerät spricht während Sie diese Geräte aktualisieren. Der Software
VPN Client ist sowohl auf Basis der Classic Firmware als auch alternativ auf Basis der RuggedVPN Firmware Generation
erhältlich. Dies ist die letzte Firmware-Version, die noch Verbindungen zu alten Geräten mit unserer Classic-Firmware-
Generation (2015 und älter) sowie einem Upgrade von einer solchen Firmware-Version unterstützt.


Die folgende Liste listet alle neuen Funktionen und Fehlerbehebungen im Vergleich zur vorherigen stabilen RuggedVPNFirmwareversion
(Version 2018091860/2018100300 vom 10. Oktober 2018) auf.

Fehlerbehebungen

  • Falls die lokale Ausgabebandbreite einer WAN-Optimizerverbindung auf null fallen würde, hat der WAN-Optimierer
    die entfernte Seite nicht benachrichtigt, das Senden einzustellen - dadurch konnte auf Empfängerseite das RAM
    gefüllt werden, was den Router zum rebooten bringen konnte.
  • "HUGE"-Debugmeldungen entfernt. Diese haben in einigen Installationen die Log-Dateien überfluteten, was zu
    vielen Kopfschmerzen führte.
  • Ein ARP-Problem auf der WAN-Schnittstelle des Hubs wurde behoben. Wenn jemand eine defekte Switch-
    Konfiguration hatte, konnte dies dazu führen, dass die WAN-Schnittstelle eines Hubs nach einem Neustart oder IPWechsel
    für lange Zeit nicht erreichbar war. Dieser Fix ist keine Einladung, weiter nicht spezifizierte ARP-Cache-
    Timeouts auf Switches zu verwenden.
  • Wenn einem Multichannel VPN Router 300 der RAM-Speicherplatz ausgeht, startet er neu. Vor dem Neustart würde
    er ein Crash-Log auf den Flash-Speicher schreiben. Es stellte sich heraus, dass aufgrund des Alters der
    Flashbausteine manchmal der Flash-Schreibzug bis dahin nicht abgeschlossen wird. Dies kann dazu führen, dass
    der Flashbaustein ausfällt. Dieser Fix sollte dies verhindern. Denken Sie jedoch daran: Bei älteren 300ern ist der
    Flash-Chip nun über 10 Jahre alt und hat damit seine typische mittlere Zeit vor dem Ausfall längst überschritten.
    Wir empfehlen daher dringend, die 300er Router zu ersetzen.

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

RuggedVPN Stable Firmware Release 12. Juli 2018 – Version 201805236/2018070900

Diese Firmware-Version ist ein Durchbruch: Nach drei Jahren Arbeit ist nun endlich wieder eine brandneue und stark verbesserte WAN-Optimierung verfügbar. Diese ist viel kompatibler, schneller und stabiler als die erste Version vor einem Jahrzehnt. Welche Verbindung auch immer Sie haben, sei es gebündeltes LTE, verlustbehaftetes DSL oder sogar Satellit: Unsere neue Firmware funktioniert besser denn je.

Darüber hinaus finden Sie unten aufgelistet eine Vielzahl an Fehlerbehebungen und Verbesserungen, die diese Firmware mit sich bringt. Diese Version enthält auch ein sehr wichtiges Update für Sie, wenn Sie Virtual Hubs einsetzen. Bitte beachten Sie, dass diese Firmware-Version IPv6 NICHT vollständig unterstützt. Lesen Sie die folgenden Release Notes bitte im Hinblick auf beide Aspekte.

Ein aktualisiertes Firmware-Image wird auf Amazon AWS verfügbar sein, sobald der AWS-Genehmigungsprozess abgeschlossen ist.

Wenn Sie von einer Classic-Firmware upgraden möchten, aktualisieren Sie bitte zuerst den Router auf die letzte stabile Classic-Firmware-Version (Version 2015081830/2015102900 vom 27. November 2015). Bitte berücksichtigen Sie, dass für die Aktualisierung Ihrer Firmware von Classic auf RuggedVPN eine Viprinet Lifetime Maintenance Lizenz erforderlich ist. Weitere Informationen finden Sie unter https://www.viprinet.com/vlm. Es ist möglich, Router und Hubs auf der neuesten Version der Classic-Firmware mit einem Gerät mit RuggedVPN-Firmware zu verbinden. In diesem Fall wird jedoch ein Kompatibilitätsmodus verwendet, der die Leistung und den Funktionsumfang einschränkt. Es wird daher nicht empfohlen ein solches Setup dauerhaft in der Produktion zu verwenden, aber es ist in Ordnung wenn ein Classic-Firmware-Gerät mit einem RuggedVPN-Firmware-Gerät spricht während Sie diese Geräte aktualisieren. Der Software VPN Client ist sowohl auf Basis der Classic Firmware als auch alternativ auf Basis der RuggedVPN Firmware Generation erhältlich. Dies ist die letzte Firmware-Version, die noch Verbindungen zu alten Geräten mit unserer Classic-Firmware-Generation (2015 und älter) sowie einem Upgrade von einer solchen Firmware-Version unterstützt.

Die folgende Liste listet alle neuen Funktionen und Fehlerbehebungen im Vergleich zur vorherigen stabilen RuggedVPN-Firmwareversion (Version 2017102440/2018041200 vom 24. März 2018) auf.

Neue Funktionen

  • Die WAN-Optimierung ist optional in den QoS-Einstellungen verfügbar. Wenn Sie Ihre QoS Templates auf die Werkseinstellungen zurücksetzen, steht Ihnen ein neuer Satz von QoS-Klassen einschließlich der WAN-Optimierungsfunktion zur Verfügung, die Sie Ihren Tunneln zuweisen können.
  • Die Download-Testfunktion hat einen neuen Parameter „delay”, mit dem man zwischen dem Senden des HTTP-Headers und den eigentlichen Daten für einige Sekunden warten kann – nützlich, um lang anhaltende Leerlaufverbindungen zu simulieren.
    ​Wie hier dargestellt: wget –„O NUL http://192.168.200.1/exec?module=download&delay=10”.
  • Die Option „Routeback” in den LAN-Einstellungen hat jetzt eine Option zum Deaktivieren des Loggings, um Log-Spam zu verhindern.

Bug Fixes

  • Da sowohl die Virtualisierungs-Hypervisoren als auch die Linux-Kernel-Entwickler versuchen, einen Fehler bei der Weitergabe einer virtuellen Maschinenidentität an das Gastbetriebssystem zu beheben, könnte das Gerät nach einem Firmware-Update auf unterschiedlichen Hypervisoren in eine „Identitätskrise” geraten – die Instanz wird sich mit einer anderen Hardware-ID identifizieren, die nicht der virtuellen Hub-Lizenz entspricht.
    Wir hoffen, dieses Problem mit diesem Update zu beheben. Wir haben dies mit der neuesten Version von VMWare und KVM getestet, aber wenn Sie Virtual Hubs betreiben, überprüfen Sie dies bitte dringend nach einem Update.
  • Fragmentierte Pakete werden jetzt auch mit dem Paket-Erfassungstool erfasst.
  • LTE Band 8 wurde freigegeben für 4.5G Europa/Amerika.
  • Performance-Probleme bei IP-Fragmentierung auf 200/5xx wurden behoben.
  • Es wurde korrigiert, dass das System in einer Neustartschleife stecken bleibt, wenn mehr als 256 Routen erstellt werden.
  • Ein interner Fehler 9323AA44382D201D bei leeren WLAN-Channellisten wurde behoben.
  • Es gibt jetzt eine große und komplexe Lösung für FEC:
    Das erste Problem bestand darin, dass FEC als eine „minimale garantierte Redundanz für das System" gedacht war. Das macht Sinn für Parität, aber für die Paketverdopplung nicht.
    Die Logik war in etwa „Wenn ich 4 Kanäle will, und habe in der Regel 4 Kanäle angeschlossen und die QoS Bedürfnisse stimmen überein, aber im Moment können nur drei davon verwendet werden, dann bedeutet das, dass wir die maximal verfügbare Bandbreite erreicht haben und nichts tun können“.
    Es stellte sich heraus, dass die Geschwindigkeitstests, welche nach dem Wiederaufbau des Kanals stattfanden, genau dieses Szenario verursacht haben – alle Kanäle sind vorhanden, aber in dem wiederaufgebauten Kanal wird die gesamte potenziell verfügbare Bandbreite durch die Geschwindigkeitstests genutzt.
    Die Logik wurde nun geändert: Für die Parität ist es immer noch „dies ist das Minimum, das wir garantieren“, während dies für Verdoppelung und höher egal ist – solange wir einen Kanal übrig haben, schicken wir. Dies bedeutet, dass eine potenzielle QoS-Klasse, die viel Traffic macht, eine Duplizierungs Klasse verhindern könnte und somit nur einen einzelnen Kanal verwendet. Wir denken immer noch, dass es intuitiver ist als bisher, und diese Begrenzung kann durch Bandbreitengarantien gelöst werden.
    Außerdem haben wir die Situation behoben, dass ein Geschwindigkeitstest den gesamten Traffic eines Kanals wegnehmen kann, und nicht viel User Traffic erlaubt (und keinen bei Duplikaten und höher).
  • ICMP-Zeitüberschreitungen, die durch eine Routing-Schleife verursacht wurden, können selbst eine Routing-Schleife verursachen, was zu einem Packet Storm führt.
  • ICMP-Probleme wurden behoben, so dass man den Viprinet-Hop bei einem Traceroute wieder sieht.
  • Es gab viele Optimierungen für 5xx Durchsatz/CPU-Last.
  • Ein fester CPU-Temperatursensor für 50X0 wurde implementiert.
  • Ein interner Fehler BEF3238723CD2983 wurde behoben.
  • Ein langjähriger Fehler in RuggedVPN (war schon immer vorhanden) wurde behoben, der in seltenen Fällen auftreten konnte, wenn mehrere Kanäle genau den gleichen Score hatten, jedoch immer nur einer von ihnen verwendet wurde.
  • Der HTTP-Server deklariert nun korrekt die Zeichenkodierung (UTF8 / Ansi) für jede Art von Textdatei (html, js, css etc.). Dies dient zur Vorbereitung für eine vollständig Unicode-fähige Weboberfläche, die mehrsprachig lokalisiert werden kann. Bitte melden Sie auffällige Kodierungs- und Zeichenfehler.
  • WLAN-AP-Konfigurationsbereiche wurden repariert und sind jetzt mit Toughlink auswählbar.
  • Das Problem „HTTP-Server frisst durchgehend 100% der CPU” wurde behoben.
  • Der „Kein Gratuitous ARP bei Stacking Failover”-Fehler sollte behoben sein.
  • Das Problem, das zu einem internen Fehler „137239A239232341 / Map Size HUGE“ führte, wurde behoben. Dies ist interessant: Wenn Sie NICHT Guaranteed Delivery und auch NICHT den WANoptimizer verwendet haben, konnte jeder Flow im Laufe der Zeit ein paar Bytes an Speicher verbrauchen, bis der Fluss beendet ist. Wenn Sie SEHR lange Verbindungen hatten (z.B. ein VPN-Tunnel durch den VPN-Tunnel), und/oder Verbindungen, die eine lange Zeit mit sehr kleinen Paketen (z.B. SIP-Trunk) liefen, konnte die Speichermenge des Geräts tatsächlich eine Rolle spielen. Ausserdem wurde mehr CPU verbraucht, je länger dieser Flow dauerte.
  • Alle Gratuitous ARPs werden nach 5 Sekunden wiederholt, falls der erste aus irgendeinem Grund verloren geht. Dies behebt ein Problem mit ARP auf Stacked Nodes.

Bekannte Probleme

  • Wir sind nicht zufrieden mit dem maximalen Bündelungsdurchsatz der Modelle 2610 und 2620. Dies wird sich mit der nächsten Firmware-Version deutlich verbessern. Wenn Sie daran interessiert sind, eine Beta auszuprobieren, lassen Sie es uns bitte wissen.
  • Die IPv6-Support hatte viele wirklich schlimme Fehler, von denen einer eine sehr hohe CPU-Last verursachen konnte. Um ehrlich zu sein, der IPv6-Support ist seit Dezember letzten Jahres fehlerhaft. Da sich niemand über die letzten beiden Stable Releases beschwert hat, gehen wir davon aus, dass dieser Fehler für unsere Kunden kein großes Problem ist. Für diese Stable-Version haben wir daher den problematischsten IPv6-Traffic eingestellt. Nach dieser Stable-Version werden wir die IPv6-Unterstützung wieder aktivieren, nachdem wir die Fehler behoben haben. Wenn jemand von Ihnen daran interessiert ist, IPv6-Setups zu testen, lassen Sie es uns wissen.
  • Wenn Sie sowohl WAN-Optimierung- als auch Nicht-Wan-Opt-Verbindungen in einer QoS-Klasse nutzen (etwa wenn WAN-Opt in der QoS aktiviert ist, aber dieselbe Klasse für UDP verwendet wird), kann es zu einem Einbruch des Nicht-Wan-Opt-Traffics kommen. Bitte versuchen Sie, UDP- als auch TCP-Datenverkehr in unterschiedlichen QoS-Klassen zu halten.
  • Möglicherweise gibt es Probleme bei Anwendungen mit fester Bandbreite (Videostreams), die den WANoptimizer verwenden. Bitte melden Sie sich, sollten Sie welche sehen.
  • Modell 300 ist sehr speicherarm. Wenn Sie die Firmware nach der Verwendung dieser Version aktualisieren/downgraden möchten, müssen Sie zuerst das Gerät neu starten, um genügend Speicherplatz freizugeben. Im Allgemeinen ist der WANoptimizer auf dem 300 aufgrund des geringen Arbeitsspeichers nur bedingt einsetzbar. Wir empfehlen dringend, eines unser 300-zu-310 Trade-In-Angebote zu nutzen und das veraltete Gerät einzutauschen.
  • Modelle 200 und 5xx: Wenn Sie versuchen, integrierte Dienste (Web-Interface, Ping zu LAN IP, CLI usw.) zu erreichen, werden Sie Paketverlust und/oder hohe Ping-Zeiten sehen, wenn der Router im Leerlauf ist. Wenn der Router arbeitet, verschwindet das Problem.
    Dies ist ein Nebeneffekt der Leistungsoptimierung des WANoptimizers für diese Produkte und lässt sich nicht einfach beheben. Das Problem bleibt daher für diese Version zunächst so bestehen und wird im folgenden Beta-Zyklus behoben.
    ​In der Praxis sollte dies jedoch kein großes Thema darstellen, allerdings kann es Ihre Überwachungssysteme verwirren (in unserem Fall hat der Fehler einen automatisierten Test verfälscht, bei dem einem CLI-Login an einem inaktiven Router durchgeführt wurde).

RuggedVPN Stable Firmware Release 24. April 2018 – Version 2017102440/2018041200

Zusätzlich zu unserem wunderschönen Stable Release aus Februar bringt diese Firmware-Version einige wichtige Fehlerbehebungen, die von unseren Partnern angefragt wurden.

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.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2017102440/2018020600, veröffentlicht am 13. Februar 2018).

Bitte beachten Sie, dass dieses Stable Release noch keine WAN-Optimizer-Funktion beinhaltet. Eine dedizierte Beta-Firmware mit WAN-Optimizer kann über unseren Support und die Betatester-Mailingliste bezogen werden.

Fehlerbehebungen

  • Mehr als 256 Routen konnten dazu führen, dass die dynamische Routing-Engine und der Router-Start fehlschlugen.
  • Ein Fehler wurde behoben, der dazu führen konnte, dass Router alle 24 Tage neu gestartet wurden.
  • Ein Problem mit dem dynamischen Routing, das beim Start zufällig auftrat, wurde behoben.
  • WAN-Module blieben manchmal im „Disconnecting“-Zustand stecken, zumeist in Verbindung mit VDSL. Dieses Problem wurde behoben.

RuggedVPN Stable Firmware Release 13. Februar 2018 – Version 2017102440/2018020600

Diese Firmware-Version bringt zwei neue Funktionen mit sich, die von vielen unserer Partner angefragt wurden. Sie enthält auch zwei sehr wichtige Sicherheitskorrekturen, daher empfehlen wir dringend, alle Installationen sofort 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.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2017102440/2017120100, veröffentlicht am 6. Dezember 2017).

Neue Funktionen

  • VPN Bypass ist da!
    Dies ermöglicht es Ihnen, Traffic-Regeln zu erstellen, die nicht auf einen Tunnel zeigen, sondern direkt auf das Modul, wo der Verkehr auf die IP des Moduls geNATtet wird.
    Gehen Sie zu WAN/VPN Routing-Regeln, aktivieren Sie „Allow VPN Bypass Routing“, richten Sie einige Routing-Regeln ein, die auf ein Modul zeigen, und genießen Sie.
    Bitte beachten Sie, dass diese Funktion nur in Ausnahmefällen genutzt werden sollte – z.B. wenn sich hinter einem Ethernet WAN-Modul ein DSL-Router mit integriertem VoIP-Gateway befindet, den Ihre Telefone erreichen müssen. Denken Sie daran, dass die Verwendung des WAN-Moduls direkt für den Internet-Verkehr so ziemlich jeden Zweck zunichtemacht, für den Viprinet-Router geschaffen wurden (Sicherheit, Redundanz, reich und berühmt werden, usw.).
    Es gibt auch das „Modul Browsing Tool“ innerhalb der WAN-Modul-Objekte, wenn Sie nur vorübergehend ein Modul nutzen wollen, um ein Captive-Portal auszufüllen.
  • Sie können nun DNS A-Einträge des integrierten DNS-Servers hinzufügen und verwalten. Damit können Sie Hosts wie „mycomputer.local“ konfigurieren und diese für alle Rechner, die den DNS-Server des Routers verwenden, auf eine IP auflösen.

Fehlerbehebungen

  • Durch wiederholte Fluten von Scans für den TLS ROBOT-Angriff konnten Hubs/Router zum Absturz gebracht und neu gestartet werden.
    Wir haben jetzt die Cipher-Suiten aktualisiert, die verwendet werden, um den Austausch von RSA-Schlüsseln vollständig zu deaktivieren, wie es als Best Practice empfohlen wird.
    Damit haben wir die Kompatibilität für alle Viprinet Classic-Firmware-Geräte mit einer Firmware älter als 2015 entfernt, die mit einem aktualisierten Hub verbunden sind.
    Sie werden auch nicht mehr in der Lage sein, das Webinterface mit HTTPS mit sehr veralteten Browsern wie IE unter Version 11 zu verwenden.
    Wir haben auch den VPN-Tunnel-Code im Hinblick auf zukünftige TLS-Angriffe gestärkt.
  • Es war möglich, einen DoS-Angriff gegen den Router durchzuführen, indem man viele Verbindungen gegen die SSH-Ports öffnete, dann die SSH-Sitzung auf der SSH-Protokollschicht schloss und gleichzeitig die SSH-TCP-Verbindung offen hielt.
  • Aufgrund einer Timer-Desynchronisation konnte es vorkommen, dass Router mit der vorherigen Firmware-Version nach 24 Tagen Betriebszeit neu gestartet wurden, während die Meldung „Routing core stuck“ angezeigt wurde.
  • Wenn ein Stacked Setup mit einem Hub verbunden war und der Master neu startete, übernahm der Slave. Aber wenn der Master zurückkam und den Kanal neu aufbaute, konnte man am Hub sehen, dass der Kanal des Slaves manchmal im Zustand „Disconnecting“ hängen blieb, bis der Hub neu gestartet wurde. Dies wurde verursacht durch den “A split brain situation has occured on the remote stacking Node, channel will be disconnected”-Fehler.
  • Probleme mit der Aktivierung von VPN-Clients auf virtuellen Hubs wurden behoben.
  • In sehr seltenen Fällen können DSL-Module aufgrund von Kommunikationsproblemen zwischen Router und Modul stecken bleiben. In diesem Fall schaltet sich das Modul nun automatisch aus und wieder ein. Hier gibt es noch bekannte Probleme, an denen wir arbeiten. Sollten irgendwelche Ihrer Module im Zustand „Disconnecting“ steckenbleiben, wenden Sie sich bitte an unser Support-Team.
  • Korrekte dauerhafte Behebung der Meldung „Veraltete Firmware“. Die Meldung erscheint nun immer ein Jahr nach Erscheinen der Firmware.
  • Beim Stacking gab es oft Probleme mit der ARP-Auflösung für LTE-Module, wodurch diese für den Stacking-Master unbrauchbar wurden.
  • Eine ganze Reihe von Problemen mit der Art und Weise, wie die Router mit der IP-Fragmentierung umgehen, wurde behoben. Dies hilft allen Kunden, die fragmentierte IP-Pakete verwenden (z.B. IPSec-Tunnel durch den Viprinet VPN-Tunnel, einige Audio/Video-Codecs). Bitte beachten Sie, dass IP-Fragmentierung immer noch nicht empfohlen wird, weil sie die Performance beeinträchtigt. Sie sollten jede IP-Fragmentierung, die Sie in Ihrem Netzwerk haben, so weit wie möglich beheben, indem Sie die IP-Nutzlastgröße an die MTU Ihres Netzwerks anpassen.

RuggedVPN Stable Firmware Release 6. Dezember 2017 – Version 2017102440/2017120100

Diese Firmware-Version bringt eine Vielzahl von Verbesserungen in Bezug auf Stabilität und Qualität mit sich. Diese Version konzentriert sich zudem auf umfangreiche Verbesserungen der Web-Konfigurationsschnittstelle und die Unterstützung von LTE-Modulen.

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 noch 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.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2017081640/2017082100, veröffentlicht am 23. August 2017):

Neue Funktionen

  • UMTS- und LTE-Module verwenden jetzt eine brandneue APN-Datenbank, die auf der IMSI-Reihe der SIM basiert. Das bedeutet, dass wir nun zwischen den Netzwerk-Resellern unterscheiden können – so werden die „Tchibomobil“-SIMs auf O2 nun ihre eigene APN verwenden, anstelle der von O2. Die Datenbank wird immer aktuell gehalten. Fällt das neue System aus, wird auf die alte MCC/MNC-basierte APN-Erkennung zurückgegriffen.
  • Drastisch reduzierter Speicherverbrauch sowohl auf Hubs als auch auf Nodes.
  • Der LAN-Durchsatz auf Hubs wurde drastisch erhöht. Selbst wenn ein Hub mehr konnte, konnte er in früheren Releases maximal nur etwa 250 MBit/s aus dem LAN lesen. Jetzt liest er wieder 2 Gbit/s.
  • Massive Verbesserung des Bündelungsdurchsatzes bei den meisten Produkten. Wir haben jetzt Spitzenbündelungsdurchsätze von >200 Mbit/s auf einem 310 gesehen.
  • Unterstützt jetzt das neue LTE-A 4.5G APAC Modul.
  • Alle neueren LTE-Module sind nun in der Lage, die IP-Adresse beim Connect wesentlich schneller als bisher zu erfassen.

Verbesserungen bei der Web-Oberfläche

  • Mit dem Packet Capture Tool können Sie nun an verschiedenen Stellen PCAP-Dateien des Datenverkehrs live betrachten oder herunterladen.
  • In den Web-Interface-Sammlungen können Sie nun nicht nur neue Elemente hinzufügen, sondern auch einfügen. Wenn Sie „Einfügen“ verwenden, während Sie sich im Sammelobjekt befinden („Tunnels“), wird das Objekt oben eingefügt. Wenn Sie einen Punkt („WurstTunnel“) ausgewählt haben, wird der neue Punkt davor eingefügt.
  • In Sammlungen können Sie nun Elemente ganz nach oben und ganz nach unten verschieben, anstatt nur Zeile für Zeile.
  • Tunnelobjekte können nun verschoben und neue Tunnel eingefügt werden, anstatt sie nur hinzuzufügen.

Fehlerbehebungen

  • Das Release enthält verschiedene Korrekturen und Änderungen an der Funktionsweise von FEC und Kanalauswahl.
  • Es enthält auch verschiedene AWS-Fixes für die Zertifikatsverwaltung.
  • Einige Logikfehler, wie QoS-Klassen mit welcher Geschwindigkeit senden dürfen, wurden behoben. Dies behebt die von den Partnern gemeldeten fehlerhaften Testfälle mit „guaranteed bandwidth“.
  • Es wurde sichergestellt, dass ALLE möglichen LTE-Bänder aktiviert sind, bevor bekannt ist, welche Bänder das Modul tatsächlich unterstützt. Dies könnte die Probleme beheben, die Partner mit „Forgotten LTE bands“ hatten.
  • Von nun an wird die TCP-Option 14 durch Viprinet-Tunnel akzeptiert.
  • Wenn das interne Übertragungsnetz auf etwas anderes als die Standardeinstellungen umkonfiguriert wurde, konnten die Virtual Hubs die Verifizierungsserver für Virtual Hubs nicht mehr erreichen.
  • Bei WLAN-Client-Modulen werden die aktuell gesehenen WLAN-APs wieder in der Modulinfo aufgelistet, auch wenn keine Verbindung zu einem AP besteht.
  • Bei früheren Firmware-Versionen konnte es nach einer Laufzeit von 49,7 Tagen aufgrund eines 32-Bit-Zähler-Wrap-Arounds zu einem Reboot kommen. Dieses Problem besteht nicht mehr.
  • Das Release enthält einen Fix für einen Workaround für Fehler in einigen LTE-Modul-Firmware-Releases, die dazu führen konnten, dass die LTE-Module eines 51x SIM-Karten bei einem Kaltstart nicht erkennen.
  • Ein potentielles KRACK-WLAN-Sicherheitsproblem wurde behoben.
  • Es gab einige Fehlerbehebungen für das Problem „Module bleiben für immer im Verbindungszustand stecken“, das Partner gesehen haben.
  • Zudem enthält das Release einen Fix für Chrome 61, das die selbstsignierten SSL-Zertifikate nur ungern angenommen hat, die unsere Router für das Web-Interface generieren. Bitte beachten Sie, dass Sie manuell ein neues SSL-Zertifikat im Router erneut generieren müssen, damit Chrome aufhört, sich zu beschweren.
  • „Managed SIM Settings“ wurden aus der Firmware entfernt, da unsere Managed SIMs bereits seit einem Jahr nicht mehr verfügbar sind.
  • Die 511 LTE-Bilder wurden um 35 MB verkleinert. Jetzt funktioniert ein Offline-Update auf einem 511 wieder zuverlässig.
  • Der Slave in einem Stacking Router-Setup speicherte die Konfiguration jedes Mal, wenn eine Änderung vom Master gesendet wurde. Nun wird er nur noch alle 30 Sekunden gespeichert.
    Auch die Synchronisation wurde nun gedrosselt, um weniger CPU zu verbrauchen.
  • Unter sehr seltenen Umständen konnte es vorkommen, dass geNATteter ICMP-Verkehr, der von mehreren Quellen (Tunneln) gleichzeitig kam, einen oder mehrere dieser ICMP-Flüsse blockierte.
  • Alle Download-Tools unterstützen jetzt auch HTTP Chunked Encoding.
  • In der vorherigen Stable Firmware-Version wurde die LTE-Firmware Carrier-Zertifizierung nicht in der Modul-Info angezeigt.
  • Es wurde sichergestellt, dass bei benutzerdefinierten Profilen bestätigt werden, dass alle Einstellungen auch wirklich vom LTE-Chipsatz empfangen werden. Dies behebt alle gemeldeten Probleme bei der Verwendung privater APNs.
  • Einige Nutzer haben berichtet, dass das im Webinterface enthaltene Google Maps GPS Tool nicht mehr funktioniere. Es wurde ein neuer API-Key von Google hinzugefügt, was dieses Problem behebt.
  • Seit dem 1. Dezember 2017 beschweren sich alle Firmwareversionen fälschlicherweise, dass die Firmware völlig veraltet sei. Wir bitten die daraus resultierende Verwirrung zu entschuldigen. 

Bekannte Probleme

  • Wir haben Berichte erhalten, dass in einigen Installationen VDSL oder ADSL Module im Status “Disconnecting” hängen bleiben können, wenn sie durch den 24h-Reconnect des ISP eine neue IP bekommen. Dieses Problem wurde in den letzten Jahren schon mehrfach berichtet, wir konnten es aber nie reproduzieren. Sollte dieses Problem bei Ihnen auftreten, so wenden Sie sich bitte an unser Support-Team, damit wir das Problem endlich finden und beseitigen können.
  • Unter Umständen ist es nicht möglich, auf Virtuellen VPN Hubs VPN Clients zu aktivieren. Bitte kontaktieren Sie den Support, wenn dies bei Ihnen der Fall ist. Wir arbeiten an einem Hotfix für dieses Problem.
  • Das Löschen eines VPN-Tunnels auf einem VPN Hub kann diesen rebooten lassen, wenn der Tunnel in den 3 Minuten zuvor noch verbunden war. Bitte warten Sie daher mit dem Löschen von VPN-Tunnels 3 Minuten bis nach dessen Disconnect.
  • Nach der Installation der Firmware kann ein VPN Hub Hotspare fälschlicherweise behaupten, dass der active VPN Hub nicht mehr erreichbar sei und versuchen, diesen zu übernehmen. Das Problem verschwindet, wenn der Hotspare ein zweites Mal neugestartet wird. Dies kann z.B. umgangen werden, indem vor dem Update der Hostspare temporär aus der Redundanzgruppe entfernt wird. Wenn Sie Unterstützung beim Rollout der Firmware auf einer großen Zahl von VPN Hubs brauchen, kontaktieren Sie bitte unseren Support. 

RuggedVPN Stable Firmware Release 23. August 2017 – Version 2017081640/2017082100

Zusätzlich zu einer großen Anzahl an Verbesserungen auf im Hinblick auf Stabilität in der Firmware-Version vom Juli 2017 bringt diese Version zwei weitere wichtige Fehlerbehebungen. Alle Kunden sollten unmittelbar auf diese Version umsteigen.

Wenn Sie noch nicht auf die Firmware-Version von Juli (2016111640/2017022000) umgestiegen sind, lesen Sie bitte auch die Release Notes dieser Version.

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 noch 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.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2017021340/2017072200, veröffentlicht am 31. Juli 2017):

Fehlerbehebungen

  • Unter bestimmten Umständen konnte Traffic innerhalb von einer oder mehreren QoS-Klassen plötzlich steckenbleiben. Das konnte z.B. darin resultieren, dass plötzlich für Benutzer keine Auflösungen per DNS mehr möglich waren. Dieser Bug existierte schon seit langem, trat aber extrem selten auf. Mit neueren Firmwareversionen trat er nun häufiger auf. Wie alle uns mit uns deswegen in Kontakt stehenden Kunden bestätigt haben, ist das Problem nun behoben.
  • Bei einigen Installationen wurden mit der Juli-Firmware die LTE 450 Mhz Module, die in Nordeuropa eingesetzt werden, teilweise nicht mehr vom Router erkannt. Das funktioniert jetzt wieder mit allen Produkten.

RuggedVPN Stable Firmware Release 31. Juli 2017 – Version 2017021340/2017072200

Diese Firmware-Version bringt eine große Zahl an Verbesserungen bzgl. der Produktstabilität und -Qualität, inklusive einigen sehr wichtigen Sicherheitsvorkehrungen gegen DoS-Angriffe aus dem Internet.

Das wichtigste neue Feature ist die Option, die Firmware unserer VDSL-Module von unseren Routern aus zu aktualisieren. Parallel dazu liefern wir neue Firmware für die VDSL-Module aus, welche von unseren Kunden dringend benötigte Fehlerbehebungen und Verbesserungen bringt.

Diese Firmware-Version unterstützt zudem erstmals die neuen 4.5G LTE-A-Module.

Da diese Version wichtige Sicherheitsverbesserungen enthält, empfehlen wir allen Kunden dringend, zeitnah ihre Geräte auf diese Firmware zu aktualisieren. Kunden, die immer noch die Classic-Firmware nutzen, sollten jetzt dringend auf unsere RuggedVPN-Firmware umsteigen, da die Classic-Firmware seit über einem halben Jahr nicht mehr gepflegt und unterstützt wird.

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 noch 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.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (2016111640/2017022000, veröffentlicht am 23. Februar 2017):

Neue Funktionen

  • Sie können nun die Firmware von VDSL-Modulen innerhalb des Web-Interface des Routers updaten. Neue Firmware-Images für VDSL-Module werden automatisch nach Bedarf heruntergeladen, analog der Firmware-Images für LTE-Module.
    Firmware-Änderungen für die aktuellste VDSL-Modul-Firmware-Version 1.91:
    • VLANS funktionieren nun im ADSL RFC1483-Modus.
    • Module kommunizieren nun Authentifizierungsfehler an den Router, wenn sich die Zugangsdaten während der PPP-Einwahl als falsch herausstellen.
    • Die Werkzeuge Ping und traceroute funktionieren in Viprinet wieder.
    • Mehrfachverbindungen des Moduls in die Welt funktionieren wieder (z.B. Download Test Tool).
    • Die Firmware nutzt den aktuellen Datapump (10.23.0.47), das behebt viele VDSL-bezogene Sync-Probleme.
  • Volle Unterstützung für 4.5G LTE-A-Module. Die Module zeigen nun auch die Modulseriennummer im Web-Interface an.
  • Implementierung von Code, der Ethernet/IP/TCP/UDP/ICMP-Pakete detailliert überprüft, wenn sie aus dem LAN eingehen und wenn sie rausgehen. Das schützt sowohl unsere Router und die Netzwerke dahinter gegen eine große Reihe von TCP/IP-Protokollattacken.
  • Neue Logo-Animation beim Starten von Routern. Weil wir's können. ;-)

Fehlerbehebungen

  • Wir erlauben nun das Löschen von VPN-Tunnels, VPN-Client-Tunnels und Channels, während sie noch aktiviert (aber nicht verbunden!) sind. Das wurde geändert, um einen Fehler zu beheben, bei dem der VPN-Client beim Hochstarten unendlich in einem unsauberen Zustand stecken bleiben konnte, bei dem er versuchte, einen aktivierten Tunnel zu löschen. Im Allgemeinen sollte sich dadurch auch die Nutzererfahrung verbessern.
  • Diese Firmware-Version behebt die Probleme, die LTE Europe/Australia/Africa Module mit dem Einlesen mancher SIMs hatten.
  • Falsche Zeitzonenberechnungen auf den Geräten der 200er und 5xx-Reihe wurden behoben, die falsche Log-Zeitstempel verursachen konnten.
  • Unter seltenen Umständen konnte der Routingkern durch den unsauberen Disconnect eines Channels stecken bleiben.
  • Unter sehr seltenen Umständen konnte durch den Zugriff auf einige Objekte, die derzeit vom Routing-Kern genutzt werden, dieser stecken bleiben (z.B. durch das Auslesen von SNMP, Web-Interface, CLI oder Router-Stacking-Kommunikation).
  • Auf neueren Geräten, die einen asynchronen Hardware-Crypto-Beschleuniger nutzen, konnte ein unsauberer Channel-Disconnect beim Routerkernel zu Absturz, Panik and Reboot führen.
  • Stacking-Master blieben manchmal stecken, wenn viele Änderungen auf Channels und/oder WAN-Modulen geschahen, die zwischen Routern synchronisiert wurden.
  • Ein Memory Leak führte bei der Nutzung von FEC unter Umständen nach einigen Tagen zu einem voll laufenden Speicher und zu einem Reboot.
  • Die Clone Detection des Virtual VPN Hub konnte fälschlicherweise einen Hub als Klon identifizieren, wenn die Uhrzeit auf unserem Backend-Server desynchronisiert war.
  • SSL Handshake-Timeouts sind jetzt viel entspannter, was zu weniger SSL Handshake-Fehlern bei instabilen WAN-Verbindungen führen sollte.
  • Im Fall, dass der Router rebooten muss (z.B. weil der Routingkern hängengeblieben oder der Speicher ausgegangen ist), wird er nun zunächst noch versuchen, eine Kopie der Logdatei auf den Flash-Speicher zu schreiben. Dies ermöglicht dem Supportteam in Zukunft, einen Hub/Router nach einem Reboot auf dessen Gründe zu diagnostizieren, auch wenn kein lokaler Syslog-Server am LAN existiert.
  • Der designierte Stacking-Master nutzt nun seine eigene Uptime statt der, die vom aktuellen Stacking-Master berichtet wird. Zudem wurde das Logging verbessert, so dass es jetzt weniger verwirrend sein sollte.
  • Ein Timing-Problem im dynamischen Routing, welches zur Meldung „Duplicate Router received“ auf der anderen Seite führte, wurde behoben.
  • Die Einstellung „Distribute via Dynamic routing“ in den Additional LAN Routers wurde ignoriert.
  • Ein zum Hub verbindender Node konnte für immer mit 99% CPU-Last stecken bleiben, wenn die TCP-Verbindung des Channels in einer bestimmten Phase des Verbindungsaufbaus zusammenbrach.
  • Die „Guaranteed delivery“ QoS-Einstellung konnte unter sehr seltenen Umständen dafür sorgen, dass der Router abstürzt und/oder Speicher verliert. Dieses Feature ist in dieser Firmwareversion komplett deaktiviert, und wird in einer späteren Firmwareversion zurückkommen. Egal, was aktuell in den QoS-Einstellungen konfiguriert ist, Guaranteed Delivery wird nicht benutzt (und die Einstellung in Ihrer Konfiguration auch nicht geändert).
  • Als Schutzmaßnahme wird Hub-seitig die Channel-Verbindung geschlossen, wenn während der Authentifizierungsphase mehr als 10 Fehler aufgetreten sind.
  • Es wurde Programmcode implementiert, welcher vom/zum LAN eingehende/ausgehende Ethernet/IP/TCP/UDP/ICMP-Pakete im Detail überprüft. Dies geschieht, um sicherzustellen, dass in keinem Falle Müll-Pakete den Router verlassen, welche Abstürze verursachen könnten.
  • Die Anzahl von Paketen, die in einem Rutsch vom LAN gelesen werden, wurde reduziert. Zuvor konnte man das LAN-Interface des Hubs mit Paketen fluten, und der Router war dann kaum noch in der Lage, etwas anderes zu tun. Das konnte den Eindruck vermitteln, dass der Routingkern steckengeblieben sei.
  • Auf dem Hub gibt es nun einen weiteren Schutzmechanismus gegen die erneute Nutzung einer invaliden, zwischengespeicherten SSL-Sitzung. Dies behebt eine Flut an SSL Handshake-Fehlern, die von einigen Kunden beobachtet wurden, bevor der Routingkern eingefroren ist.
  • Fragmentierte IP-Pakete mit einer Größe über 32KB konnten einen Speicherfehler auslösen, der wiederum einen Neustart zur Folge hatte. Wir sahen dies bei einigen Kunden, meist als Folge eines Angriffs auf deren Netzwerke.
  • Der Wechsel eines Hotspares in den Replacement-Mode verursachte einen internen Absturz. Dies führte wiederum zu einem Neustart des Systems sowie zu einer längeren Dauer der Übernahme. Dies wurde behoben, so dass die Übernahme nun wesentlich schneller geht.
  • LAN IP-Aliases akzeptieren nun keine ungültigen IPv6 Adressen mehr.
  • Das Anwenden neuer Einstellungen bei den DHCP-Diensten konnte eine grundlose Fehlermeldung auslösen.
  • Die SSH CLI RSA Keylänge wurde von 1024 auf 2048 Bit erhöht.
  • Wenn man bisher ein Viprinet-Gerät mit ICMP-Ping-Paketen flutete, hörte der Router nach einiger Zeit auf, darauf zu antworten, und beantwortete von da an ICMP-Anfragen gar nicht mehr.
  • VPN-Tunnel verbinden jetzt automatisch neu, wenn ein fataler Fehler beim Lesen von Paketen eines der Tunnel-Channel auftritt.

RuggedVPN Stable Firmware Release 23. Februar 2017 – Version 2016111640/2017022000

Dieses Release bringt zwei wichtige neue Funktionen: Dynamisches Routing mit OSPF und BGP sowie SMS-Unterstützung mit SMS-Autorespondern.

Zusätzlich beinhaltet dieses Release zahlreiche Fehlerkorrekturen. Ein großer Dank geht an dieser Stelle an unsere Partner und Betatester, die mit uns dieses Release lange und ausgiebig getestet haben. Wir empfehlen daher allen Kunden, diese Firmware zeitnah zu installieren. Zudem empfehlen wir allen Kunden, die noch Classic-Firmware verwenden, jetzt auf diese Firmware umzusteigen, da die Unterstützung für die Classic-Firmware nun ausläuft.

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 noch Classic-Firmware verwenden, können zu Routern und Hubs verbinden, die RuggedVPN-Firmware verwenden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatibilitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2016111640/2016120100, veröffentlicht am 12. Dezember 2016):

Neue Funktionen

  • Dynamisches Routing mit BGP und OSPF wird nun auf Hubs und Nodes voll unterstützt.
  • LTE-Module können jetzt SMS verschicken und empfangen. Zudem können Sie automatische Antworten für eingehende SMS konfigurieren. Mithilfe dieser Funktion können Sie unsere Produkte nun für LTE-Provider verwenden, die Datentarife anbieten, bei denen Sie mithilfe einer SMS Datenpakete hinzufügen können. Beispiel: Vodafone Deutschland schickt Ihnen eine SMS „Ihr High-Speed Datenvolumen wurde aufgebraucht, antworten Sie mit ‚5‘, um weitere 5GB hinzuzubuchen.“ Mit der Autoresponder-Funktion können Sie einen Filter auf "Datenvolumen wurde aufgebraucht" erstellen, bei dem der Router automatisch mit "5" antwortet, um ein weiteres Datenpaket zu buchen. Bitte beachten Sie, dass diese Funktion aufgrund Chipsatz-Beschränkungen leider nicht für LTE 450 und 4G Europe II Module funktioniert.
  • Die Konfiguration für Viprinet Virtual VPN Hub ist jetzt kompatibel mit der von Hardware Hubs, sodass Sie eine Config-Datei von oder für einen Hardware-Router kopieren und nutzen können.
  • Interne Verbesserungen beim Speichermanagement reduzieren die Größe des genutzten Speichers und Adressraums deutlich. Die Speichernutzung auf intensiv genutzten Hubs sollte damit deutlich langsamer steigen als bisher.

Fehlerbehebungen

  • Neues verbessertes Verhalten für deaktivierte Tunnel auf VPN Hubs: Anstatt Tunnels, Clients oder Channels verbinden und wieder trennen zu lassen, wenn sie deaktiviert wurden (oder die VVH-Identität noch nicht bereit ist), werden sie nun direkt am Verbinden gehindert. Für Verbindungsversuche wurde eine Drosselung hinzugefügt.
  • Viprinet Virtual VPN Hub: Verbessertes Startsystem, das sicherstellt, dass der VVH nicht mit eingehenden Tunnelverbindungen überflutet wird, bevor er bereit ist, diese anzunehmen.
  • Viprinet Virtual VPN Hub: Wenn beim Starten des VVH DNS unerreichbar war, konnte es bis zu 5 Minuten dauern, bis der Hostname des Identitätsservers neu aufgelöst werden konnte.
  • Viprinet Virtual VPN Hub: Benutzer können nicht länger eine neue Geräteidentität anfordern, es sei denn der Hub ist als „Copy“ markiert.
  • SFTP-Transfers vom und zum Router funktionieren wieder.
  • In der WAN-Modulinfo für LTE-Module konnte manchmal sinnloser Text hinter "Country:" auftauchen.
  • Manchmal zeigte das Web-Interface die Zusammenfassung aller Items nicht, wenn eine Objektliste aufgerufen wurde.
  • Manchmal wurden die Channels von gestackten Slaves nach einem Neustart nicht mehr genutzt.
  • Aus dem Web-Interface wurden zahlreiche Javascript-Debug-Ausgabezeilen entfernt.
  • Manchmal konnte es zu einem nicht synchronisierten Zugriff innerhalb des Ajax-Nachrichtensystems des Web-Interface kommen. Dadurch konnten u.a. Router einfrieren und/oder der Object-Baum konnte im Web-Interface nicht mehr erreicht werden. Das passierte meistens, wenn „Contact license server“ manuell aus dem Web-Interface ausgeführt wurde oder wenn auf dem VVH ein Tunnel deaktiviert wurde.
  • Wenn eine Lizenz-Deaktivierung fehlschlägt, wird nun ein Fehler ausgegeben.
  • Wenn ADSL/VDSL-Modulen bei einem 24h-Reconnect eine neue IP zugewiesen wurde, ohne dass das Interface während des Reconnects neugestartet wurde, funktionierten sie danach manchmal nicht mehr.
  • Abgelaufene Lizenzen/Abonnements werden auf dem VVH nicht mehr als gültige Tunnellizenzen gezählt.
  • Die Ergebnisse von Upstream-Autotuning auf dem RuggedVPN VPN-Client wurden um ein Zehnfaches verbessert.
  • Genau wie die Router stimmt jetzt auch der RuggedVPN VPN-Client die TCP-Sendbuffers ab. Wir haben gesehen, dass damit für Windows erst bei 8k Schluss war, das bringt also eine RIESIGE Leistungssteigerung bei hochlatenzierten Links.
  • Das HTTPS-Download-Testtool akzeptierte SSL-Zertifikate, die gültig aber abgelaufen waren.
  • Wenn ein Hub nicht konfiguriert war, VPN-Clients DNS zuzuweisen, konnte der VPN-Client während des Verbindungsaufbaus für 10 Sekunden blockieren. Diese Verzögerung wurde beseitigt, wodurch das Verbinden eines VPN-Clients drastisch beschleunigt wurde.
  • Routen, die auf ungültige Ziele zeigten, konnten nicht gelöscht werden.
  • Der VPN Router 2620 glaubte, seine Bandbreitenkapazität wäre 200 Mbit/s anstatt der 400 Mbit/s, die er leisten kann. Außerdem vermeldete er eine falsche Kapazität über den Tunnel zur Gegenstelle. In der Praxis bedeutete das zwar nicht viel, aber unter gewissen Umständen / bei gewissen Lasten aus dem LAN konnte das den möglichen Gesamtdurchsatz des Routers beschränken und es konnte dafür sorgen, dass der Hub falsche Werte für die Gesamtkapazität für Bandbreiten-Autotuning annahm.
  • Für den VPN-Client wurde der HTTPS-Webserver deaktiviert.
  • Für HTTPS-Fehler wurde ein Log-Präfix hinzugefügt, das die Remote-IP anzeigt, die den Fehler verursacht.
  • Das Identitätsmanagement des Viprinet Virtual VPN Hubs wurde verbessert. Falls ein VVH als Klon markiert wird, können nun einfach alle tatsächlichen Klone ausgeschaltet werden. Nach einer Weile wird der eine verbliebene Ex-Klon dann wieder als legitimer VVH verifiziert.

Bekannte Probleme

  • Das interne Transfernetzwerk für Virtual Hubs darf nicht verändert werden.
  • VLANs und Segmentierung werden so gut wie möglich über dynamisches Routing geregelt, allerdings funktionieren möglicherweise nicht alle Setups. Es gibt keine separaten Routing-Tables.
  • Um die SMS-Funktion auf einem 510 zu konfigurieren, muss sich im entsprechenden Modem eine SIM befinden.
  • VPN-Bypass ist derzeit deaktiviert.

Hinweise zum dynamischen Routing

Um die Funktion Dynamisches Routing zu aktivieren, muss eine Enterprise Node Features Software-Lizenz auf der Node-Seite installiert werden. Das bedeutet, diese Funktion wird derzeit mit allen Viprinet-Hubs werkseitig ausgeliefert und steht auf dem 2610/2620 kostenfrei zur Verfügung.

  • Fügt ein neues Objekt im Web-Interface „Dynamic routing settings“ hinzu, inklusive zweier neuer Tools „Full routing table“ und „Viprinet routing table“
  • Macht dynamische Verteilung statischer LAN/WAN-Viprinet-Routen möglich
  • Erlaubt Push-/Accept-Routen pro Tunnel. Diese Eigenschaft findet sich bei jedem Tunnel. Der Standardfall ist, Push-Routen auf der Node-Seite und die Option „Accept incoming routes“ auf der Hub-Seite zu aktivieren, allerdings gibt es bestimmt auch Anwendungsfälle, bei denen beide Richtungen zum Einsatz kommen.
  • Erlaubt die Auswahl, welches Interface in welcher Area sprechen und ob es für dynamisches Routing verwendet werden soll (OSPF/OSPF nur für IPv6).
  • Verteilt WAN/VPN-Routingregeln, VPN-Client-Pools, LAN-IPs und zusätzliche LAN-Routen.
  • Ermöglicht einem Viprinet-Router, sich selbst als Default-Gateway zu ernennen, wobei er von anderen Routern angegebene Default-Routen ignoriert.

Zwei Beispiele

Fall 1: Das neue Tunnel-Protokoll nutzen, um alle Node-Netzwerke an den Hub zu schicken, damit der Hub sie routet (keine statischen WAN/VPN Routingregeln)

  • Hub-Seite: Aktivieren Sie „Accept incoming routes“ im ausgewählten VPN-Tunnel
  • Node-Seite: Aktivieren Sie „Push routes through tunnel“ im ausgewählten VPN-Tunnel

Nachdem diese Einstellungen aktiviert wurden, muss der Tunnel erneut verbunden werden. Der Hub sollte nun alle Node-Netzwerke empfangen und diese zum richtigen Tunnel routen.

Fall 2: Fall 1 um einen dynamischen Routingdienst erweitern

  • Konfigurieren Sie zuerst Node und Hub wie in Fall 1
  • Konfigurieren/Aktivieren Sie zusätzlich den dynamischen Routingdienst auf Node- und/oder Hub-Seite sowie den gewünschten Dienst (BGP, OSPF oder OSPF für IPv6)

Der Hub erkennt auch alle eingehenden Netzwerke auf Node-Seite und routet diese. Stellen Sie sicher, dass Sie den Haken bei „Distribute local Networks“ im gewünschten Dienst gesetzt haben, sonst wird er nicht ausgeführt. Wenn Sie zusätzlich einen dynamischen Routingdienst auf der Hub-Seite aktiviert haben, kann er alle Node- und Hub-Netzwerke zum Uplink-Router leiten.

Warnung/Hinweise

  • BGP only: Um den Dienst zu starten, müssen Sie zumindest einen BGP-Nachbar konfigurieren. Sie finden das BGP-Nachbar-Objekt unter „Integrated services“ " „Dynamic routing settings“ " „BGP settings“.
  • OSPF/OSPF for IPv6 only: Um den Dienst zu starten, müssen Sie ein Interface konfigurieren, um es im LAN-Einstellungen-Objekt zu verwenden; dort können Sie auch das OSPF-Gebiet konfigurieren.
  • VPN-Tunnel: Um „Push routes through tunnel“/„Accept incoming routes“ erfolgreich zu ändern, muss der jeweilige Tunnel neu verbinden.

Bekannte Probleme

  • OSPF/OSPF für IPv6: Die Passwort-Authentifizierung funktioniert nicht.
  • Von anderen Routern ausgegebene Default-Routen gehen derzeit verloren.

RuggedVPN Stable Firmware Release 12. Dezember 2016 – Version 2016111640/2016120100

Dieses Release beinhaltet zwei kleinere Fehlerkorrekturen. Wir empfehlen allen Kunden, zeitnah auf diese Firmware umzusteigen. Zudem empfehlen wir allen Kunden, die noch Classic-Firmware verwenden, jetzt auf diese Firmware umzusteigen, da der Supportzeitraum für die Classic-Firmware bald endet.

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 noch Classic-Firmware verwenden, können zu Routern und Hubs verbinden, die RuggedVPN-Firmware verwenden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatibilitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur vorherigen RuggedVPN Firmware-Version (Version 2016100640/2016102400, veröffentlicht am 28. Oktober 2016):

Neue Funktionen

Diese Firmware bietet keine neuen Funktionen.

Fehlerbehebungen

  • Seit dem 1. Dezember 2016 zeigten alle früheren Firmware-Versionen beim Einloggen in das Web-Interface ein nervendes Popup, das verkündete, dass die Firmware veraltet sei und nicht mehr unterstützt werde. Das passierte sogar bei der jüngsten Firmware-Version vom 28. Oktober, die vollkommen in Ordnung ist und definitiv unterstützt wird. Dieses Popup wurde entfernt. Wir entschuldigen uns für die Unannehmlichkeiten.
  • Diese Firmware-Version behebt einen Kodierungsfehler, der dafür sorgte, dass VPN Clients, die mit einem RuggedVPN-Hub verbunden waren, keine Downstream- und Latenz-Graphen im Monitor-Tab darstellen konnten.

RuggedVPN Stable Firmware Release 28. Oktober 2016 - Version 2016100640/2016102400

Dieser Release bringt eine erhebliche Zahl von Verbesserungen im Bereich Qualität, Performanz und Stabilität. Wir empfehlen allen RuggedVPN-Nutzern, zeitnah auf diese Firmware umzusteigen. Wir empfehlen zudem allen Kunden, die noch Classic-Firmware verwenden, nun zeitnah auf diese Firmware umzusteigen, da das Ende des Supportzeitraums für die Classic-Firmware bald endet.

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 Viprinet Lifetime Maintenance.

Router und Hubs, die noch Classic-Firmware verwenden, können zu Routern und Hubs verbinden, die RuggedVPN-Firmware verwenden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatibilitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur dritten RuggedVPN Firmware-Version (2016080240/2016080800, veröffentlicht am 11. August 2016):

Neue Funktionen

  • Diese Firmware bietet keine neuen Funktionen.

Fehlerbehebungen

  • Seit geraumer Zeit wurden Channel disconnects nicht sauber ausgeführt. Dies könnte zu Abstürzen führen. In weniger schlimmen Fällen traten nur SSL-Fehler auf, oder es dauerte 5 Sekunden bis der Channel abgebaut war, statt direkt sauber getrennt zu werden.
  • Auf einigen Produkten (310, 2620, 2030, 5000, 5010) konnte die Hardwareverschlüsselungsengine während Channel disconnects für einen Absturz sorgen. Wir vermuten dass dieser Fehler der Grund ist, wieso Kunden mit Routern, welche unter großem Stress stehen (Satellitenverbindungen, Schiffe, Fahrzeuge mit häufigen Verbindungsneuaufbau), häufige Reboots sehen, während andere Kunden gar nicht betroffen sind.
  • Module, die im Stacking-Verbund als Slave genutzt werden konnten nicht verbinden, wenn die errechnete MTU kleiner als 1500 war. Das führte dazu dass 500er Router nicht als Stacking Slave verwendet werden konnte (das für UMTS verwendete PPP-Protokoll verlangt nach MTUs kleiner 1500).
  • Das automatische Kontaktieren des Lizenzservers funktioniert jetzt - zuvor musste man Lizenzen manuell neu abrufen lassen.
  • Bei LTE-Modulen findet, anders in vorherigen Firmwareversionen, die Einwahl nicht mehr direkt statt, sondern wird intern ausgelöst durch eine Änderung des LTE-Profils. Wir hatten dies zuvor geändert, da es Kunden gab, die mit der Nutzung von privaten APN Profilen Probleme hatten. Das neue Verfahren hat nun aber Probleme mit einigen Providern in manchen Ländern ergeben. Das Einwahlverfahren wurde daher zurückgeändert, damit die LTE-Profile der jeweiligen Provider genutzt werden. Kunden mit privaten APNs können daher nun wieder Probleme haben. Diese können das neue "Custom WWAN Profile"-Feature nutzen, um das Problem zu umgehen.
  • Spezielle Demo- und Projektrouter waren nicht in der Lage, Stacking Slave Channels zu nutzen. Das wurde korrigiert. Betroffene Kunden müssen das WAN-Modul betroffener Channel neu auswählen, nachdem diese Firmware installiert wurde.
  • Die Popup-Meldungen bei Demo-Routers, in denen darauf hingewiesen wird dass eine Produktvorführung nur 14 Tage dauern darf, wurde angepasst und teilt nur korrekterweise mit, dass dafür 90 Tage zur Verfügung stehen.
  • Die Art wie intern Statistiken über die Quell- und Zielhosts von Traffic-Flows gehandhabt werden wurde überarbeitet. Zuvor konnte man mit DDoS-Attacken mit gefälschten Quell-IP-Adressen das gesamte RAM des Routers aufbrauchen. Derartige Angriffe machen Viprinet-Routern nun nichts mehr aus. Zudem hat sich durch die Änderungen die Perfomanz bei Nutzung mit einer sehr hohen Zahl (1000+) von Geräten im LAN merklich verbessert.
  • Bei bestimmten Arten von DoS-Angriffen konnte der Routingkern festhängen, was nach 90 Sekunden einen Neustart des Routers auslöste.
  • Im Falle dass ein DDoS-Angriff vom Router erkannt wird, wird nun ein Hinweis im Log ausgegeben.
  • Ein Fehler in der Speicherverwaltung bei IP-Paketen wurde korrigiert. Der Fehler konnte ein kleines Speicherleck auslösen, was im Laufe der Wochen zu eine erheblichen Größe anwachsen konnte. Der Fehler konnte zudem unter sehr speziellen Bedingungen auch zum Absturz des Routers führen.
  • Das setzen einer IPv6-Adresse als Haupt-IP des LAN-Interface (anstatt die V6-Adresse als Alias hinzuzufügen) war zuvor nicht zulässig, konnte aber dennoch durchgeführt werden. Damit wurde der Router aus dem LAN-Netzwerk unerreichbar. Der Router verhindert nun, dass man auf irgendeinem Weg eine v6-Adresse als Haupt-IP angibt.
  • Der Neuübertragungsmanager für QoS-Klassen mit aktivierter "Guaranteed delivery" hatte einen Speicherleck, konnte aber unter Umständen auch bewirken, dass die Hälfte aller Neuübertragungeng gar nicht stattfanden. Das bedeutete, dass ein Flow durch den Tunnel trotz garantierter Übertragung doch Paketverluste erleidigen konnte. Das konnte dramatische Konsequenzen haben: Die TCP/IP Headerkompression baut auf die garantierte Übertragung auf, es dürfen nie Pakete fehlen - geschah dies doch, wäre der entsprechende Flow steckengeblieben.
  • Die Logausgabe von TCP-Sequenznummern wurde korrigiert. Zudem wurde der Loglevel für sehr häufige TCP-Protokollverstöße, welche von kaputten IP-Scannern ausgelöst werden, nicht länger als Angriff protokolliert.
  • Es wird nun sichergestellt dass serverseitig hängende HTTP-Verbindungen bei Nutzung der Download-Testtools des Webinterfaces sauber abgebaut werden. Der zuvor vorhandene Bug konnte für 99% CPU-Last sorgen, wenn ein Download serverseitig hängenblieb.
  • Der Routingkern konnte unter außergewöhnlichen Umständen unregelmäßig auf der Empfangsseite von Flows hängenbleiben. Der Fehler trat bei Kunden teilweise über Wochen und Monate nicht auf, um dann plötzlich für einen Tag ständig aufzutreten.
  • Einzelne Flows mit aktivierter "Guaranteed Delivery" konnten bei einem Neuverbinden des VPN-Tunnels steckenbleiben, wenn sie zu diesem Zeitpunkt eine hohe Übertragungsrate aufwiesen. Hängengebliebene Flows haben in diesem Falle das RAM gefüllt, bis dem Router ggf der Speicher ausging.
  • Die empfangsseitigen Timeouts für Flows ohne "Guaranteed Delivery" sorgen dafür, dass beim Neusortieren der empfangenen Paketfragmente nur so lange auf fehlende Teile gewartet wird, wie die Bündelungslatenz erwarten lassen sollte. Verstreicht diese Zeit, sollte das entsprechende Paket verworfen werden (aus Sicht des Zielsystems handelt es sich dann um einen Paketverlist). Die Filter, um die richtige maximale Wartezeit zu ermitteln, waren bisher nicht ausgereift. Insbesondere bei Bündelung von Leitungen mit sehr hoher oder schwankender Latenz (z.B. Satellit) konnten die Timeout-Werte ungünstig sein. Dies konnte dazu führen dass aufgrund von scheinbar verlorenen Paketen auf Empfangsseite ein Nutzer z.B. bei einem Download nicht die volle Bandbreite ausnutzen konnte, die der VPN-Tunnel eigentlich zur Verfügung stellt. Die Filter wurden nun komplett neu geschrieben und ausführlich getestet.
  • Die Meldungen "Average latency is ... ms, maximum allowed is ... ms, no alternatives,  keeping channel." wurden komplett entfernt, wie auch die zugrundeliegende Idee: Es macht keinen Sinn einen Channel kramphaft als verbunden zu forcieren, wenn die Latenz über der liegt, die vom Benutzer als maximal angebenen ist. Es ist sinnvoller in diesem Fall die Verbindung des Channels zu trennen, und die Pufferung auflaufender Pakete stattdessen auf der Tunnelebene durchzuführen.

RuggedVPN Stable Firmware Release 11. August 2016 - Version 2016080240/2016080800

Dies ist der empfohlene offizielle drittestabile Release der RuggedVPN Firmware. Dieser Release bringt eine erhebliche Zahl von Verbesserungen im Bereich Qualität, Performanz und Stabilität. Wir empfehlen allen RuggedVPN-Nutzern, zeitnah auf diese Firmware umzusteigen. Wir empfehlen zudem allen Kunden, die noch Classic-Firmware verwenden, nun zeitnah auf diese Firmware umzusteigen, da das Ende des Supportzeitraums für die Classic-Firmware bald endet.

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 Viprinet Lifetime Maintenance.

Router und Hubs, die noch Classic-Firmware verwenden, können zu Routern und Hubs verbinden, die RuggedVPN-Firmware verwenden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatibilitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur zweiten RuggedVPN Firmware-Version (Version 2016040640/2016061000, veröffentlicht am 17. Juni 2016):

Neue Funktionen

  • Es können nun angepasste LTE WWAN-Profile angelegt werden, wie sie von einigen Carriern benötigt werden (z.B. für private APNs). Bitte beachten Sie, dass die Profil-Voreinstellungen sich geändert haben. Bitte überprüfen Sie die Kompatibilität mit Ihrem LTE-Anbieter, bevor Sie diese Firmware im großen Stil ausrollen.
  • Hubs im Hotspare-Modus verfügen nun über funktionierende ACLs (und haben intern nun unseren vollen Routing-Stack laufen, was zuvor nicht der Fall war). Dies ermöglicht endlich, die Service-ACLs auch in diesem Modus zu nutzen. Dies ist deshalb wichtig, da ohne ACLs der DNS-Service von Hubs im Hotspare-Modus offen im Internet erreichbar ist, und für DNS Amplification-Attacks missbraucht werden kann. Bitte verifizieren Sie daher nach dem Firmware-Update unbedingt, dass Sie eine entsprechende ACL angelegt haben, die den DNS-Dienst abschottet.
  • Die CPU-Last für Tunnel-Channel auf Nodes wurde verringert. Dies kann zu leicht erhöhter Bündelungskapazität führen, wenn viele Channels benutzt werden (z.B. beim Stacking).
  • Die CPU-Last auf Hubs und Nodes, die eine sehr hohe Anzahl von neuen Verbindungen/Flows durch den Tunnel erhalten (z.B. bei einem eingehenden Portscan oder einer DoS-Attacke), wurde drastisch reduziert.
  • Die Latenz des Routingkerns ist nun so niedrig wie nie zuvor. Der Router lässt sich nun mit einer Antwortzeit von <3ms anpingen.
  • Der LAN-Durchsatz wurde erhöht, die CPU-Last durch LAN-Traffic reduziert.
  • Die LTE-TDD Bänder B38 and B40 bei Nutzung des 4G Europe/Australia/Africa moduls sind nun getestet und funktionieren. Das Modul hat nun auch ein funktionierendes AT Command Tool, und ist insgesamt bereit für die Nutzung in Produktion.

Fehlerbehebungen

  • Zahlreiche Fehler beim WLAN Client-Modul behoben, wodurch die Kompatibilität verbessert und nun auch die Verbindung zu unverschlüsselten Access Points erlaubt wird.
  • QoS Bündelungsprioritäten wurden nicht kopiert, wenn man QoS aus Vorlagen wiederherstellte oder dorthin speicherte.
  • Beim Stacking von Slaves konnte ein 24h-Disconnect oder das Neuzuweisen einer IP durch den Provider, während man verbunden war, den Router dazu bringen, konstant 99% CPU zu verbrauchen.
  • Hubs im Replacement-Modus warnten manchmal davor, dass auf ihnen VLM nicht installiert sei. Das wurde behoben.
  • Die Heartbeat-Diagnose ("A single router is gone from the network") wird nun nur noch einmal pro Sekunde ausgegeben.
  • Log-Nachrichten verloren Speicher, wenn das Web-Interface ohne aktivierte Websockets genutzt wurde. Das wurde zu einer wesentlichen Menge an Speicher, wenn das Web-Interface eine sehr lange Zeit geöffnet war und der Router eine große Anzahl Log-Zeilen produzierte (sehr ausgelastete Hubs).
  • Ein Speicherleck wurde behoben, das auftrat, wenn der Router IPv6 Broadcast-Verkehr verwarf, welchen er vom LAN erhielt.
  • Ein kleines Speicherleck im Konfigurationssystem wurde behoben. Bei gestackten Nodes mit sehr vielen Konfigurations-Synchronisationen (z.B. weil sehr instabile Channels genutzt werden) konnten diese Lecks über längere Zeit erhebliche Ausmaße annehmen.
  • Der RAM-Verbrauch von Hubs die eine sehr hohe Zahl (50000+) von gleichzeitigen Flows (Verbindungen durch das VPN) sahen, wurde deutlich reduziert.
  • Der interne Packet-Slicer, welcher dafür zuständig ist, dass Pakete in Fragmente zerschnitten und dann über mehrere Channels geschickt werden, konnte unter Umständen (hohe Nummer von Channeln, instabile Channels und/oder FEC angeschaltet) eine erhebliche Menge von Speicher lecken.
  • Die LAN NIC der Router kann nicht länger hängenbleiben, im schlimmsten Falle bringt ein LAN-Reset das Interface wieder zurück ins Leben.
  • Ein WLAN Client-Modul konnte dafür sorgen, dass der Router 100% CPU verbrauchte.
  • Der voreingestellte Autotuning Modus für neu angelegte Channels ist nun "Hybrid" statt "Heuristic", was typischerweise die bessere Wahl ist.

RuggedVPN Stable Firmware Release 20. Juni 2016 - Version 2016040640/2016061000

Dies ist der empfohlene offizielle zweite stabile Release der RuggedVPN Firmware, welche seit über einem Jahr in Entwicklung war. Wir empfehlen allen Kunden, die noch "Classic"-Firmware verwenden, nun auf diese Firmware umzusteigen.

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 installlierte Viprinet Lifetime Maintenance Lizenz erfordert. Weitere Informationen hierzu erhalten Sie unter https://www.viprinet.com/vlm.

Router und Hubs, die noch Classic firmware verwenden, können zu Routern und Hubs, die RuggedVPN firmware verwenden, verbinden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatiblitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur ersten RuggedVPN Firmware (Version 2016040640/2016040300 veröffentlicht am 7. April 2016)Version 2015081830/2015102900 veröffentlicht am 27. November 2015).

Neue Funktionen

  • In den Enabled Mobile Technology lassen sich nun präferierte LTE-Bänder konfigurieren.
  • Funkzellenwechsel werden nun aufgezeichnet und gelogged. Es gibt nun auch eine Funktion um manuell alle LTE-Bänder abzuscannen. Und schließlich gibt es ein optionales Feature, dass nach zwei Funkzellenwechseln bei denen nur UMTS empfangen wurde automatisch versucht wird, auf LTE zurückzukehren, und dabei die präferierten Bänder zu nutzen. Das ist sehr nützlich für Fahrzeuganwendungen, bei denen durch Bereiche mit schlechtem Empfang gefahren wird. Ohne dieses Feature würde das LTE-Modul nach dem Wechsel hinunter auf UMTS dort verharren, da ein Wiederhochwechseln zu LTE die Channelverbindung trennen würde. Mit diesem neuen Feature wird in diesem Fall zunächst der Channel kurz disconnected, LTE gescanned, und dann der Channel wieder neu aufgebaut.
  • Das Google maps tool mach nun live automatische Updates, wenn der Router (bzw das Fahrzeug in dem sicher Router befindet) bewegt.
  • Es gibt nun bessere QoS default templates, die auch viele möglicherweise durch den Viprinet-Tunnel betriebene VPN-Protokolle erkennt, z.B. IPSec. Benutzen Sie die "Restore Manufacturing defaults" Funktion um diese neuen QoS-Templates zu erhalten. Sollten Sie den Router in einem Fahrzeug nutzen, sollten Sie zusätzlich die Forward Error Correction (FEC) für alle QoS-Klassen aktivieren.
  • SNMP: Die Mobilfunk-CellID sowie Module-Perfomancedaten werden nun übermittelt. Zuvor wurde für vpnRouterInterfaceIndex in der VIPRINET-MIB immer 0 berichtet, das wurde nun korrigiert.

Fehlerbehebungen

  • Die Hinweise auf bald ablaufende VLM Lizenzen erscheinen jetzt nur noch, wenn die Lizenz in weniger als 7 Tagen abzulaufen droht.
  • Alle Firmware-bezogenen Warnungen wurden aktualisiert. Für unlizensierte Firmware (kein VLM installiert) gibt es nun sehr explizite Warnungen.
  • 310/2030/2620 Router haben beim System-Neustart das Viprinet-Logo nicht ausgeschaltet.
  • Demorouter dürfen nun für jeweils bis zu 90 Tage am Stück genutzt werden, die Warnungen im Log wurden entsprechend angepasst.
  • In den SNMP Settings werden nun auch die Modelle 2620 und 2030 erwähnt.
  • Für den Hub 5000 wurden fehlende Lizenztypen hinzugefügt. Zurvor wurden VLM Lizenzen beim Hub 5000 ignoriert.
  • Die Art wie Listenobjekte (z.B. Tunnel) intern gelöscht wurden wurde geändert. Zuvor konnte es passieren, dass abhängig von der Reihenfolge in der der Benutzer diese markierte, manche Einträge nicht gelöscht wurden.
  • Die Lademaske im Webinterface wird nicht mehr angezeigt, wenn der Router weniger als 500ms vom Browser-Benutzer "entfernt" ist. Wenn man lokal zu einem Router verbindet fühlt sich das Webinterface dadurch noch flotter an.
  • Objekteditoren im Webinterface werden nun automatisch aktualisiert, wenn sich das Objekt verändert (z.B. die Bandbreite eines Tunnels). Wird ein Objekt gerade editiert, wird das Objekt aber nicht mehr neu geladen, um das aktuelle Editieren nicht zu stören.
  • Listeneinträge hoch- oder runterzubewegen war bisher extrem mühsam und erforderte Teils ein Neuladen der Seite. Dieses verschieben funktioniert nun sauber wie erwartet, und der Objektbaum auf der linken Seite aktualisiert sich ebenfalls passend automatisch.
  • Wenn sich ein Objektname ändert (z.B. wenn sich ein WAN-Modul umbenennt) wird der Objektbaum nun korrekt aktualisiert.
  • Diese Firmware behebt zwei seltene aber bedeutende Fehler die dafür sorgen konnten dass der Routingkern bis zu 30 Sekunden einfriert, was wiederum alle Tunnel zu einem Hub zum disconnecten bringen würde.
  • Die Meldung "Slot 6 - 4G Americas for AT&T USA contains illegal characters." wurde korrigiert.
  • Gelegentlich (vor allem mit Stacking) konnte es passieren, dass der DHCP-Dienst beim Routerstart nicht mitstartete.
  • Latency Autotuning wurde so geändert, dass keine Werte über 1000ms mehr ermittelt werden. Sollten Sie Satellitenverbindungen mit höheren Latenzen nutzen, sollten Sie Latency Autotuning ohnehin deaktivieren.
  • Wenn Sie FEC im Webinterface für eine QoS-Klasse aktivieren, wird die "Preferred number of channels" automatisch auf einen sinnvollen Startwert 3 gesetzt. Dieser Wert sollte dann nach Bedarf angepasst werden (z.B. wenn lieber die besten 4 von 6 Channeln genutzt werden sollen).
  • Für WWAN-Module wurde auf Grund von Bugs im Qualcomm-Chipsatz beim ersten Verbinden zu einem Mobilfunknetz häufig kein Providername ermittelt. Dies wiederum konnte unser Signal Monitoring Tool verwirren. In diesen Fällen wird der Netzwerkname stattdessen nun durch eine Routerinterne Providernamendatenbank ermittelt.
  • Das Monitor Tool hat bisher bei WWAN-Modulen meist jeden Slot zwei Mal angezeigt - einmal als "Slot 1 - WWAN (3G/4G) und dann kurz darauf mit dem finalen Modulnamen. Dies wurde korrigiert, der "Slot 1 - WWAN (3G/4G)" Eintrag wird nicht mehr an das Monitor Tool übermittelt.
  • Die Logik dass bei doppelten Einträgen in der Liste von "First/Second/Third Bonding Priority" diese aussortiert werden hat nicht funktioniert. Die Logik wurde entfernt, es liegt jetzt in der Benutzerverantwortung logisch sinnvolle Einträge zu erzeugen.
  • Es wurden mehrere Bugs behoben, die dafür sorgen konnten dass WAN-Module nach dem stromlosschalten des Routers ihre Konfiguration vergessen konnten.
  • Wenn man in einer QoS-Klasse die QoS Templates angewendet hat, wurden die meisten QoS-Eigenschaften überhaupt nicht kopiert.
  • Das Webinterface und die CLI wurden unerreichbar wenn man eine leere Routingregel angelegt hatte, die auf einen Tunnel zeigt.
  • Der Programmcode der Pakete vom LAN-Interface gelesen hat hatte mehrere Fehler: Ethernet-Typen außer IP/IPv6/ARP wurden trotzdem zum Teil wie IP behandelt, bevor diese Pakete verworfen wurden. Dies konnte die Internal errors CA23AA32932FFFF1 und BACEE2923EEEEEEB auslösen.
  • Für VLAN-Tagged Traffic wurden für den Rotuer wichtige Multicast-Pakete verworfen.
  • Mehrere Bugs bei der Verarbeitung von IPv6-Paketen wurden behoben. Bisher konnte es passieren, dass bei IPv6-Paketen übergroße Ethernet-Frames versendet wurden, die ggf. dann im Netz verworfen worden wären.
  • Wenn die VLAN-Id vom LAN gelesen wird wurden IEEE 802.1Q / IEEE 802.1p Markierungen bisher nicht herausgefiltert, dies resultierte in falschen VLAN Id Nummern.
  • Nachdem ein Paket vom LAN gelesen wird, werden nun zunächst einige weitere Plausibilitätschecks gemacht, bevor das Paket weiter verarbeitet wird. Ohne diese Checks war es bisher möglich einen Internal Error auszulösen, in dem man einen ungültigenTCP Header mit der Größenangabe 0 an den Router geschickt hat.
  • Die Demorouter beginnend mit dem Produktcode 55-... haben sich darüber beschwert, keine VLM-Lizenz zu haben, die sie überhaupt nicht benötigen.
  • Der Channel Verbindungsfehler nach Systemstart, der auftrat wenn "SSL/Channel Session Caching" aktiviert war wurde behoben. Es ist nun sicher diese Option für Channel zu aktivieren. Für Hubs und Nodes bei denen die Channel häufig neuverbinden, z.B. bei Nutzung von LTE oder instabilen Leitungen, wird dies sowohl die Geschwindigkeit erhöhen als auch die CPU-Last dramatisch senken.
  • Einige vergessene Debug-Logmeldungen wurden entfernt

RuggedVPN Stable Firmware Release 11. April 2016 - Version 2016040640/2016040900

Dies ist der empfohlene offizielle stabile Release der RuggedVPN Firmware, welche seit über einem Jahr in Entwicklung war. Wir empfehlen allen Kunden, die noch "Classic"-Firmware verwenden, nun auf diese Firmware umzusteigen.

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 installlierte Viprinet Lifetime Maintenance Lizenz erfordert. Weitere Informationen hierzu erhalten Sie unter Viprinet Lifetime Maintenance.

Router und Hubs, die noch Classic firmware verwenden, können zu Routern und Hubs, die RuggedVPN firmware verwenden, verbinden. Allerdings wird in diesem Falle 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 verwendet aktuell einen auf der Classic-Firmware basierenden Kern und nutzt daher immer den Kompatiblitätsmodus. Eine neue Version des Software VPN Clients mit RuggedVPN-Kern wird in nächster Zeit veröffentlicht werden.

​Nachfolgend eine Liste aller neuen Features und Fehlerkorrekturen im Vergleich zur letzten Classic Firmware (Version 2015081830/2015102900 veröffentlicht am 27. November 2015). Ja, das ist eine ganz schöne Menge.

Neue Funktionen

  • Volle Unterstützung für IPv6 Support für LAN Interfaces und VPN-Tunnel
  • WWAN Image Manager und Umschalter. Auf modularen Routern lassen sich nun für WWAN/LTE-Module neue Firmware-Versionen auf diese Module installieren, um neueste Entwicklungen bei der LTE-Technologie abzudecken und für den jeweiligen Netzbetreiber zertifzierte Firmware zu verwenden. Die zugehörigen LTE-Firmwareimages werden dabei automatisch nach Bedarf aus dem Internet heruntergeladen und für weitere Modulupdates gecached.
    Auf 511/512-Routern werden stattdessen alle möglichen WWAN-Images für die integrierten Modems bereits zusammen mit der Routerfirmware ausgeliefert. Mit einem Umschalter-Tool kann hier wiederum die auf dem Modul verwendete Firmware gewechselt werden, ohne dass ein Download aus dem Internet nötig ist.
  • Die CLI wurde komplett überarbeitet. Sie enthält nun auch eine große Zahl an Tools, die es bisher nur im Webinterface gab, z.B. Ping, traceroute, wan interface info etc.
  • Das Webinterface nutzt nun HTTP keep-alive und Websockets. Dies ergibt eine erhebliche Verbesserung bei der Reaktionszeit und Geschwindigkeit.
  • Einfache und Doppelte verteilte Vorwärtsfehlerkorrektur. Ähnlich RAID5 (Single Parity) und RAID6 (Double Parity) bei Server-Festplatten kann der Router nun automatisch durch schwankende Leistungsqualität fehlende oder beschädigte IP-Fragmente auf der Empfangsseite korrigieren und ersetzen. Der Single Parity-Modus ist ohne Extra-Lizenz verfügbar, der Double Parity Modus erfordert eine installierte Streaming Optimizations-Lizenz.
  • Neue optionale adaptive Datenkompression auf QoS-Basis. Per QoS-Klasse kann nun gewählt werden, ob der Router versuchen soll, die übertragenen Daten zu komprimieren. Bei typischem Bürotraffic erreicht man damit im Schnitt 25-30% zusätzliche Bandbreite.
  • Per QoS-Klasse kann nun eine "garantierte Übertragung" gewählt werden. Ist diese aktiviert, werden in dem Fall, dass ein Paket selbst per Vorwärtsfehlerkorrektur nicht wiederhergestellt werden kann, dieses automatisch intern neu übertragen. Damit wird für den Applikationstraffic garantiert, dass immer 0,0% Paketverlust herrscht.
    Dieses Feature ist ein bisschen "overengineered" - unsere Vorwärtsfehlerkorrektur ist so gut, dass dieser Modus so gut wie nie gebraucht wird. Dieses Feature braucht zudem einiges an CPU und RAM-Speicher.
    Das Feature ist daher per Default aus, da nur eine sehr begrenzte Anzahl von Applikationen einen Nutzen hieraus ziehen.
    Das Feature sollte nur für Applikationen aktiviert werden, die ein erhebliches Problem mit einem verlorenen Paket haben. Das können z.B. Video Codecs oder Videokonferenzsysteme sein.
  • Große Beschleunigung bei der Ausgabe von Logmeldungen im Webinterface. Selbst wenn der Router eine sehr hohe Anzahl von Logzeilen pro Sekunde generiert, sollte der Webbrowser nun nicht mehr einfrieren.
  • Der Lizenzmanager kann nun automatisch über das Internet Lizenzen prüfen. Alle auf einen Router registrierten Lizenzen werden dabei automatisch heruntergeladen und auf dem Router installiert. Sollte der Router nicht ins Internet verbinden dürfen, müssen Lizenzen weiterhin manuell eingetragen werden.
  • Für 200/511/512 Router kann der integrierte WLAN AP nun auch den schnellen "AC Mode" nutzen. Zudem wurde der Verwaltungscode für den WLAN AP neu geschrieben. Je nachdem welche Standort-Region gewählt ist, werden jetzt alle für die Region zugelassenen WLAN-Channel angeboten.
  • VLAN tunnel transport
    Die Idee ist:
    Innerhalb des Routingobjektes können Sie nun VLAN Aliase erstellen. Auf diese kann in den Modul- und Tunnel-Einstellungen verwiesen werden. Für jeden Tunnel können Sie eines oder mehrere dieser VLANs wählen.
    Nun wird aller vom LAN VLAN hereinkommender Traffic auf den Tunnel weitergeleitet der dieses VLAN gelistet hat. Das Paket innerhalb des Tunnels ist Tagged, d.h. auf der anderen Seite des Tunnels wird das Paket ebenfalls mit einer VLAN-ID markiert sein. Sollte das VLAN-Tag dort nicht eingetragen sein, wird das Paket verworfen. Dadurch kann der Administrator eines Nodes nicht in VLANs anderer Nutzer auf dem VPN Hub eindringen, egal was er konfiguriert.
    Die aus der Classic-Generation bekannte "Tunnel Segmentation ID" existiert weiterhin. Diese wird verwendet um Pakete zu taggen, die untagged aus dem Tunnel kommen. Dadurch kann selbst dann auf dem Hub VLN Tagging benutzt werden, wenn auf dem Node keine VLANs konfiguriert sind.
    Sollten Sie mehrere am Node vorhandene VLANs durch den Tunnel hindurch zum Hub durchbingen wollen, so erfordert das auf dem Node eine "Enterprise Node Features"-Lizenz (Ausnahme: 2610/2620 Router enthalten dieses Feature kostenlos).
  • Jedes WAN-Modul hat nun ein Unterobjekt "Performance data", welches über Webinterface und CLI sowie SNMP erreichbar ist. Wenn es per SNMP abgefragt wird, wird das Objekt maximal alle 5 Sekunden aktualisiert. Damit lassen sich bequem aus der Ferne Performancedaten wie Signalstärke auslesen. Das Auslesen dieser Daten per SNMP erfordert eine "Enterprise Node Features"-Lizenz (2610/2620 haben dieses Feature wiederum kostenfrei inkludiert).
  • Unterstützung für LTE450 Module
  • Enabled Mobile Technologies bekommt nun automatisch passende Vorgabewerte zu den von dem jeweiligen Modul unterstützten mobilen Technologien. Als Beispiel wird bei LTE450 nur das 450 Mhz-Band aktiviert, bei dem 4G Europe/Australie-Modul wird CDMA deaktiviert.
  • Die summierte aktuelle Bandbreite für alle verbundenen Tunnel wird nun in der Tunnelübersicht angezeigt. Dies ermöglicht es nun die genutzte Bandbreite des Hubs auszulesen.
  • SSL-Sitzungen und Kanalautentifizierungen werden nun zwischengespeichert. Dies bewirkt das wiederverbindende Kanäle auf den Nodes nicht länger eine erhöhte CPU-Last auf dem Hub verursachen. Wir konnten somit eine erhebliche Verbesserung für jeden Nutzer von Nodes in Fahrzeugen beobachten. Auf einem Kunden VPN-Hub wurde die CPU-Last von 65% auf 2% verringert.
    Diese Verbesserung bewirkt auch, dass ein Kanal mit Beispielsweise 100ms Latenz nicht länger mehr als eine Sekunde Zeit zur Wiederverbindung des Kanals benötigt, sondern nur noch einen Bruchteil davon. Wir glauben das dies eine deutliche Verbesserung ist, die viele unserer Kunden nicht mehr missen wollen.
  • Eine VLAN ID wurde zu den Routing- und QoS-Regeln hinzugefügt. Mit diesem neuen Feature können Sie nun die Routing- und QoS-Regeln entsprechend der Tunnel Segmentierung / VLAN ID steuern.

Fehlerbehebungen

  • Sollte während eines Router-Kaltstarts ein Modul, welches vorher bereits konfiguriert (und in der Konfiguration gespeichert) wurde, nicht sichtbar sein, warten wir nun bis zu 30 Sekunden, damit das Modul wieder erscheint. Das liegt daran, dass während eines schnellen Bootprozesses des Routers die betroffenen 4G Module noch nicht komplett gebootet haben, aus diesem Grund sind die Module noch nicht sichtbar, während die Konfiguration geladen und ausgeführt wird. Bei einem unvorteilhaften Timing könnte dies dazu führen, dass die Module ihre Konfiguration verlieren.
    Dies sollte alle bei Kunden aufgetretene Probleme mit verlorenen Konfigurationsdaten beheben, welche wir zuvor nie reproduzieren konnten.
  • Verbesserte Sicherheit: TLS Sicherheitspatch gegen RSA CRT Attacken implementiert.
  • Verbesserte Sicherheit: SSLv3 und SB_SUITE_RSA_RC4_SHA werden nicht länger für das Web-Interface verwendet (dies bedeutet, dass der IE 6 nicht mehr unterstützt wird).
  • Sicherheitsverbesserung: die einzigen ICMP Pakete die noch akzeptiert werden sind: ICMP_ECHO, ICMP_ECHOREPLY, ICMP_UNREACH, ICMP_TIMXCEED, alle anderen werden gefiltert. Dies wird aufgrund eines Sicherheitsaudits eingeführt - man erhält keine TIMESTAMP Antworten eines Viprinet Routers, da diese einen potenziellen Angriffsvektor darstellen.
  • Hubs überprüfen nun ihre Modellnummer während sie im Hub Replacement und Hotspare Mode sind. Im Hotspare Modus werden Lizenzen deshalb als gültig dargestellt (zuvor war diese Überprüfung nicht möglich, da das Router Modell "unbekannt" war). Es wurde ausserdem Text entfernt, welcher ausführte, dass der Lizenz-Manager im Hotspare Modus nicht genutzt werden kann, denn dies ist nun möglich.
  • Ein Classic VPN Client welcher sich zum HUB verbindet, konnte Pakete senden die eine Größe von 1500 Bytes überschreiten (aufgrund fehlendes Unpaddings) dies führte zum Fehlercode 12A8922323111132 innerhalb des VPN Clients.
  • Hubs werden nun Fehlermeldung in das Logfile schreiben, falls ein entfernter Router eine Fehlermeldung während der Verbindungsaushandlung des Tunnels sandte. Ausserdem wird die "Connection dropped due to command timeout" message nur dann genutzt wenn die Verbindung während einer Zeitüberschreitung geschlossen wurde.
  • Manchmal wurde eine SIM Karte während einer Race Condition entsperrt, aber das Auslesen der IMSI und HomeMCC/MNC schlug fehl, da die SIM Karte noch nicht bereit war. In diesem Fall wird das Auslesen wiederholt. Jedoch war die Funktion zum Wiederauslesen des MCC fehlerhaft, so dass dies nie funktionierte. Dies ist der Grund, warum APN Autodetection seit einigen Firmware Versionen mit einigen unserer LTE Module fehlschlug.
  • Wurde der Trafficcounter eines Interfaces mehrfach resettet, hatte dieser anschließend falsche Werte.
  • Falls ein WAN Module öfters neu verbunden hat oder keine IP-Addresse erhielt, konnte der genutzte Channel Internal Error Fehlermeldungen verursachen und der Router neustarten.
  • Manchmal, wenn man einen Router neustartete oder wenn man von Slave auf Master Mode umschaltete, war es möglich dass einige LAN Dienste nicht funktionierten.
  • Ein Modulreset (manuell oder automatisch) blockierte den Haupttimer des Routers bis zu zwei Sekunden. Dies verursachte unter Umständen einen Verbindungsabbruch der übrigen Channels.
  • Ein 511/512, der durchgehend ein Modul neustartet, konnte nach einer Weile keine File Descriptors mehr zur Verfügung haben und deshalb in einem unnutzbaren Zustand enden. Dies sollte nun behoben sein.
  • Fix für VDSL RFC 1483 statische IP (ein Modem-Fix ist hierfür auch notwendig)
  • Die maximale Anzahl an Verbindungen für Hotspare Konfigurationsübertragungen war undefiniert (wurde niemals gesetzt) und deshalb war diese Anzahl je nach Build zufällig definiert. Aufgrund dieses Zustandes hat dieses Feature auf einigen Firmware Builds nicht funktioniert, während auf anderen Builds die Hubs einwandfrei die Konfiguration übertragen konnten.
  • Mehrere Crash-Bugs im Stacking-System wurden behoben.
  • Bei hoher Speicherauslastung konnten einige Skripte nicht mehr ausgeführt werden. Dies verursachte verschiede Fehler, z.B. bei der Einwahl. Wenn dies geschah konnte der Router noch nicht einmal rebootet werden.
  • Das Hinzufügen einer IPv6-Adresse als primäre LAN IP Adresse führte zu einer Reboot-Schleife. Dies ist nun nicht mehr möglich, IPv6 Adressen können nur als LAN Alias verwendet werden - verschiedene Teile der Software vertrauen auf eine IPv4-Adresse als primäre IP auf dem LAN Interface.
  • Zeitsynchronisation mittels NTP funktioniert nun auch auf Hotspare Hubs.
  • Die Art wie sich LTE Modems eingewählt haben, hat sich für folgende Module geändert - 4G Europe/Australia, 4G Europe II und 4G Americas. Dies löst Probleme die Module mit der 05.05.58 Firmware hatten und sich nicht mehr zu AT&T und T-Mobile in den USA verbinden konnten.
  • Bei manchem Netzanbietern haben die neuen 4G Europe II Module den Netzwerkname in 7bit Kodierung gemeldet, was in falschen Netzwerknamen resultierte.
  • 4G Europe II Module haben falsche "Expected Link Capacity"-Werte ermittelt, zudem haben alle 4G Module manchmal EV-DO statt UMTS erkannt, was ebenfalls in falschen Kapazitätswerten resultierte. Falsche Kapazitätswerte wiederum sorgten dafür dass Channels nicht die tatsächlich maximale mögliche Kapazität der Verbindung nutzten.
  • Durch ein Timingproblem schlug das Auslesen der IMSI oder Home MCC/MNC von der SIM nach der SIM Entsperrung fehl. Dies kann dazu führen, das die APN Autokonfiguration fehlschlägt. Diese Daten werden nun später ausgelesen.
  • Der Neustart eines Routers sollte nun nicht mehr fehlschlagen, auch bei wenig verfügbaren Speicher.
zum Anfang