• Mit diesem Release unterstützten wir erstmals unsere neuen CDMA 450 Mhz Module, die für den Einsatz in Nord- und Osteuropa bestimmt sind.
• Channel Congestion Detection ist nun etwas aggressiver eingestellt als bisher.
• Die CLI wurde vervollständigt und ist nun bereit für den Produktiveinsatz. Ein Scripting Toolkit, mit dem die Administration und das Deployment von Routern automatisiert werden können, ist auf Anfrage verfügbar.

• WICHTIG: Im vorangegangenen Stable Firmware Release aus Dezember 2012 existiert ein ernstzunehmender Fehler. Referenzen von VPN Routing Regeln auf einen Tunnel können zerstört werden, wenn Tunnel aus der Tunnelliste gelöscht werden - anschließend zeigen Regeln dann auf die falschen Tunnel. Ähnliches konnte auch bei QoS-Regeln passieren. Löschen Sie mit dem Dezember-Release keine Tunnel. Aktualisieren Sie zunächst auf diese Firmware.
• Wenn Channel komplett idle waren (für geraume Zeit weniger als 20 KBit/s an Traffic), hätten die Channel eigentlich in einen Trafficsparmodus gehen sollen, bei dem nur noch 1x pro Sekunde statt 10x pro Sekunde die Latenz und Eigenschaften des Channels analysiert werden. Damit sollte der Trafficverbrauch insbesondere bei Leitungen mit hohen Traffic-Kosten (z.B. UMTS) reduziert werden. Durch einen Rundungsfehler hat diese Funktion leider tatsächlich in der Praxis nie funktioniert: Wenn auf einem Channel auch nur ein einziges Mal mehr als 24 Kbit/s übertragen worden war, wurde der Traffic-Sparmodus nie wieder aktiviert. Dieser Modus funktioniert nun so wie erwartet und reduziert den Trafficverbrauch bei ungenutzten Channeln um den Faktor 10.
• Im Hotspare-Modus eines Hubs zeigt der Lizenzmanager nun einen Hinweis an, dass in diesem Modus keine Lizenzen geprüft werden.
• Ein Timingproblem konnte beim 500er Router in seltenen Fällen dazu führen, dass es gelegentlich kurze Aussetzer beim Routing gab.
• Das Ethernet Infotool für das LAN Interface am 500er Router funktioniert nun tatsächlich.
• Mehrere BondingTCPOptimizer bugs wurden gefixt. Diese konnten BondingTCPOptimizer TCP-Verbindungen hängen lassen, wenn nicht das WAN sondern das LAN das Bottleneck darstellte (z.B. wenn es im LAN einen traffic shaper hinter dem Viprinet-Router gab).
• Ethernet Autonegotiation Settings für Ethernet WAN Module wurden bisher nicht gespeichert und waren nach einem Reboot verschwunden. Dies ist nun behoben. Weiter besteht ein bekanntes Problem: Bei Gigabit Ethernet modulen lässt sich Ethernet Autonegotiation aufgrund eines Bugs im NIC-Treiber aktuell nicht deaktivieren. Bitte nutzen Sie als Workaround Fast Ethernet Module in diesen Fällen.
• Ein Memoryleak in Bezug auf Tunnelobjekte wurde behoben. Wenn man mit bisherigen Firmwarereleases eine sehr große Zahl von VPN Tunnel z.B. per automatisierter Scripte anlegete und löschte, konnte dem Router mit der Zeit das RAM ausgehen, so dass dieser rebootete. Das passiert nicht länger. Auch wurde die Performance beim Massenanlegen oder -löschen einer großen Zahl von Tunneln verbessert.
• Im vorangegangenen Firmwarerelease wurde eingeführt, dass ein Router nach Auftreten einer hohen Zahl von kritischen Fehlern im Routerlog automatisch neu startete. Leider wurde bisher auch der Ausfall einer der zwei Lüfter eines Routers fälschlicherweise als kritisch gelogged, weswegen nun alle Router, bei denen ein Lüfter ausgefallen war, alle paar Minuten rebooteten. Das Problem wurde behoben, in dem der Ausfall nur eines einzelnen Lüfters nun als "Alert" statt als "Critical" gelogged wird.
• Ein "invalid floating point error" konnte erscheinen wenn man im Download tool des Web interfaces die Option "Measure & discard" nutzte.
• Wenn man das PUTTY-Tool plink nutzt um eine Liste von Kommandos per CLI durch den Router ausführen zu lassen, wurden bisher carriage returns ignoriert, wodurch man immer nur ein Kommando ausführen konnte.
  
  Beispiel:
  plink -pw -batch -ssh -P 22 root@ -m commands.txt -v ERROR 140 ←[1m←[31mThis object does not exist←[0m
  
  Nun funktioniert dies sowohl mit CR als auch CR/LF als Kommandotrenner.
   
• Die CLI erlaubt es nun Unterobjekte anhand ihres Objekt-Indexes statt ihres Namens zu löschen - z.B. mit "execute DELETEITEM OBJECT__2"
• Die CLI schließt SSH-Verbindungen situationsabhängig nun korrekt. Damit wird es auch möglich SSH-Scriptingtools (z.B. Paramiko) zu nutzen, die pro Kommando einen neuen SSH-Subchannel öffnen.
• Mehrere Tippfehler im Webinterface wurden behoben.
• Das Timing von Hubs in einer Redundanzgruppe, welche beim Routerstart prüfen ob sie ersetzt wurden, ist nun deutlich robuster.
• BondingTCPOptimizer Verbindungen welche auf dem WAN packet loss ausgesetzt waren konnte insbesondere bei instabilen aber schnellen WAN-Verbindungen dafür sorgen, dass aufgrund fehlernder Pakete und Retransmissions sich beim empfangenden Router große Mengen an Daten aufstauten. War der Datenstrom durch Retransmission dann vollständig, wurden diese Daten mit einem Schlag ins LAN weitergeleitet, teilweise mehrere Megabyte. Das sorgte für eine große Trafficspitze im LAN, womit nicht alle Geräte in einem LAN besonders gut klarkamen. Auf dem Router war dies als "XX packets have been dropped reading from LAN" Nachricht zusehen. Die Pakete werden in der oben genannten Situation nun langsamer ins LAN geleitet, wodurch diese Spitzen deutlich abgemildert werden.

• The integrated system bootloader of the 500 router now uses error correction for its flash memory. In the past, we have seen RMA-ed 500 routers that had recoverable errors on the bootloader. Such a router would on power-on only have the power led going on, with nothing else happening besides that. With this improvement, these total failures will be a matter of the past.
• The Routers/Hubs will now keep state of all connections including NAT state if a tunnel disconnects. If the tunnel reconnects within 3 minutes, all state is restored. In previous firmware releases, a full tunnel disconnect (all channels disconnected) would often cause connections going through the tunnel to hang after tunnel reconnect; now it no longer does so if the tunnel comes back within 3 minutes. That's a huge improvement especially in moving vehicles that enter a "dead zone" with no mobile network reception at all. We were now able to do test drives for hours through forests etc. without ever having our connections going through the tunnel getting reset.
• The BondingTCPOptimizer mode has been improved a lot. Before, it had compatibility issues, especially if a connection went through multiple BondingTCPOptimizer tunnels (site-to-site VPNs). Also, the performance of this mode has been improved a lot. We now recommend to use BondingTCPOptimizer for any TCP traffic when bonding links with very high latencies, even for site-to-site VPNs, as it will improve achievable throughput a lot.
• Performance for the 500 router has been optimized a lot. In most situations, the maximum amount of bonded throughput is increased by over 30%.
• VLAN IDs may now be configured for additional LAN routes.
• LAN Aliases if a VLAN ID is assigned now may optionally have a default GW. If this is configured, then for traffic coming from the respective tunnel, segmentation ID will go to that default gateway, while the LAN interface (VLAN 0) will no longer be used (and that tunnel will no longer be reachable from VLAN 0).
• The two new features above together allow ISPs/BSPs to have a dedicated VLAN on the Hub per customer, a feature requested by multiple service providers.
• Webconfig system now logs user logins/logouts/errors.
• A new set of QoS rules and classes has been created. Web surfing by default still used Bonding, for high-latency bondings this should be changed to BondingTCPOptimizer. RTMP stream always uses BondingTCPOptimizer by default. The rules for RTP/VoIP have been changed to match on ToS and therefore generate less false positives, and to also support video conferencing. The VoIP QoS class now uses Lossy Bonding if a license for that is available. To use the new rules, you need to go to "QoS rules and classes templates" and execute "Restore Manufacturing Defaults", then go to each tunnel and select "Copy QoS templates to here". You need to do this on both, the Hub and the Router!
• There have been several buffer tunings going on. In many setups, throughput will improve, especially for connections using the "Bonding" mode. Also, performance for high-latency links and links with a high bandwidth-delay product (Satellite) has been improved.
• Configuring ethernet auto-negotation settings is now supported for Fast & GigabitEthernet modules.
• For high latency links (GPRS, Satellite), the passive and hybrid autotuning modes will now increase speed much slower so that the link is not overloaded without noticing it late.
• The Router may now be reached from the LAN using the hostname "viprinet.router".
• The "Resource Reservation Protocol" (RSVP) can now be routed through Viprinet Routers.
• Min and Max commands inside CLI now work.
• CLI is now displaying nicer datatype names on LIST.
• LTE module signal info inside the monitoring tool is now updated more constantly.

• Crash Bugs in der CLI in Zusammenhang mit Disconnects, während noch eine Antwort an den Client unterwegs war, wurden behoben.
• Tab-Vervollständigung in der CLI funktioniert nun auch für die VALUES-, MIN- und MAX-Befehle.
• Eine Änderung der WAN IP-Adresse an VPN Hubs unter Nutzung des Hub-Redundanzsystems konnte bewirken, dass anschließend das Webinterface des Routers hing und nicht mehr erreichbar war.
• Hubs im Hotspare-Modus haben bisher alle optionalen Hub-Features als unlizensiert angezeigt. Es erscheint nun ein Hinweis, dass dies im Hotspare-Modus irrelevant ist.
• Der 500er-Router hat für das LAN-Interface weder die Ethernet-Parameter angezeigt, noch ließen sich diese konfigurieren. Beides funktioniert nun.
• TCP-Neuübertragungen, welche durch die "Retransmission multiplier"-Einstellung ausgelöst wurden, sorgten als Nebeneffekt dafür, dass Channels nicht mehr in den "Stalled"-Modus gingen. Dies wiederum bewirkte, dass solche Channel trotz überschreiten der "Maximum allowed latency" weiter genutzt wurden. Dieser Bug beschränkte insbesondere in bewegten Fahrzeugen die Performance.
• Die 5 Ghz Channel Auswahl im WLAN Access Point des Multichannel VPN Router 500 hat nicht richtig funktioniert, nur der erste Channel konnte korrekt ausgewählt werden.
• Im vorangegangenen Stable FirmwareRelease hat das Hub-Redundanzsystem nicht auf dem WAN-Interface gelauscht, sondern nur auf dem LAN-Interface. Das konnte eine "Split Brain"-Situation auslösen, wenn am Hub nur der LAN-Link ausfiel, während das WAN-Interface noch up war. Das Redundanzsystem nutzt nun wieder sowohl WAN- als auch LAN-Interface.
• Wenn unter 'Reset after minutes of downtime' ein Wert konfiguriert war, wurde das Modul selbst dann in diesem Intervall rebooted, wenn das Modul eigentlich deaktiviert war.
• Objekt-Referenzen (Ziele von QoS-Regeln, Verweise auf WAN-Module in den Channels etc.) lassen sich nun auch mit der CLI konfigurieren.

• Der neue LossyBonding mode, der über die Streaming Optimizations Lizenz optional verfügbar ist, war in allen bisherigen Firmware-Releases fehlerhaft. In vielen Fällen kam es dazu, dass beim Empfänger Packet Reordering auftrat, was bei vielen Anwendungen für Probleme sorgte. LossyBonding bringt nun die erwartete Performance, und wird für alle Applikationen, bei denen zeitkritischer UDP-Traffic über instabile Bündelungen transportiert werden soll (z.B. Videokonferenzen über gebündeltes UMTS) empfohlen.
• Unter bestimmten (seltenen) Umständen konnte es passieren, dass ein Stromverlust des Routers beim Speichern der Konfiguration zu Fehlern auf dem internen Flashspeicher führten. In diesen Fällen zeigte der Router nach dem nächsten Start als Seriennummer nur noch "XX-XXXXX-XXXXX" an, und war nicht mehr voll funktionsfähig.
• Auf dem Multichannel VPN Router 500 konnte es passieren, dass plötzlich sämtliche Module "verschwanden" und nicht mehr nutzbar waren. Das Problem lies sich nicht mit einem Reboot, sondern nur mit Aus/Anschalten der Stromversorgung des Routers beheben.
• Die NAT-Engine hatte Probleme mit diversen ICMP-Unterprotokollen. Das konnte dazu führen dass Traceroutes von genatteten IPs ausgehend teilweise nicht richtig funktioniert haben.
• Die Broadcast-Detection wurde verbessert. Wenn bei früheren Firmwarereleases ein Router an einem LAN hing, in dem es ein IP-Netz gab welches aber an dem Router selber lokal nicht anlag, hat der Router Ethernet-Broadcasts dieser Netze ebenfalls empfangen und diese dann verwertet - mangels lokal anliegendem Netz konnte er dabei aber nicht wissen, dass das ein IP-Broadcast ist und hat es auf den Tunnel geschickt. Das hat u.a. zu PacketHeap-Fehlermeldungen im Log geführt.
• Das interne Konfigurationssystem wurde um den Faktor 20 beschleunigt. Inbesondere bei Hub-Setup mit einer sehr hohen Zahl von VPN-Tunneln dauerte das Ändern von Einstellungen im Webinterface bisher sehr lange. Auch bei solchen Szenarien speichert das Konfigurationsystem entsprechende Änderungen nun viel schneller.
• Die Firmware des Multichannel VPN Router 500 hatte einen Speicherleck-Fehler, der dazu führen konnte, dass dieser Router nach wenigen Tagen automatisch rebootete.
• Der BondingTCPOptimizer Bündelungsmodus hatte einen Fehler, der äußerst selten (mit einer Wahrscheinlichkeit von 0.25^12%) auftreten konnte. In diesem Falle stürzte der Router ab und startete neu.
• Im Hub-Redundanzsystem hat das Entfernen einer Test-IP nicht dafür gesorgt, dass diese IP tatsächlich nicht mehr gepingt worden wäre. Stattdessen wurde die IP bis zum nächsten Routerneustart weiter angepingt.
• Traffic Accounting funktionierte auf dem Multichannel VPN Router 500 nicht richtig
• Auf dem Multichannel VPN Hub 5000 funktionierten eingehende VPN Tunnel Channel Verbindungen nicht mehr zuverlässig, wenn bereits über 200 Tunnel Channel verbunden waren.
• Diverse Bugfixes für die SNMP-Implementierung, insbesondere für Nutzer der erweiterten SNMP-Lizenz (AdminStatus gemäß MIB, Timestamp für Router Uptime)
• Wenn mehrere Module gleichzeitig einen Power-Reset erhielten (z.B. bei entsprechendem automatischem Reset) konnte es passieren, dass bei einigen der Module der Strom nicht wieder angeschaltet wurde, und das Modul dann bis zum einem Neustart des Routers nicht mehr nutzbar war.

• Der Hybrid-Autotuning-Modus wurde stark verbessert und hat diverse Fehlerkorrekturen erhalten. Die Nutzung vom Hybrid-Autotuning-Modus wird für alle Mobilfunkverbindungen dringend empfohlen, da gute Messergebnisse mit geringem Trafficverbrauch kombiniert werden. Auch der passive Autotuning Modus wurde verbessert.
• Bei abgeschaltetem Latency-Autotuning ist die Dauer von Ping-Tests nun stark verkürzt. Bei manuell konfigurierten Latenzen für UMTS-basierte Channels kann dies bei sich schnell bewegenden Fahrzeugen für deutlich größere Nutzungszeiten für die sich ständig neu verbindenden Channels bewirken.
• Die vom Router zu verwendende Timezone kann nun unter "Logging & Maintenance" konfiguriert werden
• Die ARP-Implementation wertet jetzt auch aus dem LAN kommende IP-Pakete aus, um den Cache zu akualisieren. Dies sorgt dafür dass bei Geräten im LAN, die über längere Zeit nicht mehr aktiv waren bereits mit ihrem ersten Request nach außen dem Router wieder ihre MAC-Adresse mitteilen, wodurch bereits das erste Antwortpaket zugestellt werden kann. Dies bringt Vorteile in Zusammenhang mit einigen embedded TCP/IP stacks.

• Mit dem vorherigen Stable-Release bleiben SNMP-Counter alle 50 Tage stehen. Der nächste Zeitpunkt, an dem dies geschehen wird, ist der 20. Juni 2012. Wenn Sie von diesem Problem betroffen sind, sollten Sie daher schnellstmöglich updaten.
• Hubs 5000 haben via SNMP fälschlicherweise immer eine CPU-Temperatur von 0°C angezeigt.
• Im vorherigen Stable-Release war die experimentelle SSH-CLI auf Port 22 standartmäßig angeschaltet. Nun ist der Werkszustand, dass dieser Service ausgeschaltet ist, und Port 22 geschlossen.
• Im vorherigen Stable-Firmware Release wurde eine Congestion Detection eingebaut, welche den MaxBandwidthToWAN-Wert eines Channels immer reduziert hat, wenn Packet Loss auf der Leitung erkannt wurde. Diese schnelle Reduzierung der Bandbreite hat das Latenzverhalten von Channeln auf instabilen WAN-Leitungen deutlich verbessert. Allerdings hat die Änderung gerade bei instabilen WAN-Leitungen auch dafür gesorgt, dass deutlich häufiger Bandbreitentests durchgeführt wurden. Dies wiederum hat dazu geführt, dass unser Stable-Release aus April im Vergleich zu früheren Firmware-Versionen deutlich mehr Datentraffic erzeugt hat für diese Tests. Dies wurde nun optimiert, die Menge des Testtraffics sollte wieder stark zurückgehen. Sollten Sie für Traffic viel Geld bezahlen (z.B. bei UMTS), sollten Sie schnellstmöglich updaten.
• Der Treiber für unsere neuen Gigabit-Ethernet-Module hatte diverse Probleme. Wenn Sie eine statische IP-Konfiguration mit diesem Modul nutzten, konnte es sein, dass die Link-Detection nicht richtig funktionierte. Dieses Firmware-Release verbessert die Stabilität der Gigabit-Ethernet-Module ganz erheblich.
• In allen vorangegangenen Firmware-Releases hatten die „Passive“ und „Hybrid“ Autotuning-Modi einen Bug, welcher dafür sorgen konnte, dass die Bandbreitenmessungen steckenblieben, wenn diese bei sehr niedrigen Geschwindigkeiten (200 KBit/s und darunter) starteten. In diesem Falle verblieb der Channel dauerhaft bei dieser niedrigen Geschwindigkeit. Dieses Problem konnte insbesondere beobachtet werden bei sich bewegenden Fahrzeugen, da hier häufig von UMTS zurück auf GPRS/EDGE geschaltet wird, welches sehr niedrige Bandbreiten erlaubt. Der Bug ist nun behoben, die „Passive“ und „Hybrid“ Autotuning-Modi funktionieren in diesen Situationen nun wie gewünscht. Sollten Sie diese Autotuning-Modi nutzen, sollten Sie unbedingt zeitnah auf die neue Firmware umsteigen.

Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmware-Stand zu halten.

• Behoben: Kürzlich hat ein Dritthersteller ein Produkt auf den Markt gebracht, welches einen kaputten TCP/IP-Stack enthält. Dieser TCP/IP-Stack sendet gelegentlich kaputte TCP-Pakete. Leider ist unser BondingTCPOptimizer für diesen Fehler anfällig - entsprechende Pakete können den Bündelungsmodus in eine Endlosschleife schicken, was letztendlich zum Ausfall des Routers führt. Sollten Sie den BondingTCPOptimizer nutzen, ist dies ein kritisches Problem. Das Problem wurde behoben, der BondingTCPOptimizer ist nun sehr robust gegen alle bekannten Attacken gegen das TCP-Protokoll.
• Behoben: Die neuen Channel Autotuning-Modes "Hybrid" und "Passive" betrieben weiter Autotuning, auch wenn dieses für den Channel abgeschaltet war.
• Behoben: Unter seltenen Bedingungen (insbesondere beim VPN Client) konnte es vorkommen, dass das Bandbreiten-Autotuning ein negatives Bandbreitenergebnis lieferte.
• Behoben: Es gab eine sehr hohe Last an ARP-Paketen auf dem LAN-Interface. In vielen Setups wurden deutlich mehr ARP-Pakete durch den Router versendet, als eigentlich nötig gewesen wäre.
• Verbesserung: Die Performance und Latenz von Channeln, die unter Volllast stehen, wurde verbessert, dies betrifft insbesondere Channel mit einer Bandbreite von <500 KBit/s.
• Verbesserung: Die Monitoring API wurde auf die neue Version v3 aktualisiert. Wenn Sie das aktuelle Monitoring-Tool von unserer Website verwenden, können Sie in diesem nun neben Informationen zu den Channeln auch Zusammenfassungen für den gesamten Tunnel sehen. Die bisherige Monitoring-Version v2 wird weiter unterstützt, entsprechende alte Tools funktionieren also weiterhin.
• Verbesserung: Eine zusammenfassende Information zu Bandbreiten ist nun Teil des Tunnel-Objekts im Webinterface.
• Behoben: Das Webinterface hat manchmal einen "Internal Error" geloggt.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

• Verbesserung: Verbesserte Performance für High-Bandwidth setups. Für Nodes und Hubs die mit hoher Bandbreitenlast (>50 MBit/s) arbeiten konnte es vorkommen dass der integrierte LAN-NIC unter Umständen einen geringen Packet Loss im LAN verursachte. Dies wiederum konnte vor allem bei WAN-Strecken mit hoher Latenz für eine Beschränkung des maximal real durch den Tunnel zu realisierenden Durchsatz bedeuten. Das Problem wurde behoben, Packet Loss am LAN-Interface sollte (abgesehen von echten Störungen im LAN) nun nicht mehr auftreten.
• Verbesserung: In früheren Releases konnte der vom "Bandwidth Autotuning" erzeugte Datenverkehr die für realen Nutztraffic vorhandene Bandbreite stark limitieren - der Autotuning-Traffic "frass" quasi die Bandreite weg. Jedes Mal wenn ein Channel ein "Bandwidth Autotuning" durchführte, sank dadurch der nutzbare Gesamtdurchsatz des Tunnels. Dies war insbesondere ein Problem, wenn sich im WAN-Bündelungsverbund ein oder mehrere instabile WAN-Links befanden, die sehr häufig Autotuning-Tests erfordern. In der Praxis konnte es so passieren, dass eine Bündelung z.B. aus 2x ADSL und 1x UMTS weniger Durchsatz brachte als 2x ADSL alleine. Das Verfahren hierzu wurde komplett verändert. Mit dieser Firmwareversion wird Autotuning-Traffic nun immer nur die Bandbreite nutzen, die aktuell nicht von realem Traffic gebraucht werden könnte. Autotuning-Traffic beeinflusst damit nun nicht länger die real nutzbare Bandbreite. In Szenarien wo eine oder mehrere WAN-Anbindung instabil sind, wird sich die Performance in der Praxis erheblich verbessern und die nutzbaren Bandbreiten stabiler sein als je zuvor.
• Neues Feature: Wenn ein Channel zusammenbrach, war es bisher so, dass Nutztraffic der in der Bündlung diesen Channel mitnutzte stockte, bis der Channel in den Status "ConnectedStalled" wechselte. Dies lag daran, dass eine interne Retransmission erst ausgelöst wurde, wenn der Channel den Status "ConnectedStalled" hat - je nach Ergebnis des Latency Autotunings konnten so bei Channelabbrüchen Aussetzer von bis zu 1500ms im realen Nutztraffic entstehen. Zusätzlich hierzu kann der Router nun bereits vorab spekulativ Retransmissions durchführen, bevor der Channel in den "ConnectedStalled"-Status gewechselt hat. Per default wird nun eine Retransmission ausgelöst, wenn der Channel aktuell die vierfache Latenz des "Optimal Latency"-Wertes hat. In der Praxis reduzieren sich damit die Aussetzer beim Wegfall eines Channels erheblich. Der Multiplikator für diese Retransmission ist konfigurierbar. Die Einstellung dazu findet sich unter "Performance finetuning" im Channel Objekt.
• Neues Feature: Für alle channels und tunnels werde nun interner Statistiken zur Stabilität geführt. Hier fließt ein, wie oft der Channel bzw Tunnel in letzter Zeit disconnected war, wie oft ein Channel in den "ConnectedStalled" status gewechselt hat, und wie häufig und wie intensiv Paketverluste aufgetreten sind. Der Stabilitätswert wird sowohl im Monitoring-Tool als auch im Webinterface angezeigt.
• Neues Feature: Der BondingDiversity bonding modus wurde dramatisch verbessert. Mit bisherigen Firmwareversionen wurden immer, egal wie stabil oder instabil die Channel waren, so viele Diversity-Kopien jedes Paketes versandt, wie noch Bandbreite auf den Channeln verfügbar war - in vielen Fällen wurde als jedes Paket über jeden Channel geschickt (5 Kopien). Das bedeutete eine Menge zusätzlichen Traffic, was inbesondere bei teuren UTMS-Kanälen ein Problem darstellte. Der mit dieser Firmwareversion deutlich verbesserte BondingDiversity-Modus ändert dieses Verhalten: Es gib nun eine "Minimum diversity" sowie eine "Maximum Diversity" Einstellung, wodurch sich festlegen lässt, wieviele Kopien eines Paketes Minimal und Maximal versendet werden sollen. Der tatsächlich genutzte Wert wird dabei automatisch zwischen diesen Grenzen festgelegt. Hierbei wird berücksichtigt, wie stabil die genutzten Channels aktuell sind. Sind die Channels instabil (z.B. in einem bewegten Fahrzeug unter Nutzung von UMTS), werden mehr Kopien versandt, sind die Channels stabil, weniger. Wir empfehlen den BondingDiversity mode nun nachdrücklich für jede Art von Applikation, bei der über sehr instabile WAN-Links eine stabile Latenz und Bandbreite erreicht werden soll (z.B. Streams, VoIP, Could Computing). Die Nutzung des "BondingDiversity"-Modes erfordert eine "Streaming Optimizations" Lizenz pro Router, welche Sie auch nachträglich erwerben können.
• Feature entfernt: Der "Bestchannel" bonding modus wurde entfernt - er war in allen Einsatzszenarien dem "Bonding"-Modus weit unterlegen und seit langer Zeit schon nicht mehr zur Nutzung empfohlen. Die QoS-Einstellung "Latency Priority", die nur für diesen Modus Anwendung fand, wurde ebenfalls entfernt.
• Feature entfernt: Die "Minimize AutotuningTraffic" option wurde entfernt. Wenn Traffickosten für einen Channel wichtig sind, verwenden Sie bitte stattdessen den "Hybrid" (empfohlen) oder "Passive" (wenn jedes Byte zählt) modus, welche beide deutlich bessere Ergebnisse bringen.
• Verbesserung: Die Dokumentation der "Channel Finetuning" Einstelllungen im Web interface wurde deutlich ausgeweitet, es sollte nun deutlich klarer sein welche der Einstellungen ggf. stark negative Auswirkungen haben können.
• Verbesserung: Hubs die das Hub Redundanzsystme nutzen, starten nun deutlich schneller. Im Bereich des Redundanzsystems wurden zudem zahlreiche kleinere Fehler behoben, die Zuverlässigkeit des Systems wurde deutlich erhöht.
• Neues Feature: Innerhalb des Tunnel Objekts existieren nun Statistiken über die aktuell insgesamt für diesen Tunnel nutzbare Up- und Downstreambandbreite. Zudem gibt es einen Satz Statistiken zur dauerhaft als stabil anzusehenden Bandbreite. Diese wird dadurch ermittelt, dass die verfügbare Up- und Downstreambandbreiten von instabilen Channeln nicht mitgezählt werden. Für diese Statistiken werden wir in Kürze auch eine API zur Fernabfrage anbieten, welche z.B. für Hersteller von Videocodecs genutzt werden kann, um die Streambandbreite dynamisch anzupassen. Bitte kontaktieren Sie unser Supportteam bei Interesse an dieser API.
• Fixed: Nach einem Powercycle konnte es vorkommen, dass ADSL-Module nicht korrekt erkannt wurden. In diesem Falle wurde der jeweilige Slot im Webinterface als leer angezeigt. Das Problem wurde behoben, ADSL-Module sollten nun immer erkannt werden.
• Fixed: Das Traceroute tool im Webinterface hat nicht korrekt für das LAN interface funktioniert.
• Fixed: Ein sehr selten auftretender Bug konnte theoretisch für Reboots des Routers sorgen.
• Fixed: Die Kombination aus einem Port Forwarding am Hub, welches auf einen Host hinter einem VPN Node verwies mit der Nutzung von LAN aliases oder VLANs am Node konnte zu Problemen bei der Erreichbarkeit der Hosts hinter dem Port Forwarding führen. Der Router sendete in diesem Fall inkorrekte "ICMP Redirect" Pakete.
• Fixed: Die ARP Implementierung für das LAN-Interface von Hubs und Nodes hatte diverse Probleme. Wenn eine IP innerhalb des LANs von einem PC zu einem anderen übertragen wurde (sich also die MAC-Adresse der IP änderte), konnte es passieren dass diese IP anschließend durch den Node nicht mehr erreichbar war. Dieses und weitere Probleme in Bezug auf den ARP Cache wurden behoben.
• Fixed: Statische DHCP Einträge funktionierten nicht, wenn mehr als ein statischer DHCP-Eintrag angelegt wurde.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

• Fixed: Die Releases vom 2. und 29. Dezember enthielten beide einen kritischen Memory Leak Fehler. Router unter hoher Last (mehrere tausend gleichzeitige Verbindungen durch den VPN Tunnel) konnten nach Tagen oder Wochen des Betriebes dadurch Fehlverhalten zeigen oder rebooten. Dieses Problem ist nun behoben.
• Fixed: Der Release vom 29. Dezember gibt den vollen VPN Tunnel setup Dialog in das logfile aus. Für Verbindungen von VPN Nodes mit einer Firmware von vor Dezember 2010 sowie für Verbindungen von VPN Clients bedeutet das, dass das geheime Tunnel-Passwort im Klartext im Logfile zu lesen ist, was natürlich ein Sicherheitsproblem darstellt. Das Problem wurde behoben, der Dialog wird nicht länger gelogged.
• Fixed: VPN Hubs haben auf ICMP pings auf ihrem LAN-Interface mit mehreren ICMP-Replys geantwortet (mit Windows ping nicht sichtbar).
• Neues Feature: Es ist nun möglich statische DHCP leases auf VPN Nodes zu konfigurieren.
• Neues Feature: Es ist nun möglich sich auf VPN Nodes die aktuelle DHCP lease table anzeigen zu lassen.
• Neues Feature: Die DHCP lease time ist nun konfigurierbar.
• Fixed: Das VPN Hub Redundanz-System hatte eine ganze Reihe von Problemen und Bugs. Das System ist nun auch bei einer hohen Anzahl von VPN Hubs und in mehr Ausfallszenarien sehr viel stabiler als zuvor.
• Fixed: VPN Hubs im "Hotspare"-Modus konnten keine DNS-Auflösung vornehmen, damit war auch ein Online-Firmwareupdate von "Hotspare"-Routern unmöglich.
• Fixed: Alle Datei-Uploaddialoge (QoS Config restore, config restore, firmware upload) ließen den Upload beliebig großer Dateien zu, was im schlimmsten Falle zum Reboot des Routers führen konnte. Unsinnige Dateigrößen werden nun abgefangen.
• Verbesserung: Die SSL Fehlermeldungen im Logfile sind jetzt klarer zu verstehen als zuvor.
• Fixed: Das Download test tool hatte mehrere kleine Probleme. Insbesondere bei Verbindungen zur HTTP Servern, die "Chunked Encoding" nutzen, waren die Messergebnisse falsch. Das Download test tool bricht jetzt automatisch ab, wenn durch dessen Nutzung die CPU-Last des Routers so hoch wird, dass die Performance der VPN Tunnel beinträchtigt werden würde (wodurch die Messergebnisse ohnehin unbrauchbar würden).
• Fixed: Die neuen Autotuning modi "Hybrid" und "Heuristic" hatten nach längerer Betriebsdauer u.U. Probleme. Dies konnte zu Messergebnissen von 0/0 KBit/s Up-/Downstream oder auch zu "Internal Errors" im Logfile führen.
• Fixed: Es war möglich eine gesicherte Konfigurationsdatei auf einen Router hochzuladen, der mit dieser Konfigurationsdatei gar nicht kompatibel war. Das Problem ist nun behoben. Die folgenden Produkte sind zueinander bzgl. Konfigurationsfiles kompatibel: Multichannel VPN Hub 1000/2000/5000, Multichannel VPN Router 1600/1610/2610. Die Konfiguration des Multichannel VPN Router 300 ist mit keinem anderen Produkt kompatibel.
• Fixed: VLANs zur Verwendung von VDSL-Modems an Ethernet-Modulen funktionierten nicht richtig.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

• Neues Feature: Die Router unterstützen nun die neuen CDMA/EV-DO module, welche für Kunden in Nordamerika verfügbar sind.
• Der SNMP Service hatte im Betrieb Probleme mit einer fehlerhaften SNMP Anfrage. Diese konnten zu einer Betriebsverweigerung führen. Dies ist nun beseitigt.
• Falls DHCP als DHCP relay konfiguriert worden ist, wurde dieser Service nach einem Reboot nicht mehr automatisch gestartet. DHCP Relay musste hingegen manuell im Webinterface neu gestartet werden. Dies ist nun beseitigt, auch nach einem Neustart wird DHCP relay automatisch starten.
• Eine Vielzahl von HTTP/HTTPS Attacken auf das Webinterface führten zu internen Fehlermeldungen in den Logs. Diese waren und sind unkritisch. Die Zahl an Attacken, die potenziell diese Fehlermeldungen auslösen können, wurde verringert.
• Die neue "Heuristic" Autotuning Methode konnte bei Verwendung instabiler Links zu internen Fehlern führen. Diese internen Fehler konnten potenziell zu verringerter Performance oder, im schlimmsten Falle, zu nicht erreichbaren VPN Nodes führen. Dieser Fall ist nun beseitigt.
• Fehlermeldungen zu SSL Verbindungen werden künftig deutlicher machen ob sie VPN Tunnelverbindungen oder Webinterface-Verbindungen zuzuordnen sind.
• Eine Reihe von "Debug" Log-Meldungen wurden beseitigt.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

• Huge performance increase: Compared to previous releases, the total bonded VPN throughput a router/hub can do has increased by about 30%.
• User rights management system in AdminDesk - you now may create groups and users who only have read/write rights for certain objects. This can be used to enable customer access to their tunnel's settings only.
• VPN Hub: You now may create port forwardings mapping destination IPs at the VPN Hub to private IPs behind VPN Tunnels
• WAN VLAN Support: The Ethernet WAN modules now can use VLAN tagging. This is useful e.g. for external VDSL modems that require tagged Ethernet frames
• VPN Hub: LAN/LAN alias VLAN support. You now may use multiple VLANs at the LAN interface of a VPN Hub. The main IP configured in LAN Settings always will be sent untagged (VLAN0) and serves as access to the public internet. Traffic going there from the Tunnels matching a NAT rule will be NATted. In addition, LAN aliases may use tagged VLANs. This way it becomes possible to have dedicated networks
• "Tunnel segmentation" - similar to VLANs, you may group multiple tunnels by assigning them the same tunnel segmentation ID. Internally, all tunnels with a different segmentation ID are completely separate. This makes it possible to have multiple customers with multiple sites each terminated on one VPN Hub, where all sites per customer can see each other, but customers can't see other customer's networks. It is even possible to have multiple customers use the same private IP network - e.g. two customers that both use 10.0.0.0/8. If the tunnel segmentation ID chosen is the same as a VLAN ID assigned on a LAN interface, then traffic from all tunnels with this ID may exchange traffic with these VLANs, with all other customers not being able to reach the VLAN. Using this in combination with a VLAN-enabled switch at t

• In allen bisherigen Releases gab es Stabilitätsprobleme mit dem Hot-Plugging von LTE-Modulen. Das Ziehen von LTE-Modulen oder ein Modulreset im Webinterface konnte zu einem Reboot des Routers führen. Das war besonders ärgerlich, da bei der noch recht instabilen LTE-Technologie der Provider die automatische Modul-Reset-Funktion eigentlich sehr hilfreich wäre. Das entsprechende Problem wurde nun behoben, auch LTE-Module sind nun voll hot-plugging-tauglich.
• Mit der Verfügbarkeit des Hub 5010 wurde das Produkt nun als zum Hub 5000 kompatibel in der Firmware erfasst. Sollten Sie Hub 5010 und Hub 5000 gemischt nutzen im Hotspare-Betrieb, so müssen Sie die aktuelle Firmware einsetzen.

• Das interne Socket Buffer Tuning der Tunnelkanäle wurde im Mai-Release verändert, mit den oben genannten Konsequenzen. Dies wurde nun optimiert, das Socket Buffer Tuning baut nicht länger auf den "Maximum Bandwidth to WAN"-Wert, sondern richtet sich immer aktuell nach dem "Current Bandwidth to WAN"-Wert. Dies sorgt für eine optimierte Latenz bei Channels mit hoher Maximalbandbreite.
• Die Logmeldung eines VPN Hub im Hotspare-Modus mit Bezug auf Paketverlust-Vergleichen war fehlerhaft. Statt einer Prozentangabe für den Paketverlust wurde die IP-Adresse ausgegeben. Dies wurde korrigiert.
• Wenn unsere Traffic Accounting API mit einem VPN Hub mit einer großen Zahl konfigurierter VPN Tunnel genutzt wurde, konnte im Log die Meldung "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" erscheinen, damit konnten Traffic Accounting-Einträge verloren gehen. Dies wurde behoben, wir unterstützen nun ein deutlich größeres Backlog.
• Die Logmeldung "Unable to submit traffic accounting data to server with URL..." gibt nun tatsächlich eine URL aus. Dies hilft beim Debugging eigener serverseitiger Implementierungen unserer API.

Hinweise zum Upgrade: Änderungen an der Konfiguration sind für das Update nicht nötig. Wie immer empfehlen wir, alle miteinander mit einem VPN-Tunnel verbundenen Router auf den gleichen Firmwarestand zu halten.

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

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

• 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.
• 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.
• 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. Lizenzen werden nun gelöscht, wenn der Lizenzserver das anordnet, und die Online-Lizenzdeaktivierungsfunktion 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 „Iron“, die bei OEM-Projekten Verwendung finden wird, wird nun unterstützt.
• 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.

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

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

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

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

• 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üssel-austausch 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.
• 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.
  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 sind wir nun in der Lage, eine höhere Channel-Verbindungslast auf dem Hub zu verarbeiten, als mit der vorherigen Stable-Firmware (deren SSL-Handshake noch dazu weniger sicher ist).
• Bei multiplen Authentifizierungsfehlern auf der SSH-CLI werden weitere Login-Versuche von derselben IP nun gedrosselt. Dies erschwert Brute-Force-Attacken auf SSH enorm.
• 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).
• 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 (inklusive VLANs und RFC1483).
• Der neue Multichannel VPN Router 200 wird nun unterstützt (dieser wird erstmals auf der CeBIT 2014 zu sehen sein).
• 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.
• 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).
• 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.
• 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 der aktuellen Firmware laufen, immer noch produktive Hubs bedienen können, die mit der vorherigen 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 konnten, 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.

• 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.
• 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.
• 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.
• Ein Fehler wurde behoben, der durch einen SSL Handshake-Felher unter seltenen Umständen den Aufbau eines Tunnel-Channels zum VPN Hub abbrechen lassen konnte.

• In Stacking-Setups mit mehr als 2 Routern gab es einige Fehler. Ein Slave, der von einem alten zu einem neuen Master wechselte, konnte abstürzen; alternativ konnte es passieren, dass einige der geteilten Module auf dem Slave nach dem Wechsel nicht mehr funktionierten.
• Das "Download Test Tool" im Web-Interface konnte den Router abstürzen / rebooten lassen.

Wir empfehlen allen Kunden, die zuvor auf die Firmware-Version 2013051031/2013060600 geupdatet haben, ihre Router erneut zu updaten. Allen anderen Kunden wird empfohlen, auf die aktuelle Firmware-Version zu updaten, um die zahlreichen Verbesserungen nutzen zu können, die das Stable Firmware-Release aus Juni bringt.

• Wichtig: Alle unsere jüngsten Firmware-Versionen (Stable und Cutting Edge-Releases seit April 2013) beinhalteten einen kritischen Fehler: Wenn ein VPN-Tunnel aufgebaut und dann getrennt, danach erneut aufgebaut und wieder getrennt wurde, diesmal für mehr als 3 Minuten, dann konnten Router und Hub abstürzen und neustarten.
  Wir entschuldigen uns für eventuelle Unannehmlichkeiten, die das bei Kunden verursacht haben könnte, und möchten uns an dieser Stelle bei denjenigen unserer Partner bedanken, die den Fehler gefunden und uns davon berichtet haben.
  Aufgrund dieses Fehlers sahen wir uns auch gezwungen, alle Firmware-Versionen seit April 2013 von unseren Servern zu nehmen. Wenn Sie eine der betroffenen Versionen verwenden, updaten Sie Ihre Geräte bitte umgehend.
• Das Download Test Tool innerhalb des Web-Interface konnte den Router zum Absturz bringen, wenn die heruntergeladene Test-Datei HTTPS nutzte.
• Manchmal konnten Tunnel-Channels aufgrund eines SSL Handshake-Fehlers beim Verbinden direkt wieder abbrechen und neu verbinden, und es konnte eine Weile dauern, bis die Verbindung stabil bestehen blieb. Das passiert nun nicht mehr, dieser Handshake-Fehler ist behoben.
• Passive und Hybrid Autotuning, deren Nutzung bei mobilen Verbindungen (UMTS, LTE, Sat) empfohlen wird, tendierten dazu, die Max Bandwidth To WAN auf einen Wert zu optimieren, der leicht über dem optimalen Wert liegt. Dadurch konnte es zu Buffering auf dem Channel kommen, was im Monitoring für Latenz und aktuellem Traffic durch diesen Channel als „Sägezahn“-Form aufschien. Das Autotuning wurde verbessert, um die Geschwindigkeit dann langsamer zu erhöhen, wenn der Wert für „Optimal Latency Below“ fast erreicht ist.
  Diese Optimierung verbessert die Stabilität von Latenz-kritischen Anwendungen wie VoIP über instabile Verbindungen um einiges.
• Die Hub-Modelle 1020 und 2020 berichteten manchmal, dass ein oder zwei Lüfter zu langsam liefen, und meldeten daher, dass diese vermutlich defekt seien. Das ist tatsächlich nicht der Fall, daher wurde die Minimaldrehzahl der Lüfter bei diesen Produkten im Vergleich zu anderen Produkten gesenkt.
• Das Download Test Tool brach aufgrund zu hoher CPU-Auslastung öfters ab. Es ist nun in dieser Hinsicht etwas entspannter.
• Das Hub-Redundanzsystem markiert nun korrekterweise die Hub-Modelle 1000, 1020, 2000 und 2020 als zueinander kompatibel. In früheren Releases waren die Modelle 1020 und 2020 als inkompatibel zu früheren Hubgenerationen markiert.

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

• Wenn sich VPN Clients in einem gewissen zeitlichen Muster zu/von VPN Hubs verbanden/trennten, konnte der Hub früher oder später abstürzen und rebooten. Das passierte meistens dann, wenn ein VPN Client zu einem VPN Hub verband, die Verbindung trennte, direkt wieder aufbaute und vor erneutem Wieder-Verbinden erneut für mind. 3 Minuten trennte. Dieses Problem wurde behoben, VPN Clients können VPN Hubs nicht länger zum Abstürzen bringen.
• Reparatur bei heuristischen Autotuning: In der Theorie (nicht bestätigt durch reale Ereignisse) konnte Autotuning in eine Endlosschleife geraten, sodass unglaubliche Mengen an Test-Traffic erzeugt wurden.
• 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.

• Channels können nun Backup Scores haben, und dem Tunnel kann ein Minimum-Backup Score zugewiesen werden. Das erlaubt Ihnen Setups, bei denen mehrere Backup-Channels genau dann aktiviert werden, wenn der Master-Channel abbricht, bis der Verlust im „Score“ ausgeglichen wurde. Der Router wird mehr Backup-Channels aufrufen, bis der Minimum Backup Score des Tunnels erreicht ist. Der Backup Score eines Channels wird auch mit dem Link Stability-Wert des Channels multipliziert, daher bekommen instabile Channels nicht den vollen Score. Auf diese Weise ist ein Schutz gegen Link Flapping gegeben.
• Mithilfe von Stacking können mehrere Node-Router einen Stack bilden und so zu einem großen Router werden. Einer der Router bekommt die Master-Funktion zugewiesen und benutzt die anderen Router, die als Slaves dienen. Wenn ein Slave-Router ausfällt, brechen nur die Channels ab, die über den Slave-Router laufen. Wenn der Master-Router ausfällt, wird ein Slave-Router automatisch der neue Master. Wenn der festgelegte Master-Router wiederkommt, geschieht ein automatischer Failback. Damit all das funktionieren kann, synchronisiert der aktuelle Master-Router permanent einen Großteil der Router-Konfiguration mit den Slaves. Außerdem bringt der aktuelle Master-Router mindestens eine dedizierte IP-Adresse ins LAN, die ebenso übernommen wird, wenn ein Slave zum Master wird. Diese geteilte IP wird als Gateway ins LAN genutzt. Detaillierte Anweisungen zum Aufsetzen eines Stackings sind nun verfügbar. Stacking erfordert das Verwenden einer optionalen Zusatzlizenz.
• Wenn der Router mit einem GPS-Empfänger ausgestattet ist (für modulare Router bedeutet das, dass zumindest ein LTE/GPS-Modul verwendet wird), kann der Router nun seine aktuelle Position kommunizieren. Mit dem neuen Web-Interface ist eine Integration von Google Maps möglich.
• Channels können nun den Wert „Kosten“ haben. Channels mit niedrigeren Kosten werden bevorzugt, wenn nicht die gesamte verfügbare Bandbreite genutzt wird. Sie können nun z.B. ADSL-Channels haben, um damit den meisten Traffic kostengünstig abzuwickeln, und UMTS/LTE-Channels für Traffic-Spitzen.
  Dieses Feature ist noch nicht ganz ausgereift, wenn mehr als 2 verschiedene Kosten-Level definiert werden.
• Ein neues modern aussehendes Web-Interface ist nun optional und parallel zum alten Web-Interface verfügbar. Das neue Web-Interface beschleunigt die Router-Administration dramatisch. So können Sie z.B. mehrere gleiche Objekte zur selben Zeit bearbeiten (z.B. alle Channels eines Tunnels). Das neue Web-Interface erfordert einen aktuellen Browser (IE9+, Firefox 3.6+).
• Bei zukünftigen Firmware-Releases werden wir die erlaubten Zeichen in Objektnamen und String Properties begrenzen. Nur die folgenden Zeichen werden erlaubt sein:
  'a'..'z', 'A'..'Z', '0'..'9', '-', '+', '.', '_', ' ', '#', '(', ')', '/'​
  Wenn Sie momentan irgendwo andere Zeichen verwenden (Tunnel- oder Channel-Namen, Routing-Regeln, Router-Namen, etc.), ändern Sie sie bitte. Mit diesem Firmware-Release wird im Log eine Warnung ausgegeben, wann immer nicht-erlaubte Zeichen benutzt werden.​
  Der Grund für diese Änderung ist der bessere Schutz gegen Injection-Attacken auf allen Levels.
• Von Benutzern angelegte Objekte wie Tunnels und QoS-Klassen sollten nun nur noch etwa 1/4 so viel Memory benötigen wie bisher. Dadurch wird eine größere Anzahl an konfigurierten Tunnels und QoS-Objekten auf Hubs möglich.
• Die benutzten Root-Server für den DNS-Service wurden geupdated.
• Mit diesem Release unterstützen wir unsere neuen CDMA 450 MHz Module, die für den Einsatz in Nord- und Osteuropa bestimmt sind, erstmals vollständig. Die Unterstützung, die in der letzten Stable Firmware released wurde, war unvollständig. Nutzen Sie diese Firmware, wenn Sie CDMA 450 MHz-Module verwenden möchten. *)
• Die Unterstützung für LTE-Monitoring wurde entscheidend verbessert, wie auch die Unterstützung für mehrere LTE-Module in einem einzigen Router. Wenn Sie LTE benutzen, upgraden Sie bitte auf dieses Release. *)
• Hubs 1020 und 2020 werden nun vollständig unterstützt. Dieses Firmware-Release wird benötigt, um 1020/2020 zu betreiben.*)
• Die CPU Load wird nun durch das Web-Interface und SNMP überwacht und gemeldet. *)
• Es gab einige Fehlerbehebungen bezüglich Ethernet Autonegotiation. Auto Neg funktioniert nun für den 500er LAN-Port und die Gigabit Ethernet-Module. *)
• Bis jetzt führte das völlige Ausnutzen des Up- und Downstreams eines Channels zur selben Zeit zur Überlastung des Channels und zu hohen Latenzen, da der Downstream auf dem Upstream ACK Traffic verursachte zur Tunnel-Channel-Verbindung und anders rum. Das wurde verbessert. *)
• Das Ändern von QoS-Klassen, die gerade benutzt wurden (z.B. durch Ausführen von „Copy QoS templates to here“ auf einem laufenden Tunnel) konnte den Router zum Absturz bringen oder ihn einfrieren. Das passiert nun nicht mehr. *)
• Es war möglich, durch das Löschen der Standard-QoS-Klasse Internal Errors oder Abstürze zu verursachen. Das wurde behoben. Im schlimmsten Fall, bei dem die Standard-QoS-Klasse nicht mehr existiert, wird stattdessen die erste verfügbare Klasse genutzt. *)
• Es gibt nun eine „Reconnect“-Funktion für Tunnels. *)
• Wenn ein Tunnel von einem Node zu einem anderen verschoben wurde, konnte es passieren, dass der Hub den Fehler „A channel of this tunnel is already connected to a different VPN Node“ meldete, obwohl kein Channel des alten Nodes mehr verbunden war. Das wurde behoben. *)
• Wenn ein LTE-Modul idle war (Modul verbunden, aber kein Tunnel-Channel vorhanden), konnte es passieren, dass es erst inaktiv wurde, dann die Verbindung abbrach und sich wieder verband. Diese Schleife konnte ewig weitergehen. Nun ist dieses Problem behoben, LTE-Module beenden keine Verbindung aufgrund Inaktivität. *)
• Wenn Tunnel-Segmentation auf einem Hub genutzt wurde, konnten TCP-Verbindungen, die zwischen einem Tunnel auf Seg 0 zu einem anderen Segmenttunnel aufgebaut wurden, nach 30 Sekunden abbrechen, wenn sie inaktiv waren. Dadurch konnten inaktive SSH-Verbindungen zwischen diesen Segmenten einfrieren.

*) Diese Verbesserungen waren bereits mit der „Cutting Edge“-Firmware aus April 2013 verfügbar.

• Der gefürchtete Internal Error-Code 513791371A2237AE sollte behoben sein – es war ein Fehler im Heuristic Autotuning.
• Auf dem Hub gab es einen kritischen Wettlauf: Wenn zwei Nodes exakt zur selben Zeit Channels zum Hub verbanden, konnte der Hub in einen inkonsistenten Zustand gelangen, bei dem ein Channel von Node A verbunden wurde, aber der Tunnel des Hubs dachte, er wäre mit Node B verbunden. Deswegen konnte Node A keine weiteren Channel verbinden. Diese Situation konnte in größeren Stacks vorkommen, wenn Router rebooteten oder einen Powercycle brauchten und daher kurzzeitig zwei Master existieren und auf den Hub verbanden. Diese Split Brain-Situation wurde nun entdeckt und gelöst.
• Die CLI zum Zuweisen von Eigenschaften prüfte nur, ob der Benutzer die Erlaubnis hatte, eine Eigenschaft zu ändern, aber nicht, ob die Eigenschaft änderbar oder nur read-only war. Read-only Eigenschaften zu ändern führte zu allerlei seltsamen Problemen. Es ist nun nicht mehr möglich, Read-only Eigenschaften zu ändern.
• Kein Tool im alten und neuen Web-Interface benötigte Write-Erlaubnis des Benutzers für Änderungen. Nun brauchen dies alle Tools.
• Das Download Test-Tool (nur altes Web-Interface) wurde verbessert, sodass es weit weniger CPU benötigt. Daher gibt es nun keine „Download test aborted due to too high CPU load“-Meldungen mehr.
• Wenn ein deaktivierter Lüfter wieder aktiviert wurde, konnte es passieren, dass der Lüfter nicht startete, da der Lüfter-Speed zu niedrig eingestellt war.
• Während Router-Neustarts wird nun die CPU Load nicht länger überwacht und gemeldet, um nervige Warnungen loszuwerden, wenn es nichts gibt, wovor gewarnt werden sollte.
• Einige Produktionsläufe des Routermodells 300 haben das Problem, dass der Resetknopf nicht immer schnell funktioniert. Das ist nun behoben; den Resetknopf kurz drücken resettet das System sogar auf diesen Geräten.
• In den Modul-Einstellungen in der CLI und dem neuen Web-Interface konnten unzulässige Konfigurationstypen ausgewählt werden. Das ist nun nicht mehr möglich.
• „Expected Internet link capacity“ funktionierte für einige LTE-Carrier nicht, dadurch entstanden Internal Errors und negative Autotuning Speed Resultate. Das ist nun behoben.

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

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

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

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

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

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

• Diese Firmware bietet keine neuen Funktionen.

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

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.

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

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