Firmware Release Notes

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

"Cutting edge" vs. "Stable"

Viprinet bietet zwei Entwicklungszweige bzgl. seiner Firmware an: "Stable" und "Cutting edge". Die "Stable"-Firmware wird von uns über Wochen in Langzeiteinsätzen getestet und ein bis zwei Mal pro Jahr aktualisiert. Alle Kunden sollten immer mindestens die neueste "Stable"-Firmware nutzen. Zusätzlich bieten wir mehrfach im Jahr eine "Cutting edge"-Firmware an - diese enthält neueste Entwicklungen und Features, wurde aber nicht langzeit-getestet. Diese Firmware sollte von allen Kunden genutzt werden, die neue Features oder Fehlerbehebungen benötigen.

Online Update (nur Stable-Firmware)

Unsere Router enthalten im Web-Interface unter [ AdminDesk ] [ Logging & Maintenance ] [Router Firmware Update] die Möglichkeit, ein bequemes Online-Update der "Stable"-Firmware durchzuführen. Hier kann automatisch geprüft werden, ob für das Routermodell ein Firmware-Update vorliegt, dieses ggf. heruntergeladen und installiert werden. Es kann auch konfiguriert werden, dass Firmware-Updates ohne Zutun des Administrators bei Verfügbarkeit heruntergeladen werden. Die Installation sollte aus Sicherheitsgründen aber immer in Anwesenheit eines Administrators durchgeführt werden.

Offline update

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

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

Stable Firmware Release 6. März 2014 – Version 2014021430/2014022500

Im Zuge der NSA-Enthüllungen hebt diese Stable Firmware-Version die Sicherheit unserer Produkte auf eine neue Ebene. Wir haben die vergangenen Wochen damit verbracht, so ziemlich jeden sicherheitsrelevanten Aspekt unserer Produkte zu verbessern.

Außerdem beinhaltet diese Firmware-Version eine finale und stabile Version unseres neuen Administrations-Web-Interface, das als Preview schon seit ein paar Monaten verfügbar war.

Und schließlich behebt diese Firmware eine Reihe an Fehlern.

Dieses Release ist vollständig kompatibel zur Stable Firmware-Version vom 12. August 2013 (Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)). Eine gemischte Installation von Routern und Hubs, die noch die vorherige Stable Firmware-Version nutzen, ist daher möglich. Viele Verbesserungen bzgl. Sicherheit erfordern jedoch Unterstützung auf beiden Seiten des VPNs. Wir empfehlen daher, sowohl auf dem Router als auch auf dem Hub zügig diese Firmware-Version zu installieren.

Wichtige Hinweise für Kunden, die von einer früheren Stable Firmware-Version updaten

Viprinet unterstützt nun Zugriffskontrolllisten (ACL). Damit können Sie definieren, welche IPs und Subnetze aus dem LAN oder WAN/VPN auf welche Dienste zugreifen können. Beim Firmware-Update wird ein Standardregelsatz erstellt. Diese Regeln sind so gestaltet, dass sie existierende Installationen nicht beeinträchtigen, aber es wird empfohlen, sie zu verfeinern. So wird z.B. der Zugriff auf den AdminDesk sowohl per HTTP als auch HTTPS von überall gestattet, wobei wir empfehlen, aus dem Internet nur HTTPS zuzulassen.

Aufgrund der neuen ACLs wurden die Einstellungen für die SSL-Zertifikate im AdminDesk von „[ AdminDesk ] LAN settings“ zu „[ AdminDesk ] Integrated services“ verschoben. Sollten Sie Ihr eigenes SSL-Zertifikat installiert haben, müssen Sie es nach dem Firmware-Update erneut installieren.

Auch alle SNMP-Einstellungen wurden zu „[ AdminDesk ] Integrated services“ verschoben. Nach dem Firmware-Update müssen Sie SNMP erneut konfigurieren.

Liste der Veränderungen im Vergleich zur vorherigen Stable Firmware-Version

Neue Funktionen

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

Fehlerbehebungen

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

Cutting Edge Firmware Release 3. März 2014 – Version 2014021430/2014022500

Im Zuge der NSA-Enthüllungen hob die letzte Cutting-Edge Firmware-Version die Sicherheit unserer Produkte auf eine neue Ebene. Das aktuelle Update bringt darüber hinaus einige weitere neue Funktionen. Im Bezug auf die neuen Sicherheitsfunktionen lesen Sie bitte die wichtigen Release-Notes für die vorherige Cutting-Edge Firmware-Version (10. Februar 2014 – Version 2014013131/2014020702), die auch für die aktuelle Version zutreffen.

Außerdem beinhaltet diese Firmware-Version einige zusätzliche Verbesserungen für unsere Version vom 10. Februar, und wird sehr wahrscheinlich zur neuen Stable-Firmware-Version werden.

Dieses Release ist vollständig kompatibel zur Stable Firmware-Version vom 12. August 2013 (Version 2013071130/2013080900 (Multichannel VPN Router 500/510: Version 2013071130/2013080900)). Es ist daher möglich, Router auf die Cutting-Edge Firmware zu updaten, während die Hubs noch mit der Stable-Version laufen. Viele Verbesserungen bzgl. Sicherheit erfordern jedoch, dass beide Seiten des VPN-Tunnels auf diese Cutting-Edge-Version geupdated werden. Wir empfehlen daher, sowohl auf dem Router als auch auf dem Hub zügig diese Firmware-Version zu installieren.

Liste der Veränderungen im Vergleich zur vorherigen Cutting-Edge Firmware-Version (2014013131/2014020702) – Sollten Sie von einer Stable-Version auf diese Cutting-Edge-Version updaten, lesen Sie bitte auch alle vorherigen Cutting-Edge Release Notes seit der Veröffentlichung Ihrer Stable-Version.

Neue Funktionen

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

Fehlerbehebungen

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