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