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.

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

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

Nachfolgend erhalten Sie wichtige Informationen zu den zuletzt veröffentlichten Firmwareversionen, die neueste steht oben.

Firmwareupdate 22.07.2011 – Version 2011020901/2011062701

Dies ist ein Update zu unserem Firmwarerelease vom 11.05.2011 (Multichannel VPN Hub 1000: 16.05.2011).

Dieses Update kann für Kunden von hoher Bedeutung sein, wenn Setups existieren, bei denen Kanäle mit hoher maximaler Bandbreite (z.B. Kabelanschluss, VDSL) gebündelt werden, und diese Kanäle im Up- und Downstream gleichzeitig voll ausgenutzt werden. Die im Mai veröffentlichten Firmwareversionen können bei solchen Setups die Performance verschlechtert haben - die Latenz der Channels konnte deutlich höher sein als in früheren Firmwareversionen, was wiederum für einen eingeschränkten Durchsatz bei den Tunneln, die diese Channel verwenden, sorgen konnte. Dies wurde optimiert, die Latenzen von Tunnel Channels sind nun auch in solchen Fällen wieder deutlich stabiler.

Die übrigen Änderungen an dieser Firmware sind Kleinigkeiten. Diese Firmwareversion wurde von uns lange und intensiv getestet, und wird für die nächsten Monate stabil sein. Wir empfehlen ein Update daher für alle Kunden.

Hier die Liste aller Änderungen:

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

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

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

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

Firmwareupdate 16.05.2011 – Version 2011020901/2011051700

Dies ist ein dringendes Update zu unserem Firmwarerelease vom 11.05.2011 für den Multichannel VPN Hub 1000. Andere Produkte sind nicht betroffen.

Wir müssen Ihnen mitteilen, dass aufgrund eines Problems in unserem Release- und Zertifizierungssystem ein schwerwiegender Fehler in das Firmwareimage für den Multichannel VPN Hub 1000 gelangt ist: In diesem Firmwareimage war die Hardwarebeschleunigung für die AES-Verschlüsselung des Hubs abgeschaltet. Ein Multichannel VPN Hub 1000, der die Firmwareversion 2011020901/2011051001 nutzt, zeigt damit eine sehr schlechte Performance bei Nutzung mit verschlüsselten VPN-Tunnel-Channeln (was als default eingestellt ist).

Sollten Sie bereits vergangene Woche Ihren Multichannel VPN Hub 1000 auf die Firmware 2011020901/2011051001 aktualisiert haben, so führen Sie bitte schnellstmöglich ein weiteres Update auf die neue Version 2011020901/2011051700 durch. Diese Version behebt das Problem, weitere Änderungen gibt es nicht.

Für alle anderen Produkte gilt, dass diese von diesem Fehler nicht betroffen sind – für sie ist die Firmwareversion 2011020901/2011051001 weiter aktuell. Die Releases 2011020901/2011051001 und 2011020901/2011051700 sind 100% kompatibel zueinander.

Wir möchten uns zutiefst dafür entschuldigen, dass es zu dieser Panne kommen konnte. Wir haben Maßnahmen in die Wege geleitet, unser Release- und Testsystem zu erweitern, um zu verhindern, dass solch ein Fehler in Zukunft nochmals passieren kann.

Firmwareupdate 11.05.2011 – Version 2011020901/2011051001

Die neue Firmwareversion bringt nochmals einige Fehlerbehebungen und Verbesserungen zu unserem Major Release vom 2. Dezember 2010. Sollten Sie den "BondingTCPOptimizer"-Bündelungsmodus nutzen, so ist dies ein kritisches Firmwareupdate.

Dieses Wartungsrelease ist dazu gedacht, unseren Kunden für lange Zeit eine hochstabile Firmwareversion anzubieten, daher sind keine neuen Features enthalten. Wir empfehlen allen Kunden, auf diese aktuelle Firmwareversion umzustellen.

Liste der Verbesserungen und Fixes:

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

Firmwareupdate 25.02.2011 – Version 2011010901/2011022500

Die neue Firmwareversion bringt zahlreiche Fehlerbehebungen und Verbesserungen zu unserem major release vom 2. Dezember 2010. Enthalten sind Bugfixes für durch Kunden reportete Fehler, allgemeine Performanceverbesserungen sowie erhebliche neue Features für Nutzer der "Streaming Optimizations"-Lizenz. Für Einsatzszenarien, bei denen über sehr instabile WAN-Verbindungen (z.B. UMTS unter Bewegung) stabile Bandbreiten und Latenzen erreicht werden sollen, gibt es enorme Verbesserungen.

Solange Sie nicht von einem der gefixten Bugs betroffen sind, ist es nicht kritisch sofort auf dieses Update umzustellen. Wegen der zahlreichen Verbesserungen empfiehlt es sich trotzdem für alle Kunden, bald auf diesen Firmware-Release umzustellen.

Liste der Verbesserungen, neuen Features und Fixes:

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

Firmwareupdate 10.01.2011 – Version 2011010401/2011011003

Dieser zweite Nachtrags-Release zu unserem großen Firmwarerelease vom 2.Dezember beseitigt eine Reihe von Fehlern. Dieses Update behebt zudem ein wichtiges Problem mit dem Firmwarerelease vom 29. Dezember. Wir empfehlen allen Kunden, baldmöglichst auf die neue Firmware-Version zu aktualisieren. Dieses Update führt zudem neue Features rund um DHCP ein - so ist es nun beispielsweise möglich, statische Einträge für DHCP Leases anzulegen.

Hier die Änderungen im Einzelnen:

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

Firmwareupdate 29.12.2010 – Version 2010112901/2010122800

Dieser Nachtrags-Release zu unserem großen Firmwarerelease vom 2.Dezember beseitigt eine Reihe von kleineren Fehlern. Für viele Kunden ist dies ein nicht-kritisches Update. Sollten Sie jedoch auf Ihren Routern SNMP oder den BondingTCPOptimizer Modus in Ihren QoS-Klassen nutzen oder künftig das DHCP relay feature nutzen wollen, empfehlen wir Ihnen dringend ein rasches Update.

Folgende Punkte wurden im Einzelnen repariert:

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

Firmware update 12/02/2010 - Version 2010112901/2010120203

The latest firmware version for the Multichannel VPN Routers and Multichannel VPN Hubs constitutes no less than a revolution of functionality. The new release offers a vast number of new features, many of which have been desperately requested by partners and customers. Moreover, the firmware contains a number of bugfixes that provide higher system stability.

New features:

• 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 the VPN Hub allows for having local servers in the datacenter next to the VPN Hub, which become part of a customer’s VPN.

• Local Firmware updates - you now may upload Firmware images using the web interface. This allows for the firmware to be updated in situations where the online updater is unable to connect to the Internet

• QoS classes/rules export/import - You now may backup and restore collections of QoS rules and classes from/to Tunnels, VPN Client settings and the QoS Template object

• BondingDiversity mode - inside the QoS classes, you may now select the new BondingDiversity mode. This mode will send duplicates of data packets over multiple channels. This way even with VERY unstable WAN link quality you are able to get a stable stream through the bonding - this helps a lot for low-latency-streaming, Citrix or VoIP over bonded UMTS/3G.

• Several bandwidth autotuning methods are now available for selection per channel. There are huge improvements in regards of throughput for high-loss WAN links like UMTS. One of the new autotuning modes works without generating any artificial test traffic, which is useful whenever traffic is expensive (UMTS/3G).

• For the TCP connection used by the Viprinet tunnel protocol, the congestion control method now can be used. Some are optimized for high-latency and high-loss links (UMTS, Satellite). "Hybla" for UMTS in many cases will drastically increase achievable throughput.

• The monitoring tool will receive more data sources: The maximum allowed bandwidth for both directions of a channel will now be displayed; it is no longer needed to connect the monitor to both the VPN Hub and Node. In addition link stability and packet loss of the tunnel transport itself will be displayed. This allows for judging if there is a problem with the WAN link easily. This information also is available inside the Channel object inside the web interface.

• MCC/MNC/LAC are now displayed for UMTS/3G modules inside the monitoring tool and web interface. This allows to track changes of the used cell

• For UMTS/3G modules, APN auto configuration is now available. Using an integrated database of APN/username/password settings for various UMTS/3G providers in the world, the router will fully automatically configure these settings once a UMTS/3G module is plugged in. You no longer have to change any configuration setting if you exchange the SIM of a UMTS/3G module. Please report back if any UMTS/3G provider in your country is not detected!

• The maximum interface link speed for various WAN media is now automatically detected and displayed inside the module Object. For UMTS/3G this value for example is adapted depending on current reception of GPRS/EDGE/UMTS/3G/HSPA, for ADSL this is the ATM sync rate. The value here also is internally shared with the VPN Hub, and used on both sides to optimize bandwidth autotuning.

• New feature: It is now possible to run the integrated DHCP server on the node as a DHCP relay agent, forwarding DHCP requests to a central DHCP server located behind another VPN Node or a VPN Hub.

Enhancements:

• Hybrid-Autotuning now uses an exponential approach at measuring maximum bandwidth on connect, followed by passive autotuning. This ensures an initial rough estimate of the possible bandwidth without relying only on user generated traffic.

• Ethernet modules now show MAC-address in WAN Interface info

• Configurable DNS servers. With the new DNS server settings you can run the Viprinet router in two different modi:

  • resolver: The router will work as recursive DNS server, requesting the 13 DNS root server

  • CachingProxy: The router will work as recursive DNS server, forwarding the DNS request to a editable list of nameserver and cache the look up

• Configurable NTP server. Now it is possible to configure own NTP servers for time synchronization

• Both in the module configuration section and the LAN configuration object there now exists a download test tool. This allows you to measure the speed, round-trip-time and packet loss while doing a HTTP- or HTTPS-download from a server through the physical link instead of the tunnel. Very useful for problem diagnosis - if your tunnel channel is showing, issues test the line using the download test tool, it is comparable to connecting a Laptop directly to the line modem (if all tunnel channels using the link are disabled during the test, that is)

• Several fields that allow input of IP addresses or CIDR networks inside the web interface now do more accurate input validation.

Major Bug fixes:

• Small Memory leak when reading ADSL module info. This caused issues for partners who periodically polled this info using an external tool.

• The Hub redundancy system had various non-critical bugs. In case of a hotspare Hub taking over a broken active Hub and the administrator then converting this into a permanent replacement, all routers in this segment didn't notice this and kept complaining about a missing Hub.

• Reading the CPU/System temperature was inaccurate

• Space characters at the end of "IP to connect to" for tunnels/tunnel channels caused the connect to fail because the router would think this is a hostname

• Lots of bugfixes for the BondingTCPOptimizer mode - in many cases performance should be much better now, compatibility should be highly improved. It is recommended to try the BondingTCPOptimizer for high-bandwidth/high-latency bonded WAN links for bulk traffic like HTTP and FTP.

We recommend that all customers presently convert to the latest firmware version in order to profit from the various features and improvements. If you need advice for the update, please contact our support team to fix an appointed date for upgrading at support@viprinet.com. Please do not update your system during weekends, as our support won’t be able to back you up then. As usual, we advise you to run all devices connected with a VPN tunnel with the same firmware version.

Firmwareupdate 25.08.2010 - Version 2010063001/2010082300

Zur Beseitigung spezieller Probleme bei der Nutzung von IPSec wurde eine kleinere Firmwareaktualisierung vorgenommen.

Dieses Firmwareupdate behebt zwei kleinere Probleme:

• Bei dauerhaft "für immer" bestehenden Verbindungen bestand die Möglichkeit, dass ein zwischenzeitlicher Komplettausfall eines VPN-Tunnels (alle Tunnel Channels disconnected) nach Wiederaufbau des Tunnels dafür sorgte, dass diese Verbindungen "hingen". Dieses Problem bestand insbesondere bei der Nutzung von IPSec-Tunneln durch Viprinet-VPN-Tunnel hindurch (wovon wir abraten). Das Update behebt das Problem.

• Ein Fehler im Handling innerhalb des Bonding-Modus von Paketen, deren Time to Live Zeit abgelaufen ist, sorgte dafür, dass mehrfach hintereinander aufgerufene ICMP traceroutes nicht zuverlässig funktionierten. Das Update behebt das Problem.

Wir empfehlen allen Kunden, die durch Viprinet VPN Tunnel IPSec betreiben ein sofortiges Update auf die aktuelle Version. Für alle übrigen Kunden ist dieses Update nicht dringend, und sollte im Rahmen interner Wartungszyklen ausgeführt werden.

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.

Firmwareupdate 07.07.2010 - Version 2010063001/2010070600 (nur für Multichannel VPN Hub 1000 & Multichannel VPN Hub 2000)

Am 1. Juli 2010 wurde für alle Multichannel VPN Router und Multichannel VPN Hubs eine neue Firmware veröffentlicht. In dieser Firmwareversion für Multichannel VPN Hub 1000 und Multichannel VPN Hub 2000 existiert leider ein Bug, der je nach Konfiguration dazu führen kann dass das WAN/VPN-Interface der VPN Hubs aus dem Internet nicht mehr erreichbar ist.

Aus diesem Grunde haben wir am heutigen Tage eine aktualisierte Firmware für diese zwei Produkte veröffentlicht. Sollten Sie die Firmware-Version vom 1. Juli auf Ihren VPN Hubs eingespielt haben, empfehlen wir Ihnen ein sofortiges Update.

Die Produkte der Multichannel VPN Router Reihe sind von diesem Problem nicht betroffen, hier existiert auch kein Update. Das Problem betrifft ebenfalls nicht Multichannel VPN Hubs mit Firmwareständen älter als 1. Juli 2010, ein Update auf die aktuelle Firmware-Version ist hier also nicht als dringend anzusehen.

Bitte beachten Sie: Wir empfehlen grundsätzlich, bei allen miteinander verbundenen Viprinet-Routern die gleiche Firmwareversion einzusetzen. Dass in diesem Falle nach dem Update die Multichannel VPN Hubs eine neuere Firmwareversion aufweisen als die Multichannel VPN Router ist jedoch KEIN Problem, die Versionen sind vollständig und uneingeschränkt kompatibel.

Wir möchten uns für die entstandenen Unannehmlichkeiten bei den betreffenden Kunden entschuldigen. Wir haben unseren Qualitätssicherungsprozess nochmals verfeinert, um vergleichbare Probleme künftig im Rahmen unserer automatisierten Tests erfassen zu können.

Firmwareupdate 01.07.2010 - Version 2010063001/2010063001

Zur Beseitigung kleinerer Probleme vor allem im internationalen Bereich wurde die Firmwareversion vom 8. Juni nochmals aktualisiert.

Im Einzelnen behebt das Update die folgenden Probleme:

• Im Firmwareupdate vom 8. Juni 2010 hat sich ein Fehler eingeschlichen, der dafür sorgte dass bei Abfragen der Router mit SNMP als Description nicht der genaue Modellname des Routers, sondern nur eine generische Angabe ausgegeben wurde. Dieser Fehler wurde behoben.

• Neu hinzugekommen ist bei Ethernet- und ADSL-Modulen die Möglichkeit, im Webinterface einen MTU-Wert festzulegen. Dies wurde nötig, da in einigen Ländern die DSL-Provider selber teilweise kein MSS Clamping betreiben und/oder Path MTU blockieren – dies hatte zur Folge, dass mit diesen ISP ein aufgebauter VPN Tunnel Channel direkt nach dem Connect aufgrund eines falschen MTU-Wertes wieder die Verbindung verlor.

Ein Update auf diese Firmwareversion ist nur nötig für Kunden, die die falsche SNMP-Description des Juni-Releases stört, oder die Viprinet-Router mit DSL im Ausland einsetzen möchten. Für alle übrigen Kunden besteht keine Notwendigkeit eines Updates.

Bitte beachten Sie, dass grundsätzlich alle miteinander mit einem VPN Tunnel verbundenen Router auf dem gleichen Firmwarestand gehalten werden sollten.

Firmwareupdate 8. Juni 2010 - Version 2010042001/2010060800

Mit diesem Firmwareupdate konnte die Performance der Viprinet Geräte weiter optimiert und stabilisiert werden. Dieses Firmwareupdate behebt folgende Probleme:

• Bei Nutzung des "BondingTCPOptimizer"-Modus konnte es für die betreffenden Trafficklassen nach langer Betriebszeit unter Umständen dazu kommen, dass pro TCP-Verbindung nur noch ein Durchsatz von unter 100 KBit/s erreicht wurde.

• Bei Nutzung des "Bonding"-Modus konnte bei einer sehr hohen Zahl von Verbindungen über einen langen Zeitraum ein Speicherproblem auftreten, welches in Folge zum Neustart des Routers geführt hat.

• Mit ADSL-Modulen der Revision 2 (Erkennbar an "(R2)" in der Modulübersicht im Webinterface) konnte es dazu kommen, dass die Modems nach einem 24h-Disconnect nicht wieder automatisch neu eine Verbindung aufbauten.

• Der SNMP-Dienst lieferte bei Benutzung bestimmter SNMP-Clients keine Antwort, wenn die Anfrage über einen Viprinet VPN Tunnel zum Router hereinkam.

Aufgrund dieser Qualitätsverbesserungen empfehlen wir allen Kunden, zeitnah auf die neue Firmware-Version umzustellen. Dies ist inbesondere der Fall bei Installationen, bei denen unerklärliche Router-Reboots auftraten. Alle in dieser Hinsicht bekannt gewordenen Fälle werden mit diesem Update behoben.

Des Weiteren bringt die Firmware noch einige kleinere Verbesserungen:

• In Zusammenhang mit ADSL-Modulen der Revision 2 wird nun neben PPPoE auch PPPoA und RFC1483 unterstützt. Dies ist wichtig für den Einsatz im Ausland.

• ADSL-Module der Revision 2 ermöglichen nun die Konfiguration der erlaubten DSL-Modulationsarten. Eine Anpassung ist nur in einigen wenigen Ländern erforderlich, wenn das utomatische Aushandeln zwischen Modem und DSLAM fehlschlägt oder nicht die volle erwartete Sync-Geschwindigkeit bringt.

• Mit der aktuellen Firmware wird ein neuer Satz optimierter QoS-Templates mitgeliefert. Sollten Sie nicht bereits eigene QoS-Klassen und -Regeln für Ihren Bedarf erstellt haben, empfehlen wir Ihnen die Nutzung dieser neuen Templates. Um diese zu nutzen, wählen Sie im Webinterface unter "QoS rules and classes templates" die Funktion "Restore Manufacturing Defaults" aus. Der geladene Templatesatz kann anschließend innerhalb der jeweiligen VPN Tunnel Objekte über "Copy QoS templates" aktiviert werden. Bitte beachten Sie, diese Änderungen jeweils sowohl am VPN Hub als auch am VPN Node durchzuführen.

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.