Diese Firmware bietet keine neuen Funktionen.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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