Our team of developers is keen to continuously improve our products. Hence, we periodically release firmware updates to not only eliminate errors and raise product quality but also provide new additional features. In the development of new product features we strongly upon our customer's feedback.

All our routers provide the option of a simple online update in the Webinterface at [ AdminDesk ] [ Logging & Maintenance ] [ Router Firmware Update ]. The device will automatically check for firmwareupdates for this specific router model and - if applicable - download and install them. Configuration settings permit that firmwareupdates will be downloaded without any administrator support when available. However, the installation should always be run with an administrator present.

If you need any help or further information concerning firmware updates, please contact our support team.

Following you will find important information on recently released firmware versions, with the latest update at the head.

Firmware update 07/22/2011 – Version 2011020901/2011062701

This is a maintenance update for the firmware released on May 11th, 2011 (Multichannel VPN Hub 1000: May 16th, 2011)

This update might be of importance to customers who are using a setup where commonly both the up- and downstream of all channels are fully used in combination with high-bandwidth links. The firmware versions released 11.05.2011/16.06.2011 might have degraded performance in these setups - the latency of the links could become much higher than in previous releases, possibly causing suboptimal throughput on the VPN tunnel level.

This has been resolved, the latencies of VPN tunnel channels are much more stable now even with high-bandwidth links.

Other than the former change, this release, which has gone through a long testing phase and is regarded the stable firmware release for the next few months, only brings some minor changes. We therefore recommend all customers to update to this firmware release.

Here is a list of all changes:

• Fixed: The internal socket buffer tuning of tunnel channels was changed in the release from May, with the consequences outlined above. This has been optimized now, the socket buffer tuning no longer relies on the calculated Maximum Bandwidth to WAN, but instead uses the Current Bandwidth to WAN, optimizing latency for high-bandwidth links.

• Fixed: The log message of a VPN Hub in hot spare mode in regards to comparisons on packet loss have been corrupt. Instead of a percentage, the IP address was displayed. This has been fixed.

• Fixed: If you use the traffic accounting API on a Hub with a very high number of VPN tunnels, "Too many uncommitted traffic accounting log entries in backlog, deleting oldest one" messages would appear in the log, with traffic accounting entries getting lost. This is fixed, we now support a much larger backlog.

• Fixed: The log message "Unable to submit traffic accounting data to server with URL..." now actually does output a URL to help with debugging your own implementations based on our traffic accounting API.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

Firmware update 05/16/2011 – Version 2011020901/2011051700

This is an urgent update for the firmware released on 11th May 2011 for the Multichannel VPN Hub 1000. Other products are not affected.

We have to inform you that due to an error in our release and certification process, a significant error slipped through - in our firmware release for the Multichannel VPN Hub 1000, the hardware encryption acceleration was turned off. The Multichannel VPN Hub 1000, when using the firmware release 2011020901/2011051001, will show terrible performance when used with encrypted VPN Tunnel channels (which is the default).

If you have already updated your Multichannel VPN Router 1000 to the firmware release 2011020901/2011051001 last week, please immediately update again to the new release 2011020901/2011051700, which fixes this problem. There are no other changes in this firmware release.

For all other products, the issue does not exist, and the firmware release 2011020901/2011051001 is current. The releases 2011020901/2011051001 and 2011020901/2011051700 are 100% compatible to each other.

We are very sorry for any inconvenience caused. We've made sure that such an error cannot happen again in the future by again improving our release testing system.

Firmwareupdate 05/11/2011 – Version 2011020901/2011051001

This is a maintenance release bringing once again small fixes and improvements to our major release from December 2nd 2010. If you are using the "BondingTCPOptimizer" mode in your router setups, this is a critical release.

This maintenance release was designed for providing a long-time highly stable firmware version and therefore does not add new features. We recommend all customers to upgrade to this firmware release.

List of improvements and fixes:

• Fixed: Recently, a third-party vendor has released products with a broken TCP/IP stack, which is sometimes sending broken TCP packets. Sadly, our BondingTCPOptimizer was sent into an endless loop if such a packet was transferred through a Viprinet router. This would basically make the router go out of service. If you are using BondingTCPOptimizer, this is a critical issue. The problem has been solved, and the BondingTCPOptimizer is now unsusceptible against all known kinds of TCP exploits.

• Fixed: The new channel autotuning modes "Hybrid" and "Passive" still did do autotuning even if bandwidth autotuning was turned off for a channel.

• Fixed: Under rare circumstances (particularly with the VPN Client), bandwidth autotuning could result in a negative bandwidth value.

• Fixed: There was a very high load of ARP packets on the LAN interface. For many setups, far more ARP packets were sent than needed.

• Improvement: The performance and latency of channels that are under 100% load have been improved, especially for slow channels with <500 KBit/s bandwidth.

• Improvement: The monitoring API has been updated to v3. If you use the current monitoring tool from our website, in addition to channel information you will now see summary information for the tunnel. The previous monitoring API version v2 is still supported, old tools will continue to work as before.

• Improvement: Summary information for bandwidth is now part of the tunnel's object inside the web configuration system.

• Fixed: The web interface would sometimes log an "Internal Error".

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

Firmwareupdate 02/25/2011 – Version 2010112901/2010122800

This is a maintenance release bringing various fixes and improvements to our major release from December 2nd 2010. This update brings various bug fixes for problems reported by customers, general performance improvements for most usage scenarios, and new features for "Streaming Optimizations" license holders. For usage scenarios where very unstable WAN links are bonded (like UMTS while on the move), the performance improvements in regards of achievable stable bandwidth are enormous.

Unless you are affected by one of the fixed bugs, it is not critical to update to this release. However, due to the performance improvements, it is still a recommended update for all customers.

List of improvements, new features, and fixes:

• Improvement: Performance Improvements for high-bandwidth setups. For Nodes and Hubs under high bandwidth load (>50 MBit/s) minimal packet loss could occur on the LAN board due to an Ethernet NIC issue. This could limit the achievable throughput especially for high-latency transfers through the VPN Tunnel. Packet loss will no longer occur in these situations.

• Improvement: In past releases, the test data traffic generated by the bandwidth autotuning would limit the achievable throughput of real data traffic while a channel was under test. Every time a channel was doing speed tests, the total throughput that could be achieved through the bonded Tunnel would go down. This was especially an issue for situations where very unstable WAN links were bonded that needed re-testings often. Often in these cases, a bundle of 2x ADSL and 1x 3G/UMTS would give a lower real throughput than 2x ADSL alone, due to the unstable 3G link causing test data traffic very often. This has been completely changed: Now autotuning test traffic never will eat away real data traffic bandwidth, real traffic always will have a higher priority. Especially for setups where some or all bonded WAN links are unstable, the achievable constant throughput now will be much more stable than ever before.

• New feature: In the past, when a channel was going down, depending on the "Maximum allowed Latency" settings of the channel data traffic using this channel could stall for 100-1500ms. This was because that internal re-transmissions were only triggered the moment a channel switched to "ConnectedStalled" status. In addition to that, these internal retransmissions now can also be triggered long before a channel stalls. The default now is that if a channel latency goes over 4 times the optimal latency, such a "speculative retransmit" is internally issued. The default multiplier should be fine, can however be adapted inside the "Performance finetuning" settings of the channel object.

• New feature: For all channels and tunnels there are now internal statistics about the stability. The number of times a channel went down recently is taken into account, as is the number of times a channel stalled, as is the number of times and amount of packet loss seen. The stability value is displayed inside the Monitoring tool and inside the web interface.

• New feature: The BondingDiversity bonding mode has been improved a lot. With older firmware versions, no matter how stable or unstable the channels were, redundant diversity copies were always sent as long as unused bandwidth was available. This caused a lot of traffic overhead, which especially was a problem whereever traffic is expensive (UMTS). The new BondingDiversity mode now offers a "Minimum diversity" and a "Maximum Diversity" setting, which allows you to configure the min/max number of copies of packets that should be sent. The actual number of copies now is automatically tuned between those min/max settings depending on the overall stability of the tunnel. If channels are unstable (for example because you are inside a moving vehicle, with frequent 3G cell changes), more copies of the packets will be sent, if the channels are stable, less copies will be sent. We highly recommend using the BondingDiversity mode for all applications where stable/low latency bandwidth (Streams, VoIP, Cloud Computing) should be done over highly unstable WAN links. Usage of this feature requires a valid "Streaming Optimizations" license for each router where it is going to be used.

• Feature removed: The "Bestchannel" bonding mode has been removed, as it always has been a far worse choice than for example the default "Bonding" mode. The "LatencyPriority" setting also has been removed, because it only was used for the "Bestchannel" bonding mode

• Feature removed: The "Minimize AutotuningTraffic" option has been removed. If traffic cost due to autotuning traffic is an issue, please switch either to "Hybrid" (recommended) or "Passive" (if you do not want to waste a single byte) autotuning methods, they work much better.

• Improvement: The documentation of the Channel Finetuning settings inside the web interface has been improved, it should be now much clearer which parameters are dangerous to change.

• Improvement: Hubs using our Hub redundancy system now start up much faster. There also have been lots of bug fixes in this area.

• New feature: Inside the tunnel object, there are now statistics about the current total up- and downstream bandwidths available for the tunnel. There also is a set of statistics on how much bandwidth of that is regarded stable (currently available bandwidth from channel which are regarded as unstable is not counted in). We will be offering an API to use these values for streaming codec manufacturers soon. Contact our support team if you are interested.

• Fixed: After a power-cycle, ADSL modules sometimes would not be correctly detected. Instead an empty slot was shown. This issue has been fixed.

• Fixed: The traceroute tool inside the web interface didn't correctly work for the LAN interface.

• Fixed: A very rare bug that in theory could result in router reboots has been fixed.

• Fixed: The combination of doing a port forward at a VPN Hub pointing to a host behind a VPN Node could lead to issues in regards of reachabilty if multiple LAN aliases or VLANs were used at the Node. The router was issuing incorrect "ICMP redirect" messages.

• Fixed: The LAN-Interface ARP implementation was having a lot of issues. If an IP inside the LAN was transferred from one PC to another (MAC address change), this could result in unreachability of this IP from the Node. All reported problems in regards of ARP have been fixed.

• Fixed: Static DHCP entries didn't work if more than one entry was created.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

Firmwareupdate 01/10/2011 – Version 2011010401/2011011003

This is a maintenance release bringing various fixes and improvements to our major release on December 2nd. This update also fixes an important issue introduced with the December 29th, 2010, firmware update. We recommend all customers to quickly update to this firmware release due to this. This update also introduces the option to configure static DHCP leases (and the ability to view the current lease table) as a new feature.

The following issues have been fixed:

• Fixed: Both the December 2nd and the December 29th release contained a serious memory leak issue. For routers under high load (several thousand concurrent traffic flows going through a VPN Tunnel) this could cause the router to misbehave and/or reboot after a couple of days/weeks. This issue is now fixed.

• Fixed: The December 29th release puts out the full VPN Tunnel setup dialogue between a VPN Hub and VPN Node / VPN Client to the log file. For connections between a VPN Hub with a firmware release older than December 2010 and for connections from VPN Clients this means that the VPN Tunnel password is written in clear text into the Log file. This is a security issue. The problem has been fixed, the dialogue no longer is logged.

• Fixed: VPN Hubs did send back multiple ICMP replies when pinged at the LAN interface (not visible with Windows ping tool).

• New feature: It is now possible to configure static DHCP leases at VPN Nodes.

• New feature: It is now possible to view the current DHCP lease table at VPN Nodes.

• New feature: The DHCP lease time is now configurable.

• Fixed: The VPN Hub redundancy system had a number of problems and bugs. The redundancy system is now far more stable than before even in critical situations.

• Fixed: A VPN Hub in "Hotspare" mode was unable to use DNS (and therefore also unable to do online firmware updates).

• Fixed: All file upload dialogs (QoS config restore, config restore, firmware upload) allowed files of unlimited size to be uploaded, causing the router to reboot in worst-case. There now exists a file size limit.

• Improvement: The SSL error messages are now easier to understand than before.

• Fixed: The download test tool had various issues, especially with HTTP servers using Chunked Encoding. This is fixed. The download test tool will now automatically abort if the test download is causing a CPU load so high that VPN tunnel performance would be affected.

• Fixed: The new autotuning methods "Hybrid" and "Heuristic" could result in Up-/Downstream values of 0/0 KBit or cause an Internal error after being run for a few days.

• Fixed: It was possible to restore configuration files to router types which are not compatible with the source router. Routers that are treated compatible to each other for configuration restore are now Multichannel VPN Hub 1000/2000/5000 and Multichannel VPN Router 1600/1610/2610. The Multichannel VPN Router 300 configuration is not compatible with any other model.

• Fixed: VLANs needed by external VDSL modems connected to an Ethernet modules didn't work correctly.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

Firmwareupdate 12/29/2010 – Version 2010112901/2010122800

This is a maintenace release bringing various fixes to our major release that was released on December 2nd. For many customers, this is a non-critical update. However, if you are using SNMP on your routers, the BondingTCPOptimizer mode in your QoS classes, or wish to use the DHCP relay feature, it is highly recommended to update quickly.

The following issues have been fixed:

• New Feature: All routers now fully support the new CDMA/EV-DO modules available to customers in North America.

• The SNMP service had an issue that if enabled, a malformed SNMP query could cause a denial of service. This is now fixed.

• If DHCP was configured to act as DHCP relay, the service would not come up automatically after a reboot, DHCP relay had to be restarted manually from the webinterface. This is now fixed, DHCP relay will automatically start up after a reboot.

• Quite a lot of HTTP/HTTPS attacks to the webinterface did cause Internal Error messages in the logs. These were and are non-critical. The number of attacks that can cause these Internal Errors has been reduced.

• The new "Heuristic" Autotuning method could result in Internal Errors when used with unstable links. These internal errors could potentially result in lowered performance or in worst-case, unresponsive VPN Nodes. This issue is now fixed.

• SSL connection error messages will now more clearly state if they are related to VPN Tunnel connections or web interface connections.

• Several "Debug"-class log messages have been removed.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.

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.

Firmware update 08/25/2010 – Version 2010063001/2010082300

In order to remove minor issues when using IPSec tunnels through Viprinet VPN tunnels, we have updated our firmware again.

This firmware update eliminates two minor problems:

• When using permanent connections it might have occurred that a temporary tunnel breakdown (all tunnel channels disconnected) after reestablishing the tunnels led to stuck lines. This problem particularly occurred when using IPSec tunnels through Viprinet VPN tunnels (which we advise against). The update will solve the problem.

• An error in handling packages with expired time to live within the bonding mode led to an unreliable function of multiple consecutive ICMP traceroutes. The update will solve the problem.

An immediate update is recommended only for customers that operate IPSec through a Viprinet VPN tunnel. For all other customers, this update is not pressing and can be performed during routine maintenance operations.

Notes on the update: Configuration changes are not needed for the update. As usual, we advise you to run all devices connected with a VPN tunnel with the same firmware version.

Firmware update 07/07/2010 - Version 2010063001/2010070600 (for Multichannel VPN Hub 1000 & Multichannel VPN Hub 2000 only)

At July 1st, we had released a new firmware for all Multichannel VPN Routers and Multichannel VPN Hubs. Unfortunately, this firmware version for Multichannel VPN Hubs 1000 and Multichannel VON Hubs 2000 contained a bug that might – depending on the actual configuration – cause that the Hub’s WAN/VPN interface cannot be reached via Internet any more.

Therefore, we have released another firmware update as of today for these two products. If you have already installed the July 1st firmware version on your VPN Hubs, we strongly advice an immediate update.

Products of the Multichannel VPN Router product line are not affected by this bug, hence there is no update for these devices. Multichannel VPN Hubs with a firmware older than July 1st, 2010, are not affected, either, updating to the new firmware is not considered as urgent.

Please note that we recommend to keep all devices connected with a VPN tunnel at the same firmware version. However, in this case there however will not be any problems caused by having the Multichannel VPN Hub using a slightly different firmware version than a connected Multichannel VPN Router – the versions released on July 1st (Multichannel VPN Routers) and todays release are fully compatible.

We want to apologize to the customers affected for the trouble caused. We have further improved our quality assurance in order to register comparable problems in our automated test sequences in the future.

Firmware update 07/01/2010 - Version 2010063001/2010063001

We have once again updated our firmware version as of June 8th, 2010, in order to remove minor errors especially for international applications.

In detail, the update eliminates the following problems:

• A small error has crept in the current firmware as of June 8th, 2010, with the effect that routers with SNMP will not answer description requests with the exact model name but with a generic information. This error has been rectified.

• A new addition is the option to set an MTU value for Ethernet and ADSL-modules in the web interface. This became necessary as DSL providers in some countries do not conduct MSS Clamping and / or do block Path MTU. This implicated that a VPN tunnel channel using this special ISP lost its connection due to an incorrect MTU-value immediately after connecting.

An update is only necessary for customers who are bothered by incorrect SNMP descriptions as triggered by the June-release, or who will operate Viprinet routers with DSL internationally. For all other customers, an update is not necessarily recommended.

Please note that we recommend to keep all devices connected with a VPN tunnel at the same firmware version.

Firmware update 06/08/2010 - Version 2010042001/2010060800

This firmware update further optimized stabilized the Viprinet device's performance. It eliminates the following problems:

• When using the "BondingTCPOptimizer" mode, it possibly could have occurred for respective traffic classes that a data throughput of only below 100 KBit/s can be reached per TCP connection after long operating times of the router.

• When using the "Bonding"-mode with a large number of connections over a longer period, a memory problem could have occurred that lead to router reboot.

• Some ADSL modules revision 2 (identifiable by "(R2)" in the web interface module overview) did not reestablish a connection following a 24h-disconnect.

• The SNMP service did not make a reply with some SNMP clients, when inquiries reached the router through a Viprinet VPN tunnel.

Based on these quality improvements, we recommend all customers to presently convert to the latest firmware version. This especially applies to installations that were affected by undefineable router reboots.

Moreover, the firmware features some minor improvements:

• In connection with ADSL modules revision 2, they offer PPPoE as well as PPPoA and RFC 1483 support.

• ADSL modules revision 2 now allow for configuring permitted DSL modulations. However, a modulation is only required in a few countries, where the automatic arrangement between modem and DSLAM will fail or will not provide the full expectable sync-speed.

• Included in the latest firmware is a new set of optimized QoS templates. If you have not already set individual QoS classes and rules for your demands, we recommend using these new templates. To use them, go to „QoS rules and classes templates" and choose the function "Restore Manufacturing Defaults“. The set of templates loaded can then be activatet in the respective VPN tunnel objects via „Copy QoS templates“. Please note that these changes must be made at the VPN Hub as well as the VPN Node.

Please note: no configuration changes are required for the update. We advise you to keep all devices connected with a VPN tunnel at the same firmware version.