• Für alle lokalen Dienste (DNS, AdminDesk HTTP/HTTPS, SSH CLI, SNMP) gibt es nun Zugriffskontrolllisten (ACLs). Mit diesen können Sie definieren, welche IPs und Subnetze vom LAN oder WAN/VPN auf welche Dienste zugreifen können. Beim Firmware-Upgrade wird ein Standard-Regelsatz generiert. Diese Regeln wurden so erstellt, dass sie bestehende Installationen nicht beeinträchtigen, und es wird empfohlen, sie zu verfeinern. Beispielsweise wird momentan Zugang zum AdminDesk auf HTTP und HTTPS von überall erlaubt, während wir empfehlen, nur HTTPS vom Internet aus zu erlauben.
  ACHTUNG: Aufgrund der neuen ACLs wurden die AdminDesk SSL-Zertifikatseinstellungen im Web-Interface von "[ AdminDesk ] LAN settings" nach "[ AdminDesk ] Integrated services" verschoben. Sollten Sie Ihr eigenes SSL-Zertifikat installiert haben, müssen Sie dieses nach dem Firmware-Upgrade erneut installieren.​
  ACHTUNG: Auch alle SNMP-Einstellungen wurden im Web-Interface nach "[ AdminDesk ] Integrated services" verschoben. Nach dem Firmware-Upgrade müssen Sie auch SNMP erneut konfigurieren.
• Es gibt nun ein vollautomatisches Diagnose-Tool, das Durchsatz, Packetloss, etc. für alle Interfaces testet. Bei Multichannel VPN Routern werden lokale Module sowie alle Module von gestackten Routern gemessen, ferner auch die VPN-Performance. Bei Multichannel VPN Hubs wird nur der Durchsatz von LAN- und WAN-Interfaces gemessen.
  Mithilfe dieses Tools werden erste Diagnosen in allen "Ich erreiche nicht die Leistung, die ich erwartet habe"-Fällen wesentlich einfacher. Wir legen Ihnen die Verwendung dieses Tools sehr ans Herz.
  Sie finden das "Connectivity diagnostics tool" innerhalb der "Logging & Maintenance"-Einstellungen (im alten Web-Interface, in der Beta des neuen Web-Interface ist diese Funktion noch nicht verfügbar).
• Sollten Sie optionale Routerfunktionen testen wollen, können Sie sich nun unter https://license.vipri.net/trial.php mithilfe des Trial-Tokens, den Sie im Web-Interface unter "Product features License Manager" finden, eine 30 Tage gültige, kostenlose Trial-Lizenz generieren lassen.
  Dieser Web-Dienst wird eine aktivierte Lizenzdatei generieren, die Sie dann im Web-Interface einfügen können. Die generierte Lizenz wird alle optionalen Funktionen des Routers für einen Zeitraum von vier Wochen aktivieren. Sie kann einmalig mithilfe des Webservers verlängert werden, wird danach aber für einen Monat gesperrt. Bitte beachten Sie, dass der Router am Ende des Testzeitraums automatisch rebooten wird.
  Achtung: Das Viprinet-Supportteam wird Trial-Lizenzen für Routerfunktionen nicht mehr manuell ausgeben. Bitte nutzen Sie stattdessen das Selbstbedienungssystem.
  Die Summe aller Bandbreiten vom/zum WAN auf allen Channels ist nun als Datenquelle für den Tunnel in der Monitoring API verfügbar.
• Einige Leistungsverbesserungen sorgen dafür, dass nun alle Produkte ca. 5-10% mehr Bündelungskapazität haben.

• Auf Hubs 5000 und Hubs 5010 gab es das Problem, dass unter gewissen Umständen das LAN-Interface blockieren und daher keine Pakete mehr empfangen konnte. Dieses Problem wurde behoben.
• Es gab verschiedene Fehler bezüglich des Hub-Redundanzsystems. Wenn viele Multichannel VPN Hubs in einem LAN-Segment eines Rechenzentrums betrieben wurden, funktionierte manchmal das Verteilen der Konfigurationsdatei nicht. Außerdem verursachte der Betrieb mehrerer Hotspare-Hubs in derselben Hotspare-Gruppe (was eigentlich eine gute Idee ist) manchmal (selten), dass zwei Hotspare-Hubs gleichzeitig die Identität eines ausgefallenen Aktiv-Hubs übernahmen, sodass es zu einem Adresskonflikt kam. All diese Probleme wurden behoben, sodass der Betrieb von mehreren Hotspares in einer Redundanzgruppe nun problemlos funktioniert.
• Manchmal unter seltenen Umständen konnten IP-Flows durch einen VPN-Tunnel steckenbleiben. In diesem Fall wurde im Log die Meldung "10001 packets in WANPacketHeap" ausgegeben. Diese Meldung trat manchmal bei Flows auf, die "für immer" (wie IPsec-Tunnel durch einen Viprinet-Tunnel) auf Systemen liefen, während der Viprinet VPN-Tunnel aufgrund instabiler WAN-Links oft abbrach. Flows sollten nun nicht länger steckenbleiben.
• Wenn BondingTCPOptimizer benutzt wurde, konnte es passieren, dass gewisse beschädigte TCP-Pakete ein Speicherleck verursachten. Ein Sturm dieser Pakete (z.B. während einer DoS-Attacke) konnte früher oder später für einen Reboot des Routers sorgen.
• Kleine Fehlerbehebung für BondingTCPOptimizer: Bei sehr langsamen Servern konnten Retransmissions von SYN-Paketen seltsames Verhalten bewirken. Tatsächlich beobachtet mit Samsung-Fernsehern und dem deutschen VoD-Dienst Maxdome.
• Die Konfliktlösung beim Restart von gestackten Routern wurde verbessert.

• Deutlich verbessertes Channel Bandwidth Autotuning. Sie bekommen nun viel bessere Ergebnisse für alle Arten von Verbindungen, speziell aber Sat-Verbindungen. Hybrid Autotuning bekommt nun viel bessere Ergebnisse bei seinen anfänglichen Tests auf VPN-Tunnels, die idle sind. Überlastung auf dem Channel wird nun Max Bandwidth To WAN wesentlich weniger drastisch senken, d.h. Sie werden bessere Leistung auf WAN-Links sehen, die viel Packet Loss zeigen.
• VLANs on Node werden nun auf folgende Art unterstützt:
  • In den LAN-Setting gibt es nun eine „Allow route-back“-Option. Wenn diese aktiviert wird, kann Traffic, der von einem VLAN kommt, zum selben oder einem unterschiedlichen VLAN zurückgeroutet werden – in anderen Worten, VLAN-Segmente können miteinander sprechen. Wenn die Funktion deaktiviert ist, wird Traffic vom LAN mit Ziel im LAN stattdessen gedroppt, sodass die VLANs in diesem Fall komplett separiert sind und nur mit dem VPN-Tunnel sprechen können.
  • Auf dem Node gibt es die Option „Allow all VLANs to talk to tunnel“. Wenn diese aktiviert ist, können alle VLANs mit dem Tunnel sprechen; wenn sie deaktiviert ist, kann das nur VLAN0.
  • In den WAN/VPN Routing-Einstellung auf dem Hub kann ebenso eine „allow route-back“-Option aktiviert werden. Wenn diese inaktiv ist, wird der Traffic, der vom Tunnel reinkommt und in denselben Tunnel gehen würde, gedroppt.

Mithilfe dieser Funktionen können Sie nun sowohl einen Router (Node) implementieren, der ein lokales VLAN hat, welches nicht mit dem VPN, dafür aber mit dem restlichen LAN sprechen kann, wie auch ein Setup erstellen, bei dem mehrere VLANs voneinander getrennt, aber in der Lage sein sollen, mit dem VPN zu sprechen (z.B. ein Firmennetzwerk und gleichzeitig ein öffentliches Besucher-WLAN).

Bitte beachten Sie, dass VLAN-Tags NICHT durch den Tunnel transportiert werden. Aus Sicht des Hubs kommt noch immer aller Traffic aus einem einzigen Tunnel mit einer einzigen Tunnel Segmentation ID. Wenn Sie die gerouteten Netzwerke separat behandeln müssen, müssen Sie ein VLAN auf dem Hub anlegen und den gesamten Traffic aus dem Tunnel zu einem Next-Hop in diesem VLAN routen, wo Sie dann den Traffic nach seinen Quell-IPs in mehrere verschiedene VLANs auftrennen.

• Auf allen Routern und Hubs findet sich nun ein integrierter HTTP Test-Traffic-Generator, der unter [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads aktiviert werden kann.

Wenn er aktiviert ist, können HTTP Test-Downloads von diesem Router gemacht werden ohne irgendeine Form der Authentifizierung. Dies sollte nur aktiviert werden, solange Sie selbst testen, und für Produktivsysteme deaktiviert werden.

Wenn diese Funktion aktiviert ist, kann ein zufälliger Datenstrom von diesem Router runtergeladen werden unter folgender URL:

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

Speed wird angegeben in Bit/s, 1K bedeutet 1Kbit/s, 1M bedeutet 1 MBit/s, 1G bedeutet 1 Gbit/s. Der Speed-Parameter ist optional. Wenn dieser Parameter nicht gegeben ist, wird die maximal mögliche Link-Geschwindigkeit genutzt. Der maximale erlaubte Wert ist 1G.

Size ist die Größe der herunterzuladenden Datei in Bytes, 1K bedeutet 1 Kbyte, 1M bedeutet 1 MByte, 1G bedeutet 1 GByte. Der Größen-Parameter ist optional, wenn er nicht gegeben ist, werden 16 GByte angenommen, also der maximale erlaubte Wert.

• Viprinet-Router beinhalten nun eine Sicherheitsfunktion, die vor den meisten bekannten Arten der DNS Amplification-Attacke Schutz bietet – eine einzelne IP darf jetzt nur 2 BELIEBIGE Anfragen innerhalb von 60 Sekunden stellen. Wir empfehlen weiterhin, in Ihrer Kern-Firewall ausgefeiltere Methoden zum Schutz vor DNS-Amp-Attacken zu installieren.
• Das Download-Test-Tool in den LAN- und Modul-Settings wurde erweitert und um einiges verbessert. Es kann nun Test-Dateien von einem weltweiten von Viprinet zur Verfügung gestellten Content Delivery Network runterladen, welches automatisch den Edge-Server wählt, der Ihrer Position am nächsten ist, oder – sofern der Hub diese Firmware nutzt – vom Hub Traffic-Generator runtergeladen wird. Hiermit haben Sie ein Tool, mithilfe dessen Sie einfach Ihre Verbindung und Durchsatzprobleme mit WAN-Interfaces testen, und überprüfen können, wo der Flaschenhals bzgl. Ihrer Bandbreite ist. Benutzen Sie es!
• In den Channel Feineinstellungen kann nun eine Minimum-Link-Stabilität definiert werden, die ein Channel haben soll; dabei wird eine Warnung ins Logsystem verschickt, wenn die Link-Stabilität diesen Wert unterschreitet. Für stationäre Installationen sollte ein aktiver Link mehr als 90% Stabilität aufweisen, bei sich bewegenden Fahrzeugen hängt das von der typischen Netzabdeckung ab. Mithilfe dieser Einstellung können Sie leichter automatische Benachrichtigungen einstellen, wenn Verbindungsprobleme auftreten (z.B. wenn eine SIM-Karte ihr Traffic-Limit erreicht).
• Die Monitoring AP, die vom Viprinet Monitoring Tool verwendet wird, verursachte eine hohe CPU Load auf dem überwachten Router. Diese Load wurde gesenkt.
• Früher verwendete das Konfigurationssystem (sowohl Web-Interface als auch CLI) eine globale Sperre, die den Routing-Kern für mehrere Sekunden komplett lahmlegte – z.B. konnte der Router, während LAN-Settings zugewiesen wurden, keine Pakete routen. Diese globale Sperre wurde nun entfernt, und das Arbeiten im Web-Interface sollte nicht länger solche drastischen Effekte auf die Routing-Leistung von Viprinet-Routern haben.

• Eine große Zahl an SNMP-Fehler wurde behoben. Am wichtigsten ist, dass Hotspare Hubs, die einen Hub übernehmen/ersetzen, nun korrekterweise normale volle Viprinet SNMP auf den übernommenen IPs berichten und Hotspare SNMP-Antworten auf der Hotspare IP ausgeben.
• SNMP ändert nicht länger OIDs auf anderen Tunnels, wenn ein Tunnel gelöscht wurde.
• SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature sind nun implementiert.
• Aufgrund einer Race Condition konnte Node Stacking manchmal in Failover-Situationen abstürzen. Auch der „Failed to open slot for stacking“-Fehler wurde behoben, sowie der interne Fehler 23239482394811Aa.
• Konfiguriertes Stacking zu deaktivieren konnte die falsche Fehlermeldung „[Stacking] This router does not have the stacking featured licensed. Can not start stacking!“ hervorrufen.
• Es konnte manchmal passieren, dass ein Node-Stacking Slave den internen DHCP-Server nicht beendete. Dadurch konnten zwei DHCPs auf dem LAN laufen, wodurch es zu Problemen kommen konnte.
• Der Firmware Online-Updater erforderte immer das DOPPELTE Klicken auf „check for updates now“, um ein aktuelles Ergebnis zu bekommen. Nun funktioniert schon der erste Klick.
• ADSL-Module hatten manchmal Probleme damit, die Modul-Info zu lesen zu lassen. Wir haben den Timeout für das Warten auf die Antwort vom Modem-Diagnostik-Bericht erhöht. Bitte benachrichtigen Sie den Viprinet-Support, wenn Sie beim Auslesen der Modul-Info eines ADSL-Moduls immer noch Fehlermeldungen bekommen.
• Alles im Bezug auf „Ethernet speed and auto-negotiation settings“ wurde überarbeitet. Es gab an allen Ecken und Enden Fehler: Das Ausschalten der Auto-Negotiation bei manchen Produkten und Ethernet-Modulen funktionierte nicht; das Ausschalten der Auto-Negotiation wurde beim nächsten Router-Reboot ignoriert; und zahlreiche andere. Alle wurden behoben, und wir haben sichergestellt, dass das manuelle Setzen von Ethernet Parametern nun bei allen Produkten und Modulen funktioniert, auch nach Reboots.
• Die „Reconnect“-Funktion von Fast/Gigabit Ethernet Modulen verursacht keinen PHY Reset / Neustart der Ethernet Auto-Negotiation mehr. Wenn Sie das möchten, müssen Sie das Modul jetzt resetten.
• VLANs und eine MTU von 1500 zu nutzen funktioniert bei Fast Ethernet Modulen nicht (mit Gigabit Ethernet Modulen hingegen schon). Nun funktioniert es bei beiden Modulen.
• Es konnte passieren, dass der Routing-Kern aufgrund von Rundungsfehlern in der Praxis oft mehr durchschnittliche Bandbreite auf einen Channel schickte als der „Maximum Allowed Bandwidth to WAN“-Wert erlaubte. Bei manchen Verbindungstypen konnte das dazu führen, dass der Link überlastet wurde und die Latenz trotz perfekter Autotuning-Resultate stieg. Diese Rundungsfehler wurden behoben.
• Seit der letzten Stable Firmware-Version werden Änderungen bei LAN-Einstellungen inkl. LAN Aliases übernommen noch bevor der Knopf „Apply Settings“ gedrückt wird. Das konnte für einen unsauberen Zustand sorgen, wenn man gerade dabei war, einen LAN Alias anzulegen.
• Wenn „Allow remote service connections“ eingeschaltet war und dann ausgeschaltet wurde, konnte es passieren, dass Remote Service-Verbindungen weiterhin möglich waren, bis der Router rebootet wurde. Das Ausschalten dieser Funktion hat nun direkt den erwarteten Effekt.
• Das Download Test-Tool konnte oft abstürzen „due to high CPU load“, selbst wenn die CPU Load gar nicht hoch war.

• Der Code für die Überwachung der LTE-Module wurde komplett überarbeitet. Diese Firmware-Version unterstützt nun zum ersten Mal vollständig die Modulversionen 10-01031 und 10-01032 für die USA und Kanada. Nun können auch die verwendeten Technologien besser analysiert werden; der Code meldet außerdem die/das aktuell genutzte Frequenz/Band.
• Der Startup-Code für Viprinet Router wurde optimiert. Dadurch geht die Inbetriebnahme eines Viprinet Hubs mit tonnenweise Tunneln nun wesentlich schneller vonstatten.
• Die Router haben nun eine maximale Anzahl an Tunneln, die konfiguriert werden können.​
  WICHTIGER HINWEIS: Das bedeutet nicht, dass der Router tatsächlich in der Lage sein wird, so viele Tunnel gleichzeitig bei annehmbarer Leistung zu halten - dies hängt auch von der Anzahl der Channels pro Tunnel und von der Komplexität der QoS-Regeln ab.
  Hier ist die Anzahl maximal zulässiger Tunnel je Produkt:
  • 300: 25
  • 500: 25
  • 1600/1610/2610/1620/2620: 50
  • 1000/1020: 100
  • 2000/2020: 150
  • 5000/5010: 500
• Bis jetzt nutzte das Hub-Redundanzsystem ausschließlich Ethernet-Broadcast bei der Kommunikation von Hubs untereinander. Aufgrund einer technischen Limitierung im verwendeten Kommunikationsprotokoll konnten Hubs nur dann Konfigurationsdateien teilen, wenn deren komprimierte Größe unter 64k lag. Leider war der Benutzer nicht in der Lage, herauszufinden, wie groß die aktuelle Konfiguration ist. Wenn die komprimierte Konfigurationsdatei etwas größer war als 64k, versagte das Hub-Redundanzsystem beim Synchronisieren der Konfigurationsdateien. Bei einigen Hub 5010-Installationen mit einer großen Anzahl an Tunneln und QoS-Konfigurationen wurde diese Limitierung tatsächlich auch erreicht.
  Zusätzlich gab es beim Broadcasting Protocol ein grundsätzliches Problem: Wenn viele VPN Hubs zur gleichen Zeit im Betrieb waren, konnte es bei mehreren Hubs passieren, dass sie ihre Konfiguration exakt zur selben Zeit an den Hotspare schickten. In diesem Fall erhielt der Hotspare aufgrund von Fragmentierung manchmal überhaupt keine Konfiguration. Dieses Problem verschlimmerte sich, wenn in einer einzelnen Redundanzgruppe mehrere Hotspares liefen.
  Wir haben das Hub-Redundanzsystem so verbessert, dass die hauptsächliche Kommunikation noch immer über Broadcasts läuft, für die Übertragung von Konfigurationsdateien aber nun eine direkte TCP-Verbindung zum Hotspare aufgebaut wird. Daher ist die Größe der Hub-Konfigurationsdateien nun unlimitiert. Das neue Protokoll wurde abwärts kompatibel gestaltet. Das bedeutet dass Hotspare Hubs, die mit derselben Cutting Edge-Firmware laufen, immer noch produktive Hubs bedienen können, die mit der Stable Firmware-Version laufen und ihre Konfiguration noch nicht per TCP synchronisieren können. Wir empfehlen dennoch, bei allen Hubs in einer Redundanzgruppe dieselbe Firmware-Version zu verwenden.
• Bis jetzt konnte es passieren, dass Viprinet-Router manchmal Traffic als nicht routbar markierten, wenn der Tunnel down war, während der Traffic-Flow aufgebaut wurde. Seit der letzten Stable Firmware-Version wurde diese Restriktion noch etwas strenger: Jeglicher Traffic-Flow, der aufgebaut wurde, bevor der Tunnel bestand, wurde für immer als nicht routbar markiert. Wir haben nicht erwartet, dass das je ein Problem wäre - die meisten gesunden Protokolle brechen bei so etwas ohnehin ab und verbinden neu. Das ist aber z.B. bei ISAKMP von IPSec nicht der Fall, einem völlig hirnverbranntem Protokoll: Es nutzt per Konvention immer den UDP Quell- und Zielport 500. Dadurch wird es unmöglich, zwischen diesen ISAKMP-Flows zu unterscheiden, was unter anderem auch bei NAT Gateways Probleme verursacht. Bei Viprinet wurde, wenn ein IPSec Gateway einen IPSec-Tunnel aufbaute, bevor der Viprinet-Tunnel bestand (z.B. weil der Viprinet-Router, aber nicht das IPSec Gateway rebootet wurde), der ISAKMP-Flow als permanent nicht routbar markiert. Das konnte passieren, weil das IPSec Gateway nie "abbrach", und selbst wenn, dann würde ein neues IPSec-Setup genauso aussehen wie das alte, da die UDP Quell- und Zielports sich nicht änderten.
  Wenn also das IPSec Gateway keine vernünftigen Timeouts benutzt, konnte es passieren, dass IPSec-Tunnel durch einen Viprinet-Tunnel für immer stecken blieben.
  Das verursachte keine Probleme mit IPSec Gateways, die wir intern testen konnte, denn diese warteten einfach einige Sekunden vor einem erneuten Versuch, falls der ISAKMP-Handshake fehlschlug. Bis dahin zeigte der Flow vom UDP-Port 500 im Viprinet-Router eine Zeitüberschreitung, und das neue ISAKMP-Setup wurde als neuer Flow betrachtet, der dank des Viprinet-Tunnels nun als routbar markiert wurde.
  Wie wir gelernt haben, verhalten sich nicht alle IPSec Gateways so - einige hämmern ohne Unterlass für den Fall, dass der ISAKMP-Handshake nicht funktioniert. Das ist unklug, aber leider Realität.
  Wir haben das Routing-Design innerhalb der Viprinet-Router so geändert, dass nun diese Art von Problemen bewältigt werden kann, während die Geräte weiterhin optimale Leistung bringen.
  Traffic-Flows, die als unzulässig/nicht routbar markiert werden, werden nun alle 2 Sekunden darauf überprüft, ob es in der Zwischenzeit möglich geworden ist, sie zu routen. Auf diese Weise haben wir weder hohe Last durch Systeme, die den Router mit nicht routbaren Ziel-IPs fluten (was zumindest eine Art von DoS ermöglichen würde), noch haben wir Probleme mit Protokollen, die immer denselben Flow hämmern, während der Viprinet-Tunnel noch nicht aufgebaut ist.
  ​Es ist unmöglich, alle verfügbaren IPSec Gateway-Kombinationen zu testen, aber bei denen, die wir testen konnten, wurden IPSec-Tunnel typischerweise nach einigen Sekunden (wieder) aufgebaut, nachdem auch der Viprinet VPN-Tunnel wieder kam.

• Die vorherige Cutting Edge Firmware-Version funktionierte nicht mit der 50-00500 Projektrouter-Serie. Das Problem wurde mit dieser Firmware-Version behoben.
• Ein Fehler wurde behoben, der durch einen SSL Handshake-Feler unter seltenen Umständen den Aufbau eines Tunnel-Channels zum VPN Hub abbrechen lassen konnte.

• Die Logik, anhand derer die Konfiguration eines anderen Routers darauf geprüft wurde, womit sie kompatibel ist, wurde neu geschrieben. Jetzt werden Projektrouter als mit sich selbst kompatibel markiert (ein anderer Router gleichen Modells und gleicher Projektnummer) und mit dem Standardmodell des übereinstimmenden Produkts.
  Beispiel:
  50-00300 ist kompatibel mit 50-00300 und 01-00300, aber inkompatibel zu 51-00300.
• Die drei verschiedenen Arten von LTE-Modulen benennen sich ab jetzt automatisch nach "LTE 700 AWS/UMTS/HSPA+/GPRS/EDGE" / "LTE/UMTS/HSPA+/GPRS/EDGE" / "LTE 700/CDMA/EV-DO" um, sobald das Chipset-Modell identifiziert wurde.
• Mit einem Hub verbundene VPN-Clients verwenden nun Hybrid Autotuning statt Heuristic auf dem Hub. Dadurch wird das Volumen an Test-Traffic in solchen Situationen reduziert, wenn die WAN-Konnektivität des PCs sehr instabil ist (z.B. bei einem Laptop-User, der in einem sich bewegenden Zug sitzt).
• Dieses Release enthält zum ersten Mal Firmware-Builds für die kommenden Multichannel VPN Router-Modelle 511 und 512.
• Im neuen Web-Interface gibt es nun die Tools "Module info", "Interface info" und "ARP table". Trotzdem fehlen noch viele der Tools aus dem alten Web-Interface, z.B. Ping, Traceroute und der Download-Test. Diese werden beim nächsten Release hinzugefügt.

• Das vorherige Cutting-Edge-Release unterstützte CDMA450-Module nicht, die entsprechenden Slots wurden als leer angezeigt. In diesem Release wurde der Support für diese Module wieder hinzugefügt.
• Die CLI sollte nun korrekterweise Int64- und Float-Werte unterstützen, daher sollten Sie nun in der Lage sein, GPS-Positionsdaten mithilfe der CLI auszulesen.
• Bei den LTE-Modulen war der Wert "Expected link capacity" falsch gesetzt, wenn die Module HSDPA nutzten. Dieser Fehler war in der EU sehr selten zu sehen, da man hier normalerweise HSPA+ anstatt HSDPA nutzt (=HSUPA und HSDPA+). Wenn HSUPA mit HSDPA kombiniert wurde, erreichte die Expected link capacity 348 kbit/s im Downstream, wodurch Autotuning ausgelöst wurde. In den USA trat dieser Fehler häufig bei Verwendung der Module mit AT&T und T-Mobile auf.
• Beim Routermodell 300 konnten wir Pufferüberläufe auf dem LAN-Interface sehen, wenn plötzlich eine große Menge an Paketen zum LAN gesendet wurde. Das passierte z.B. bei der Bündelung instabiler Verbindungen, bei denen Daten nach Packet-Loss/Retransmissions in großen Mengen übertragen wurden. Dieses Problem verursachte verlorene Pakete auf dem LAN, und diese verlorenen Pakete lösten TCP-Retransmissions auf der Anwendungsebene aus, wodurch der erreichbare Durchsatz bei Verbindungen mit hoher Latenz ziemlich eingeschränkt werden konnte. Das Problem besserte sich nach einigen Stunden von selbst. Allerdings bedeutete das, dass 300er in Demo-Situationen (nur eingeschaltet, um UMTS/LTE zu bündeln) instabile Download-Geschwindigkeiten erreichten.​
  Dieses Problem sollte jetzt behoben sein.
  Um das zu überprüfen, rufen Sie "[ AdminDesk ] LAN settings -> Ethernet interface info tool" auf.
• Dort sollten die "Overruns"-Zähler für TX und RX immer bei 0 bleiben.
• Ein Fehler beim BondingTCPOptimizer wurde behoben: Manche Geräte konnten beim Senden eines Zero Window steckenbleiben, da der Linux-Stil des Window-Probing, den Viprinet nutzt, ignoriert wurde. Wir haben nun auch ein zufälliges Window-Probing im Windows-Stil eingerichtet (das versucht, Daten außerhalb des Fensters zu senden). Dadurch wird künftig verhindert, dass Video-Streams bei Samsung Smart TVs hängen bleiben.
• Diese Firmware-Version beinhaltet vorläufige experimentelle Unterstützung für die kommenden neuen VDSL-Module.
• Die Testlizenz-Funktion, die in früheren Cutting-Edge-Firmware-Versionen eingeführt wurde, war fehlerhaft: Damit generierte Testlizenzen wurden nie ungültig.

• Das neue Web-Interface ist nun feature-complete, und alle bekannten Fehler wurden beseitigt. Es wird nun auch als Standard verwendet.
• Für die Nutzung des Web-Interface-Zugangs wird HTTPS empfohlen.
• Die Verschlüsselung für das Web-Interface wurde deutlich verbessert. Wir nutzen nun einen 2048-bit RSA-Schlüssel mit SHA256-Zertifikaten, TLS 1.2 und Perfect Forward Secrecy (Diffie-Hellman-Schlüsselaustausch mit Hilfe Elliptischer Kurven). Bei SSLabs erzielen Viprinet-Router Bestnoten.
• Die Verschlüsselung für VPN-Tunnel wurde ebenfalls aktualisiert. Zusätzlich nehmen die VPN-Router nun einen Fingerabdruck des SSL-Zerfitikats des VPN-Hubs und lehnen die Wiederherstellung einer Verbindung ab, wenn sich der Fingerabdruck ändert. Das ist so geregelt, dass sich der Fingerabdruck weder beim Bearbeiten der Redundanz-Einstellungen von VPN-Hubs ändert noch beim Verschieben einer VPN-Hub-Konfiguration zu einem neuen VPN-Hub. Das neue System verhindert eine theoretische Man-in-the-Middle-Attacke gegen unsere Produkte, bei der ein Angreifer ein Gerät vor einem VPN-Hub installiert, das dessen IP-Adresse stiehlt und sich als dieser Hub ausgibt.
• Bei multiplen Authentifizierungsfehlern auf der SSH-CLI werden weitere Login-Versuche von derselben IP nun gedrosselt. Dies erschwert Brute-Force-Attacken auf SSH enorm.
• Channel Bandwidth Autotuning wird nun standardmäßig keine Log-Nachrichten mehr generieren. Das reduziert deutlich die Anzahl an Logzeilen, die auf beschäftigten VPN-Hubs mit vielen Tunneln/Channels generiert werden. Das Logging kann per Channel wieder eingeschaltet werden.
• Channel- und WAN-Bandbreiten-Berichte werden nun nur alle 10 Sekunden aufgezeichnet; wenn die Verbindungsgeschwindigkeit eines WAN-Gerätes unbekannt ist, wird sie nun nicht mehr aufgeführt, anstatt bisher mit "0/0" protokolliert zu werden.
• Unsere neuen VDSL-Module werden nun voll unterstützt.

• Wir haben eine potenzielle Downgrade Attack auf das VPN-Tunnel-Protokoll behoben. Bei einer Man-in-the-middle-Attacke konnte ein Angreifer einen VPN-Router dazu zwingen, auf eine veraltete Viprinet VPN-Tunnel-Protokoll-Version zurückzuschalten, bei der das Tunnel-Passwort in Klartext über die SSL-Verbindung gesendet wurde. Auf diese Weise konnte das Tunnel-Passwort gestohlen werden und ein falscher, vom Angreifer betriebener VPN-Router konnte sich anstelle des echten zum VPN-Hub verbinden, wo er Zugang zum VPN erlangen konnte. Wir möchten an dieser Stelle der Firma Portcullis Security für ihre Forschung und ihre Beratung in dieser Sache danken. Die alten VPN-Tunnel-Protokoll-Versionen wurden deaktiviert.
• Sowohl im alten, als auch im neuen Web-Interface wurde Eingaben nicht richtig gefiltert, sodass eingeloggte Benutzer alle Arten von Cross-Site-Scripting-Attacken (XSS) ausführen konnten. Alle bekannten Attacken werden nun ordnungsgemäß gefiltert.
• Ab dieser Firmware-Version ist es nun nicht länger möglich, Objekte (Tunnel, Channel, etc.) mit unzulässigen Zeichen anzulegen. Existierende Objekte werden weiterhin geladen. Überprüfen Sie Ihre Log-Dateien für kritische Warnungen diesbezüglich und benennen Sie alle Objekte mit unzulässigen Sonderzeichen um – mit der nächsten Firmware-Version werden diese Objekte nicht länger geladen werden.
• Hybrid Autotuning zeigte einen Fehler, der dazu führen konnte, dass MaxBandwidthToWAN auf „0“ gesetzt wurde und bei diesem Wert blieb.
• Wenn mehrere Benutzer mit demselben Benutzernamen im Web-Interface eingeloggt waren (egal ob altes oder neues), konnte jeder Benutzer nur einen Teil der Log-Nachrichten sehen.
• Wenn Channel Bandwidth Autotuning für einen verbundenen Channel ausgeschaltet war und MaxBandwidthToWAN manuell auf „0“ gesetzt wurde (wie es manchmal auf dem VPN-Hub gemacht wird, um nicht den Downstream einer teuren UMTS-/LTE-Verbindung nutzen zu müssen, sondern sie nur als Upstream-Booster zu verwenden), konnten bizarre Effekte auftreten. Wenn besagter Channel die niedrigste Latenz, die beste LinkStability oder den niedrigsten Kostenwert hatte, konnte es passieren, dass QoS-Klassen diesen Channel bevorzugt zur Nutzung auswählten, obwohl sie keinen Traffic durchleiten konnten. Daher konnten diese QoS-Klassen keinen Traffic mehr transportieren. Channels mit Bandbreite „0“ werden nun vom QoS-System ignoriert.
• In einem Node-Stacking-Setup konnte manchmal ein DHCP-Dienst auf einem Slave-Gerät laufen, obwohl er das nicht sollte.

• Der neue Multichannel VPN Router 200 wird nun unterstützt (dieser wird erstmals auf der CeBIT 2014 zu sehen sein).
• Die neuen verbesserten Sicherheitsfunktionen verursachten auf dem Hub mehr Last, wenn ein Channel aufgebaut war. Wenn nun eine große Anzahl Channels gleichzeitig zum Hub verbanden, konnte die große Last eine Art DoS auf dem Hub verursachen, was wiederum eine Feedback-Schleife für die Last auslösen konnte: Aufgrund der hohen Last konnten die SSL-Handshakes der Channels nicht innerhalb der Timeout-Zeit durchgeführt werden, weshalb die Channel immer wieder abbrachen und sich neu verbanden, wodurch noch mehr Last produziert wurde.
  Das konnte man in der Realität beobachten, wenn man einen Hub rebootete, der aufgrund vieler Tunnel schwer belastet war, z.B. nach einem Firmware-Upgrade.
  Wir haben nun eine Drosselung auf dem Hub und auf dem Router implementiert. Wenn nun ein Channel während des Verbindens zu einem Hub abbricht, wird er gedrosselt, anstatt auf den Hub mit Verbindungen einzuhämmern. Auf der Hub-Seite wird, wenn die CPU-Last hoch ist, die Annahme neuer Channels verzögert, ohne dass es zu einem Timeout kommt.
  Durch diese Änderungen ist die neue Cutting-Edge-Version in der Lage, eine höhere Channel-Verbindungslast auf dem Hub zu verarbeiten, als die aktuelle Stable-Firmware (deren SSL-Handshake noch dazu weniger sicher ist).
• Das Verhalten von Routern und Hubs während einer DoS-Attacke wurde verbessert. Wenn von einem Quell- oder Zielhost mehr als 25.000 Flows (TCP-Verbindungen) eingingen, konnte dieser Host geblockt werden. Wenn jedoch die Hub-IP attackiert wurde, konnte es passieren, dass die Hub-IP selbst geblockt wurde; dadurch wurde das Web-Interface des Hubs unerreichbar, bis z.B. ein TCP SYN Flood DoS vorbei war. Nun werden lokal gebundene Router-IPs nicht mehr geblockt. Außerdem verursachte die Log-Menge während DoS-Attacken eine ziemliche CPU-Last; das wurde reduziert. Ein blockierter Host wird nun nur einmal geloggt, und erst dann wieder, wenn er nicht mehr blockiert wird (was passiert, sobald die Zahl an aktiven Flows wieder unter 24.000 sinkt).
• VDSL-Module erlauben nun das Aufsetzen eines VLAN.
• VDSL-Module unterstützen nun RFC1483 mit statischen IPs, und erlauben Sonderzeichen in PPP-Benutzernamen und Passwörtern.

• Wenn man bei der vorherigen Cutting-Edge Firmware-Version mehrere Channel mithilfe der Multiedit-Funktion im neuen Web-Interface bearbeitet hat, benutzten nach dem Speichern der Änderungen alle Channels ein einziges (das erste) Modul. Nach dem nächsten Channel-Reconnect benutzte aber jeder Channel dasselbe Modul, weswegen es passieren konnte, dass die Performance erst Stunden nach den Änderungen abstürzte. Dieser Fehler wurde beseitigt.
• Die Multichannel VPN Router 511, 512 und 513 zeigen nun den korrekten Produktnamen im Web-Interface an.

• If you have Streaming Optimizations licensed, there now is a new bandwidth autotuning mode available: “Rapid Autotuning”. This mode is optimized for 3G/4G links used in vehicles moving at high speeds, while using multiple different carriers at the same time. Rapid Autotuning is similar to Passive Autotuning as it does not generate any artificial test traffic; it is, however, far more aggressive. In a moving vehicle, cell tower changes will happen very often, as will short spikes of packet loss. With existing autotuning modes, these often would cause the channel to re-start testing at very low speeds. Rapid Autotuning instead aggressively re-establishes the previous bandwidth after a short spike of packet loss and/or a cell tower change. Compared to Hybrid and Passive Autotuning, the amount of throughput with Rapid Autotuning has doubled in our tests in high-speed vehicles. If you are using bonded 3G/4G in moving vehicles, you most definitely should start using this mode.
• The new LTE module “10-01036 LTE/UMTS/HSPA+/GPRS/EDGE (AUS)” for Australia is now fully supported.
• The performance of the new web interface for Hubs where a lot of log messages are scrolling through has been highly improved. It's now finally usable even on busy Hubs.
• For all password fields, there now is a “change password” dialogue, which also measures and displays password strength.
• LTE modules that get rejected from the network now behave much nicer. Instead of  constantly hammering the carriers' networks, they now exponentially back off in case of multiple connection failures.
• The APN database got updated. Now, there internally is also a dedicated APN database  for carriers that uses an APN on LTE that is different from the one on UMTS. Due to this, it is now possible to have APN Auto Configuration enabled for almost any carrier. Also, APN Auto Configuration from now on is by default turned on for all UMTS/LTE modules (before it had been turned off by default).
• Internal time-outs for packet flows have been reduced. This is especially the case for TCP connections through the tunnel that ended by both sides having done the FIN/ACK close. These changes should be invisible to customers, with one exception: During a DoS attack against a network connected by a Viprinet router, the system load will now be dramatically lower.
• When a tunnel was down, every packet arriving for this tunnel would generate a “Dropped packet from LAN as Tunnel is down” warning log message. This message has been removed.
• The “AT command tool” is now also available for CDMA450 modules.

• On 5XX Routers, viewing configuration objects that contained combo boxes (Drop-down selection lists) could result in an internal error.
• The module info could not be read from VDSL modules in the new web interface, only in the old one. It now works in both.
• If an Ethernet module had its “Expected Link Speed” setting not on automatic mode but manually configured, this could confuse the “Online” LED control of that module if you pulled out the Ethernet cable and plugged it back in again.
• Even if the registration on a network hadn't been completed yet, LTE modules would already try to establish a data connection to that network. This would cause log messages complaining that the data connection failed due to lack of service. The modules now won't try to establish a data connection before coverage exists and network registration has been completed.
• Since the current Stable Firmware release, the routers would automatically save the configuration after start-up. This was done so that automatically generated SSL/SSH private keys would get stored to disk. However, in rare cases, modules in the router would not have fully started up by the time the configuration was saved, causing the router to save a config with some modules missing. If you now at some point rebooted the router without ever before having changed something in the web interface (causing the config to be saved), you could lose your module config on the next boot. Now, whenever a module is inserted or removed into a router, the configuration automatically will be saved. Due to this, you will no longer lose your configuration in the case described above.
• The Hub Redundancy System in the latest Stable Firmware release contained forgotten debug log messages. These have now been removed. Also, the amount of logging for the Hub Redundancy System during times where everything is fine has been drastically reduced.
• Some recent versions of our CDMA450 modules would always start up in power-save mode, never waking up from that. With this firmware release, these modules are now woken up during initialization.
• In some cases, uploading files to the router (QoS configuration restore, manual firmware update) through HTTPS could fail with a “Bad Request” error.
• In the current Stable release, every request to the old web interface is delayed between 1–2 seconds, making things really slow. While we highly recommend to move to the new web interface, this “punishment” for using the old web interface surely wasn't intended and is now fixed.
• In a stacking setup, the log message “New effective physical link capacity to WAN (based on remote report)...” for remote interfaces (those located on a slave router) would cause internal errors on the stacking master. After 1000 of these internal errors, the stacking master would reboot. This is now fixed.

• Hubs und Router tauschen nun „Boot IDs“ aus, sodass die jeweils andere Seite informiert wird, ob die Gegenstelle neugestartet hat, und entsprechend den Flow State leeren kann.
• Erweiterte Einstellungen für VDSL sind jetzt verfügbar.
• Viprinet Managed SIMs werden nun unterstützt.
• Wartungsverträge werden nun von der Firmware unterstützt.
• Neue Einstellung zum Feinkonfigurieren von Channels „RapidReconnects“: Wenn aktiviert, zeigen Channels ein sehr aggressives Reconnect-Verhalten, dass beinhaltet, das WAN-Modul neu zu starten, wenn ein Channel für längere Zeit stillsteht. Schalten Sie diese Option nur ein, wenn der Router in einem Hochgeschwindigkeitsfahrzeug zum Einsatz kommt, das sich typischerweise bei 100km/h und schneller bewegt.
• Wenn ein Konfigurations-Backup wiederhergestellt wird, gibt es nun die Option „Do not overwrite existing licenses“. Wenn aktiviert, bleiben Lizenzen, die vor dem Backup an den Router gebunden wurden, intakt.
• Neue Funktion „Clear dynamic leases“ innerhalb der DHCP-Server-Einstellungen.

• Wenn Latency Autotuning für eine Channel ausgeschaltet ist, wird der Channel keinen Pingtest mehr durchführen, wenn er von ConnectedStalled auf Connected wechselt. Auf diese Weise kann der Channel nach einem kurzen Stillstand sehr viel schneller wieder genutzt werden (z.B. wenn ein Fahrzeug durch einen Autobahntunnel fährt).
• In sehr seltenen Fällen (Hochgeschwindigkeitszüge) konnten LTE-Module so abstürzen, dass der Router sie immer noch für verbunden hielt – im Zweifelsfall für immer. Ein neuer Wächter-Code stellt nun sicher, dass solche „eingefrorenen“ Module automatisch powercycled werden.
• LTE-Module geben nun Cell-IDs korrekt wieder (vorher zeigten sie typischerweise „0“ als Cell-ID).
• Die Empfängerseite eines BondingDiversity Flow hatte ein ernstes Speicherleck, welches nach einiger Zeit verursachte, dass dem Gerät der Hauptspeicher ausging.
• Wenn die Stromversorgung auf 5XX-Routern während eines bestimmten Moments beim Hochfahren unterbrochen wurde, konnte der Firmware-Speicher beschädigt werden, was dazu führen konnte, dass der Router nicht mehr in der Lage war, hochzufahren. Dies wurde in solchen Installationen beobachtet, bei denen der 5XX-Router in einem Auto verwendet wurde, das oft für nur für ein paar Sekunden angelassen und dann wieder abgestellt wurde.
• Die SSH-CLI lauscht nicht mehr auf WAN-Interfaces, da diese nicht durch eine ACL kontrolliert werden können.
• Einige Objekte im Web-Interface von früheren Firmware-Versionen ignorierten Löschversuche, z.B. Lizenzen und gestackte Router. Nun können diese Objekte erfolgreich gelöscht werden.
• Die Zeitzonenverwaltung bei 5XX-Routern war bei allen früheren Firmware-Versionen fehlerhaft. Dadurch waren Berichte für den Traffic-Bericht-Server mit falschen Zeitstempeln versehen, und Webbrowser nahmen auch keinerlei Elemente aus dem Web-Interface in den Cachespeicher auf.
• Die QoS-Klassen-Einstellung „Required Link Stability“ wurde aufgrund eines Fehlers in allen Firmware-Versionen im letzten Jahr größtenteils ignoriert. Deswegen konnte ein instabiler Channel den Traffic-Durchsatz des Tunnels ruinieren, auch wenn der instabile Channel eigentlich nicht genutzt hätte werden dürfen. Diese Fehlerbehebung bringt daher eine deutliche Durchsatzverbesserung für Setups, in denen instabile Links gebündelt werden (z.B. in Fahrzeugen).
• CDMA450-Module konnten abstürzen, wenn man sie in einem 5XX-Router resettete. Die  Reset-Option für diese Module wird daher nun ignoriert.
• Die diversen Formen von Download-Tools im Web-Interface hatten Probleme auf 5XX-Routern. Dort konnten diese Tools steckenbleiben oder abbrechen.
• Die Benutzerrechteverwaltung für WAN-Module war nicht persistent, entsprechende Einstellungen gingen beim Routerneustart verloren. Im neuen Web-Interface konnten Userrechte-Einstellungen für WAN-Module überhaupt nicht vorgenommen werden. Dies funktioniert nun, man kann nun auch Nicht-Root-Usern Rechte für WAN-Module zuweisen.
• Das Download Test Tool brach den Download nicht ab, wenn das entsprechende Fenster im neuen Web-Interface geschlossen wurde, stattdessen lief der Download im Hintergrund weiter. Das verursachte ggf. unnötigen Datentraffic.

• Leider beinhaltete die Cutting Edge Firmware-Version von Juli einen Compiler-Fehler für die Router-Serien 200, 500 und 51X. Dieser Fehler kann subtiles und schwer zu entdeckendes eigenartiges Verhalten verursachen. Aber schlimmer noch, wenn Hosts viele Traffic-Flows durchführen, kann es passieren, dass diese Traffic-Flows auf dem Router früher oder später stecken bleiben – der Router bezichtigt dann fälschlicherweise den Host einer DoS-Attacke und erlaubt von diesem keine neuen Flows mehr.
  Dieser Fehler bewirkt faktisch, dass einige oder alle Ihrer Hosts im LAN nach einiger Betriebszeit nicht mehr mit dem Router oder dem VPN/Internet sprechen können!
  Wir raten daher all unseren Kunden, die auf Routern aus den Serien 200, 500 und 51X die Cutting Edge Firmware-Version von Juli installiert haben, DRINGEND, auf die aktuelle Version zu updaten! Kein anderes Produkt ist von diesem Fehler betroffen. Wir entschuldigen uns für Ihre Unannehmlichkeiten und haben unsere internen Test-Setups entsprechend umgebaut, um ähnliche Fehler in Zukunft rechtzeitig entdecken zu können.
   
• Neue Option zur Feinkonfiguration von Channels „Save traffic when idle“: Diese wird für Vodafone UK benötigt, damit stagnierende Channels nicht aus der UMTS-Funkzelle und in einen seltsamen Hochlatenz-Idle-Modus geworfen werden. Dieser Idle-Modus bewirkt, dass Modems mit sehr geringem Traffic konstant aus UMTS-Funkzellen geschmissen werden, sodass sie sich neu einloggen müssen. Dadurch verursacht er eine Idle Link-Latenz von über 350ms und einen plötzlichen Anstieg von Paketverlust und/oder Latenz auf bis zu 2500ms, wann immer der Channel versucht, wieder erhebliche Mengen an Bandbreite zu übertragen - nach diesem Anstieg normalisiert sich das Verhalten des Netzwerks wieder. All das kann bzgl. erreichbarem Durchsatz und Channel-Autotuning viele Probleme verursachen. Wir glauben, dass das, was Vodafone da tut, eine schreckliche Idee ist und Standards erheblich verletzt, müssen aber dennoch damit umgehen.
  Die neue „Save traffic when idle“-Option ist standardmäßig eingeschaltet, wodurch das Verhalten des Routers dasselbe ist wie bei früheren Firmware-Versionen, bei denen es diese Option noch nicht gab. Wenn Sie diese Option deaktivieren, wird mehr Idle-Ping-Traffic generiert (ca. 10–15 KBit/s), damit sichergestellt wird, dass das Modem nicht aus der UMTS-Funkzelle gekickt wird. Allerdings werden Sie dadurch mehr Traffic verbrauchen. Wir empfehlen daher, diese Option nur beim Einsatz im Vodafone UK-Netzwerk zu deaktivieren.
  Eine alternative Lösung für das Problem ist, Latency Autotuning für Channels, die Vodafone UK-Netze nutzen, zu deaktivieren und innerhalb der Konfiguration für Channels einen „Optimal Latency below“-Wert von 400ms und einen „Maximum allowed Latency“-Wert von 2500ms zu wählen. Auf diese Weise bleibt der Channel auch dann nutzbar, wenn Vodafone UK den Idle-Modus aktiviert.
  Außerdem kann unser 3G-Monitoring-Code jetzt diesen seltsamen Idle-Modus entdecken und wird ihn entsprechenden Monitoring Tools als Registrierungsstatus „Normal / Idle“ berichten.

• Seit letzter Woche wurden zahlreiche Exploits in der häufig genutzten Bash-Shell entdeckt. Während wir die Bash-Shell nicht direkt dort einsetzen, wo sie mit der Außenwelt in Kontakt käme, wird sie vom DHCP-Client-Dienst genutzt, der für die WAN-Module läuft. Es gibt einen unbestätigten möglichen Angriffsvektor, der bewirkt, dass wenn ein Angreifer in der Lage wäre, einen kompromittierten DHCP-Server an ein Viprinet WAN-Ethernet-Modul anzuschließen und wenn dieses Ethernet-Modul dann konfiguriert würde, um DCHP zu nutzen, dann könnte der Router mithilfe manipulierter DHCP-Optionen dazu gebracht werden, Code auszuführen.
  
  Diese Firmware-Version beinhaltet alle veröffentlichten Patches für Bash und behebt daher nach unserem Erachten alle bekannten Schwachstellen.
  
  Bis Sie Ihren Router auf die neue Version aktualisiert haben, können Sie einen potentiellen Angriffsvektor auch dadurch schließen, dass Sie DHCP auf WAN-Ethernet-Modulen abschalten und diese stattdessen auf eine statische IP konfigurieren.
  
  Soweit wir wissen, gibt es für VPN Hubs keine solchen Angriffsvektor und es gibt auch keinen Angriffsvektor für irgendeinen unserer anderen Routerdienste oder VPNs.
• VDSL-Module antworteten immer „No answer received from modem“, wenn sie die Modulinfo auslasen.
• CDMA450-Module hatten diverse Probleme mit Reset und dem Wechsel vom/zum Stromsparmodus. All diese Probleme wurden behoben.
• In sehr seltenen Fällen konnte die SIM-Initialisierung für unsere LTE-Module aufgrund eines Qualcomm-Fehlers schieflaufen. Ein Work-Around stellt sicher, dass das nicht mehr passiert.
• Durch das Erstellen von unzulässigen Port-Forwarding-Einträgen konnte man ein Port-Forwarding der Hölle einrichten, durch das man sich aus dem Router aussperren konnte. Nun ist es nicht länger möglich, sich selbst so ins Knie zu schießen.
• Wenn man eine Routing-Regel anlegte, bei der alle Optionen auf „Ignore“ standen, konnte man faktisch eine Default-Route anlegen, bei der man sich aus dem Router aussperren konnte. Auch diese Möglichkeit, sich selbst ins Knie zu schießen, wurde beseitigt.

• Standard Congestion Control ist nun Cubic, standardmäßiges Autotuning Hybrid. Es gab signifikante Verbesserungen zum Hybrid Autotuning-Modus.
• Volle Unterstützung für die finale Version der VDSL-Module.
• Ab jetzt wird eine neue HTTPS-Zertifizierungsstellen-Datenbank verwendet, die Unterstützung für diverse Zertifizierungsstellen, nach denen Kunden gefragt haben, mit sich bringt.

• Managed SIMs wurden deaktiviert, sobald der Aktivierungsserver für eine Stunde unerreichbar war, während sie eigentlich erst nach 24h deaktiviert werden sollten.
• Wenn ein VPN-Client getrennt wurde und ein anderer Client-Nutzer später mit derselben IP des vorherigen Nutzers wieder angemeldet wurde, konnte das einen Absturz und Neustart des VPN-Hubs auslösen.
• Bei den Access-Point-Einstellungen fehlte die Option, Admin-Rechte zu konfigurieren.
• Beim Router-Start wurde die Fehlermeldung „The tunnel password for the tunnel contains illegal characters“ ins Log geschrieben.
• Wenn zwei oder mehr WAN-Module exakt zur gleichen Zeit powercycled wurden, konnte es passieren, dass die Module manchmal nicht mehr gefunden wurden, sodass ein Router-Neustart nötig war, um die Module wieder anzuzeigen.
• TKIP ist nun für HT-Clients auf 5XX WLAN-APs in 802.11n deaktiviert.
• Manuelle Firmware-Updates können nun auch hochgeladen werden, wenn die automatische Firmware-Prüfung den Status „UpdatesAvailable“ ergab.
• Bei allen 51X-Routern wurden die jeweiligen Konfigurationsdateien als miteinander kompatibel markiert. Davor konnten 511, 512 und 513 keine 510-Konfigurationen nutzen und umgekehrt.
• Bei Hubs 5000/5010 wurde im Web-Interface die Bildgröße korrigiert.
• Wenn die SSH-CLI aktiviert war, konnte eine Verbindungsflut auf Port 22 genutzt werden, um eine DoS-Attacke gegen den Router zu fahren.

• Es ist jetzt möglich, DNS-Server für VPN-Client-Gruppen zu konfigurieren. Wenn das der Fall ist, wird der VPN-Client diese DNS-Server anstatt den Hub-DNS nutzen. Dadurch ist es möglich, den VPN-Client in Kombination mit einem Domain-Controller zu nutzen, damit VPN-Client-Nutzer Teil einer Windows-Domäne werden können.
• Das neue „4G Europe II“-Modul wird nun unterstützt.
• Die CLI unterstützt nun die Werkzeuge Ping, Traceroute und Moduleinfo (angelehnt an die Funktionen im Web-Interface).

• Eine Race Condition, die bewirkte, dass Update-Scripts manchmal zweimal aufgerufen wurden, wenn man sie manuell startete, wurde behoben.
• Sehr große (100Mb+) lokale Update-Pakete werden nun unterstützt.
• Ein Fehler wurde behoben, bei dem Offline-Firmware-Updates manchmal abgebrochen wurden, was bewirkte, dass fehlerhafte Firmware-Uploads zurückgewiesen wurden. Das passierte, wenn nur 100ms lang keine Daten während des Uploads gesendet wurden. Meist geschah das mit dem neuen Web-Interface und wenn Updates manuell eingespielt wurden.
• Die Verteilung von Systemlast auf Mehrkern-Hubs wurde verbessert.
• Der Start für die Benachrichtigung bzgl Serviceverträgen wurde auf März 2015 verschoben.
• Diese Firmware-Version bringt einige Verbesserungen für LTE-Statusberichte.
• Ein Fehler wurde behoben, der verursachte, dass OptimalLatencyBelow nicht in der Monitoring API und im Monitoring-Tool angezeigt wurde.
• Die IP-Adresse eines ersetzten Geräts im Hub-Hotspare-Modus wird nun im neuen Web-Interface angezeigt.
• Einige Fehler im Channel-Congestion-Benachrichtigungssystem wurden behoben.
• Die SIM-Traffic-Berichterstattung konnte in einem Status enden, bei dem sie ihre Werte nie an den Abrechnungs-Server schickte.

• Bei Verwendung mehrerer neuer 4G Module konnte den Router komplett blockieren, wenn eines der Module nicht in der Lage war, die Heimnetzwerkinformation von der SIM-Karte zu lesen.
• Die Anzeige des Netzwerknamens war beim 4G Europe II Modul für einige Anbieter (z.B. T-Mobile) fehlerhaft.
• Unter sehr seltenen Umständen konnten beschädigte SSL-Daten bei einem Hub 5010 einen Absturz und anschließenden Reboot auslösen.
• 4G Module, die in einem Stacking Slave verwendet wurden, konnten sich nicht in manche mobilen Netzwerke verbinden.
• Unter seltenen Umständen konnte es passieren, dass WWAN-Module die IMSI und Home MCC/MNC von der SIM-Karte nicht lesen konnten, wodurch Automatic APN Detection versagte.
• Die APN-Datenbankeinträge wurden für AT&T USA, Rogers und Telus Canada aktualisiert.

• Der Lizenzmanager, den es bislang nur für RuggedVPN gab, ist nun auch für die Classic Firmware verfügbar.
• Die SupportID, die benötigt wird, um einen Router für das kommende Viprinet Lifetime Maintenance System zu registrieren, wird nun angezeigt.

• Ein seltener Absturzfehler auf VPN Hubs, der auftrat, wenn sich veraltete VPN-Clients verbinden wollten, wurde behoben.
• In einem Node-Stacking-Setup haben gestackte Nodes bislang nie LAN-Routen geteilt.
• Ein Fehler, bei dem GPS Geschwindigkeit und Richtung nicht aktualisierte, wurde behoben.
• Alle Produkte sollten jetzt CPU- und Systemkerntemperaturen anzeigen. Bitte beachten Sie, dass für manche Produkte jetzt ein anderer Temperatursensor tiefer innerhalb der CPU verwendet wird. Dadurch kann es passieren, dass Ihre CPU-Temperatur um etwa 10-20°C steigt. Das ist kein Problem und auch kein Defekt.
• QoS-Regeln, die nur für TOS galten, wurden bislang ignoriert.
• Alle Warn-Popups bzgl. fehlender Service-Verträge und RuggedVPN wurden aktualisiert. Wir möchten uns an dieser Stelle für jegliche Verwirrung entschuldigen, die diese nervenden Meldungen aus früheren Firmware-Versionen verursacht haben.
• Wenn ein Classic-Router sich zu einem RuggedVPN-Hub verband, konnte es unter sehr seltenen Umständen passieren, dass der Traffic für QoS-Klassen, die den BondingTCPOptimizer verwenden, auf dem Classic-Node geblockt wurde.
• Bislang funktionierte eine Änderung der Einstellung "Enabled mobile technologies" manchmal nicht, speziell wenn sie für ein Modul getroffen werden sollte, das gerade eine Datenverbindung offen hatte. Nun sollte diese Änderung immer funktionieren.

Eine gültige Garantieerweiterungs-Lizenz, die noch nicht abgelaufen ist, wird nun auch als „Unter Wartungsvertrag“ gezählt. Wenn Ihr Router noch immer Garantie übrig hat, können Sie daher jetzt auf RuggedVPN aktualisieren, selbst wenn Sie Ihre Garantielizenz bislang nicht in einen Viprinet Lifetime Maintenance-Vertrag umgewandelt haben. Bei Garantieerweiterungen wird nun auch angezeigt, wie viele Tage sie noch gültig sind.

• Nach einem Routerneustart konnte es unter seltenen Umständen passieren, dass ein Stacking Master-Node seine Kommunikationsbuchse nicht aktivieren konnte, wodurch die Stacking Slaves wiederum nicht in der Lage waren, sich mit dem Master zu verbinden, woraus im Endeffekt eine Split Brain-Situation entstehen konnte.
  In diesem Worst Case startet der Stacking Master jetzt neu, um dieses Split Brain aufzulösen.
• Unter sehr seltenen Umständen konnte es passieren, dass zwei in einem Split-Konflikt stehende Stacking Nodes, die gleichzeitig zu einem Hub mit einem zuvor weniger als 3 Minuten unterbrochenen Tunnel verbinden wollten, diesen Hub zum Abstürzen bringen konnten.
• Im SNMP wurde vonRouterCPULoad als string ausgegeben, anstatt als integer, wie es eigentlich hätte sein müssen.
• Für VDSL-Module war der Sync Speed im Log vertauscht („Synched Downstream / Upstream Rate“). Die tatsächlichen Werte waren in Ordnung, daher war dies nur ein Anzeigefehler.
• Falls die DNS-Auflösung auf einem VPN Hub falsch konfiguriert ist, kann der DNS Reverse-Lookup für eingehende Channelverbindungen sehr lange dauern. Falls sich viele Channels neu verbinden, kann das das Abschließen dieser Reconnects sehr lange verzögern. Eingehende Channel-Verbindung werden nun nicht mehr umgekehrt aufgelöst.

• Es ist nun erlaubt, ohne aktives VLM-Abonnement von Classic auf RuggedVPN aufzurüsten. Dabei wird eine Warnung angezeigt. Bitte beachten Sie, dass RuggedVPN dennoch ein VLM-Abonnement benötigt. Allerdings müssen Sie die VLM-Registrierung nun nicht mehr zwingend vor der Installation der RuggedVPN-Firmware vornehmen, sondern können das danach machen.
• Nach der Installation von RuggedVPN bleibt der Router 14 Tage lang voll funktionstüchtig; wenn er bis dahin nicht unter ein VLM-Abonnement genommen wurde (oder wenn der Router nicht wieder zu Classic zurückgestuft wurde), hört das Gerät auf, zu funktionieren. Auf diese Weise können unsere Kunden die RuggedVPN-Firmware testen.
• Diese Firmware-Version bietet erstmals volle Unterstützung für die nordeuropäischen LTE450-Module.

• Lizenzen werden nun gelöscht, wenn der Lizenzserver das anordnet, und die Online-Lizenz-deaktivierungsfunktion ist nun auch verfügbar.
• MCC/MNC wurde auf dem Gerät nicht erneut ausgelesen, wenn der erste Versuch fehlschlug. Dadurch konnte es passieren, dass die APN Auto Detection manchmal versagte.
• Ein LTE-Modul zu resetten oder wiederzuverbinden, kann bei der Synchronisation des internen Router-Timers zu einer Abweichung von bis zu zwei Sekunden führen. Aufgrund dessen verhalten sich Channels eigenartig: Sie zeigen hohe Latenz, Channel-Stillstand, etc. an. Dieses Problem ist nun behoben. Der Reset oder das Wiederverbinden eines Moduls sollte andere Channels nicht weiter beeinflussen.
• Weil die Anti-DDoS-Verbindungsbegrenzung nicht korrekt initialisiert wurde, konnte es bei allen früheren Firmware-Versionen passieren, dass manchmal die Übertragung von Konfigurationsdaten zwischen aktiven und Hotspare-Hubs durch einen SSL-Fehler versagte.
• Die Abonnement-Stufe "Eisen", die bei OEM-Projekten Verwendung finden wird, wird nun unterstützt.
• Es ist nun erlaubt, ohne aktives VLM-Abonnement von Classic auf RuggedVPN aufzurüsten. Das funktioniert auch mit dem alten Web-Interface.
• Zum Lizenzmanager wurde eine fehlende "Deactivate"-Schaltfläche hinzugefügt.
• Eine bereits bestehende Konfigurationsdatei von einer früheren RuggedVPN-Installation wird nun beseitigt, wenn das Gerät auf Werkseinstellungen zurückgesetzt wird.
• Es gab einen Weg, um SSH-CLI-Verbindungen ohne Auswirkung auf die Verbindungsbegrenzung zu schließen. Das konnte dazu führen, dass nach zuvielen Reconnects eine IP permanent aus der CLI ausgeschlossen wurde.
• Der Lizenzmanager benutzt nun immer das richtige Interface für Lizenzaktivierungen und -deaktivierungen. Davor funktionierte das nur, wenn die Default-Route auf einem VPN-Tunnel lag.
• Die Verbindungsbegrenzung / der DDoS-Schutz wurde geändert. HTTP-, VPN-, SSH-, Stacking- und Hotspare-Verbindungen werden nun individuell pro IP gezählt.