Firmware RuggedVPN

RuggedVPN Stable Firmware Release December 21, 2018 – Version 2018091860/2018111900

This firmware release is bringing a number of product quality improvements and critical stability fixes. We
recommend all customers to update to this release in a timely manner.

In addition to the firmware release from October, this edition is bringing another batch of bug fixes. An updated
firmware image will be available on Amazon AWS as soon as their approval process is finished.

If you wish to upgrade from Classic firmware, please first update the router to the last stable Classic firmware
release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your
firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be active. For more
information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on the
latest version of Classic firmware connect to a device running RuggedVPN firmware. However, in this case a
compatibility mode will be used, which limits performance and features. It is therefore not recommended to
permanently use such a setup, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware
device while you are upgrading. This REALLY is the final firmware version that still supports connecting old
devices running our Classic firmware generation (2015 and prior) and upgrading from such a firmware release.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release
(Version 2018091860/2018100300 released on October 10, 2018).

Bug Fixes

In case the local output bandwidth of a WAN Optimizer connection dropped to zero, the WAN Optimizer would
not notify the remote side to stop sending, therefore filling up the RAM. That's a very rare condition, because
this can only happen if the receiving side of a TCP user connection would suddenly close the receive window
forever. There is one case where we have seen this in real life: The "pause download" function of browsers.
Removed "HUGE" debug messages that were flooding the logs in some installations, causing lots of
headaches
Fixed an ARP problem on the Hub's WAN Interface. If someone had a terribly broken switch configuration,
this could cause a Hub's WAN interface to not be reachable for a long time after a reboot or IP change. This
fix is not an invitation to run out-of-spec ARP cache timeouts on switches
If a Multichannel VPN Router 300 runs out of memory, it will reboot. Before rebooting it would write a crash
log to the flash. It turns out that sometimes the flash write-trough might not have completed by then. This
could cause the flash to fail. This fix should prevent this to happen. However, keep in mind: On older 300s, the
flash chip now is over 10 years old and therefore has long passed its typical mean time before failure. We
recommend to replace your 300 routers.

RuggedVPN Stable Firmware Release October 10, 2018 - Version 2018091860/2018100300

This firmware release is bringing a number of product quality improvements and critical stability fixes for VPN Hubs. We recommend all customers to update to this release in a timely manner.

An updated firmware image will be available on Amazon AWS as soon as their approval process is finished.

If you wish to upgrade from Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be active. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on the latest version of Classic firmware connect to a device running RuggedVPN firmware. However, in this case a compatibility mode will be used, which limits performance and features. It is therefore not recommended to permanently use such a setup, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading.This is the final firmware version that still supports connecting old devices running our Classic firmware generation (2015 and prior) and upgrading from such a firmware release.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 201805236/2018070900 released on July 12 2018).

Bug fixes

In the stable release 2018070900 we had prepared support for the web interface to be able to use Unicode (for localization) in the future. The implementation contains a bug that if a certain URL formatwere included in a HTTP/HTTPS request, it would make the Hub/Router silently reboot without giving any message.

Sadly this bug is triggered by automated exploit scans searching for web application vulnerabilities. This means that any Viprinet device which has its web interface open to the Internet (which is fine and expected) without having it protected by an ACL will be affected.This is a very critical bug. This update fixes this problem, and makes the code involved much more robust.

In some rare cases, updating a 51x router to the stable release 2018070900 could make it hang during the boot process. For some customers this has never happened, for some it happened on a lot of devices. The exact reasoning why this is happening only for some customers are unclear, but with those who had seen the problem we have verified the bug is fixed.
With the stable release the "Minimum guaranteed bandwidth/maximum allowed bandwidth" features of QoS did not longer work as expected. This is now fixed, they fully work as expected again. (Bug ticket #1391)
For 200/5xx routers an optimization for reading packets going to internal router services (web interface, SSH CLI) was introduced in the stable release 2018070900. This has now been removed, as CPU cache bugs were causing packet loss and reordered packets when accessing router services. From our tests we have not seen any significant impact in performance.
Viprinet routers contain a connection limiter making sure you can not overload the router's services with simple single-IP DoS attacks. It makes sure only a certain amount of connections per IP can be established per service. However, in the 2018070900 stable release this was broken on two counts: For HTTP/HTTPs and SSH the limit was not enforced at all.

But there was another bug that was present for a long time already: If at any given moment any single IP had hit the maximum connection limit on a service, this service would die and no longer respond to anyone. This was the case for example for the VPN WAN interface on Hubs - if a single IP once managed to open 100 concurrent HTTPs connections (which is hard to do), no channel would be able to connect to the Hub's WAN port until the Hub was rebooted.

Executive summary: both bugs are resolved. In addition, we have lowered the maximum number of concurrent established connection from a single IP for the following services

Web interface: 25
VPN Channels: 25
SSH Connections: 3

(all of this is per-IP!)

The code that decided on how many concurrent WAN Optimizer connections to allow was basing it decision on how much free RAM was left on a router. However, it did not take into account that RAM it already uses itself should also be counted as "free". This caused a router after running for a long time or having used a lot of WAN Optimizer connections to reduce the maximum allowed WAN Optimizer connections, effectively resulting in at some point the WAN Optimizer hardly being used at all anymore.
The TCP Option 254 originally used for RFC3694-style experiments according to IANA is illegal and should not be used, however customers have reported that they have broken equipment in their network that improperly uses this option in shipping products. We therefore are now allowing this TCP Option as requested by a partner.
If you had flapping channels on a Hub (channels constantly reconnecting), this would cause a small memory leak that over time would grow large until the Hub ran out of memory. (Bug ticket: #1399: Memory leak with flapping channels)

RuggedVPN Stable Firmware Release July 12, 2018 – Version 201805236/2018070900

This firmware release is a breakthrough: After working on it for three years, finally a brand new and highly improved implementation of our WAN optimization feature is back. It's much more compatible, faster and stable than its first incarnation from a decade ago.

Whatever link you might have, may it be bonded LTE, lossy DSL or even satellite: Our new firmware will perform better than ever. In addition to this, this firmware is bringing a metric ton of bug fixes and improvements, which you will find listed below. This release also contains a very important update if you are using Hub virtualization. Please note that this release does NOT fully support IPv6. Please check the release notes below for both issues.

An updated firmware image will be available on Amazon AWS as soon as their approval process is finished.

If you wish to upgrade from Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be active. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on the latest version of Classic firmware connect to a device running RuggedVPN firmware. However, in this case a compatibility mode will be used, which limits performance and features. It is therefore not recommended to permanently use such a setup, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client is available based on Classic Firmware and alternatively based on the RuggedVPN firmware generation. This is the final firmware version that still supports connecting old devices running our Classic firmware generation (2015 and prior) and upgrading from such a firmware release.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2017102440/2018041200 released on March 24 2018).

New Features

The WAN optimization feature is available as an option to be enabled in the QoS settings. If you restore your QoS Templates to manufacturing defaults, a new set of QoS classes including the WAN optimization feature will be available to be assigned to your tunnels.
The download test tool has a new "delay" parameter that can be used to wait between sending the HTTP header and the actual data for a number of seconds – useful to simulate long-lasting idle connections.
Like this: wget -O NUL "http://192.168.200.1/exec?module=download&delay=10".
The route back option in LAN settings now has an option to disable its logging to prevent excessive logging.

Bug Fixes

Due to both virtualization hypervisors and the Linux kernel addressing a bug on how a virtual machine identity is passed on to the guest operating system, on multiple hypervisors the device might get into a state of "identity crisis" after a firmware update – it will identify as a new machine with a different hardware ID, not matching its virtual hub license. We hope to have fixed this problem with this release. We've tested with latest versions of VMWare and KVM but if you are deploying Virtual Hubs please urgently check your own installations.
Fragmented Packets are now also captured using the packet capture tool.
Enabled Band 8 for 4.5G Europe/America.
Fixed performance problems within IP fragmentation on 200/5xx.
Fix for system getting stuck in a reboot loop if more than 256 routes are created.
A big and complex fix for FEC:
The first problem was that FEC was meant as a "this is a minimum guaranteed redundancy for the system". This makes sense for parity, but for packet duplication it does not.
The logic was something like "If I want 4 channels, and in general have 4 channels connected / fitting the QoS needs, but only three of those can be used right now, then this means that we have reached the maximum available bandwidth and can not do anything".
Turns out that the speed tests after the missing channel reconnected caused exactly this scenario – all channels are there, but for this one channel all the potentially available traffic is eaten by speed tests.
The logic has now been changed: For parity it still is "we guarantee this minimum", while for duplication and up, now we just don't care – as long as we have a channel left, we'll send. This means that a potential QoS class doing lots of traffic could prevent a duplication class to only use a single channel most of the times. We still think it's more intuitive than it is today, and this limitation can be solved using bandwidth guarantees.
Also, we have fixed the situation that a speed test can take away all the traffic of a channel, not allowing much user traffic (and none in case of duplicate and above).
"ICMP time exceeded" messages caused by a routing loop could itself cause a routing loop resulting in a packet storm.
Fixed ICMP stuff so you again see the Viprinet hop when doing a traceroute.
Lots of optimizations for 5xx throughput/CPU load.
Fixed CPU Temperature Sensor for 50X0.
Fixed internal error BEF3238723CD2983.
Fixed a long-standing bug in RuggedVPN (has always been present) that in a rare case if multiple channels had the exact same score could have caused that only one of them would be used.
The HTTP server will now correctly declare the character encoding (UTF8 / Ansi) for any kind of text file (html, js, css etc) served. This is in preparation for a fully Unicode-enabled web interface that can be localized in multiple languages. Please report any strange encoding/character errors.
Fixed WLAN AP config regions now being selectable with Toughlink.
Fixed the "HTTP Server is eating 100% of the CPU forever" problem.
"No gratuitous ARP on stacking failover" bug should be fixed.
Fixed the underlying problem leading to Internal Error 137239A239232341 / Map size HUGE. That one is actually interesting: If you did NOT use guaranteed delivery and also did NOT use WANoptimizer, over time any flow would eat a few bytes of memory until the flow ends. If you had VERY long running connections(say a VPN tunnel through the VPN tunnel), and/or connections that ran a long time with very small packets(say a SIP trunk), the amount of memory available to the device could actually have mattered. Also, the longer this flow lasted, (a little) more CPU would have been used.
All Gratuitous ARPs will be repeated after 5 seconds in case the first one gets lost for whatever reason.This fixes a problem with ARP on stacked nodes.

Known Issues

We are not happy with the maximum bonding throughput we are seing on the 2610 and 2620. This will significantly improve with the next firmware release. If you are interested in trying a beta, let us know.
IPv6 support had a lot of really bad bugs, one of which could cause very high CPU load. To be frank, IPv6 support has been broken since last December. As nobody complained after the last two stable releases, we assume it's not a big problem to our customers. Therefore, for this stable release we are now dropping most problematic IPv6 traffic. After this stable release, we'll re-enable IPv6 support after having fixed the bugs. If anyone of you is interested in testing IPv6 setups, let us know.
If you have both WANoptimizer and non-wan-opt connections in a QoS class (say WANopt is enabled within QoS, but the same class is used for UDP), there might be starvation of non-wan-opt traffic. Please try not to have both UDP and TCP traffic in a QoS class where WAN optimization is enabled.
There might be problems with fixed-bandwidth applications (Video streams) using the WANoptimizer. Please report back if you see any.
The 300 is very low on memory. If you want to update/downgrade the firmware after using this release, you need to first reboot the device to have enough memory. In general, WANoptimizer is of limited use on the 300 due to the low amount of RAM it has. We highly recommend using one of our 300-to-310 trade-in offers and get rid of this outdated device.
On 200 and 5xx, if you try to reach Integrated Services (web interface, ping to LAN IP, CLI etc) you will see packet loss and/or high ping times if the router is idle. If the router has some load, the problems disappear.
This is a side-effect of optimizing WANoptimizer performance for these products and can not easily be fixed. Therefore it will stay this way for this release, and it will be fixed during the next beta cycle.
In real life, this should not be much of an issue – however, it may confuse your monitoring systems (in our case, it did confuse an automated test doing a CLI login on an idle router).

RuggedVPN Stable Firmware Release April 24, 2018 – Version 2017102440/2018041200

On top of our beautiful February stable release, this firmware release is bringing a couple of important bug fixes our partners have requested.

If you wish to upgrade from a Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be in place. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on the latest version of the Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client is available both based on Classic Firmware and alternatively based on the RuggedVPN firmware generation. Both versions are still supported, but we recommend migrating to the RuggedVPN one.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2017102440/2018020600 released on February 13, 2018).

Please note that this stable release does not yet include the new WAN Optimizer feature. A dedicated beta firmware including WAN Optimizer is available through our support team and beta testers’ mailing list.

Bug fixes

Having more than 256 routes could cause the dynamic routing engine and router startup to fail.
Fixed a bug that could cause routers to reboot once every 24 days.
Fixed a problem with dynamic routing that would randomly appear on startups.
Fixed WAN modules sometimes getting stuck in “Disconnecting” state, mostly seen with VDSL.

RuggedVPN Stable Firmware Release February 13, 2018 – Version 2017102440/2018020600

This firmware release is bringing two new features a lot of our partners have been requesting. It also contains two very important security fixes. We recommend all installations to be updated immediately!

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2017102440/2017120100 released on December 6, 2017).

New features

VPN Bypass is here!
This allows you to create traffic rules that do not point to a tunnel, but instead directly to the module, where traffic will be NATted to the module's IP.
Go to WAN/VPN routing rules, enable “Allow VPN Bypass routing”, setup some routing rules pointing to a module, and have fun.
Please note that this feature is only to be used in corner cases–for example if there is a DSL router with integrated VoIP gateway behind an Ethernet WAN module, and your phones need to reach it. Remember that using the WAN module directly for Internet traffic defeats pretty much any purpose Viprinet routers have (security, redundancy, etc).
There also is the option “Module browsing tool” inside the WAN module objects if you just want to temporarily surf through a module to fill out a captive portal.
You can now add and manage DNS A records of the integrated DNS server. This allows you to configure hosts like “mycomputer.local” and have that resolved to an IP for all computers using the router's DNS server.

Bug fixes

Using repeated security scan floods for a TLS ROBOT attack could make Hubs/Routers crash and reboot.
We have now updated the Cipher suites used to completely disable RSA key exchange as recommended as a best practice.
By that, we have removed compatibility for any Viprinet classic firmware device using a firmware version older than 2015 connecting to an updated Hub.
You'll also no longer be able to use the web interface with HTTPS with very outdated browsers like IE below version 11.
We also have hardened the VPN Tunnel code in regards of future TLS attacks.
It was possible to run a DoS attack against the router by opening lots of connections against the SSH ports, then closing the SSH session on the SSH protocol layer, while at the same time keeping the SSH TCP connection open.
With the previous firmware release, it was possible that routers restarted after 24 days of uptime displaying a “Routing core stuck” message due to a timer desynchronization.
If a stacked setup was connected to a Hub, and the master rebooted, the slave took over. But if the master came back and restarted the channel, you could see on the Hub that the slave's channel might have hung in the “disconnecting” state until the hub rebooted. This was caused by the "A split brain situation has occured on the remote stacking Node, channel will be disconnected" error.
Problems with activating VPN Clients on Virtual Hubs were fixed.
In very rare chases, DSL modules can get stuck due to communication issues between the router and the module. If that happens, modules will now automatically power-cycle. There are still known issues in this regard which we are working on. Should any of your modules get stuck in “Disconnecting” state, please contact our support team.
Proper permanent fix for the “Outdated Firmware” message. The message will now always appear 1 year after the firmware's release date.
Stacking often had problems doing ARP resolves for LTE modules, rendering these remote modules unusable for the stacking master.
A whole lot of problems with the way routers handle IP fragmentation have been fixed. This will help all customers who are using fragmented IP packets (e.g. IPSec tunnels through the Viprinet VPN Tunnel, some audio/video codecs). Please note that IP fragmentation is still not recommended as it will hinder performance. You should fix any IP fragmentation you have on your network as far as you can by adapting IP payload size to your network's MTU.

RuggedVPN Stable Firmware Release December 6, 2017 – Version 2017102440/2017120100

This firmware release brings a big number of improvements in regards of stability and quality. It also focuses on vast improvements of the web configuration interface, and in supporting LTE modules.

If you wish to upgrade from a Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27, 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be in place. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client is available both based on Classic Firmware and alternatively based on the RuggedVPN firmware generation. Both versions are still supported, but we recommend migrating to the RuggedVPN one.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2017081640/2017082100 released on August 23, 2017):

New features

UMTS and LTE modules now are using a brand new APN databases that is based on the SIM's IMSI range. This means we can now differentiate between network resellers – so “Tchibomobil” SIMs on O2 will now use their own APN instead of the O2 one. The database is always updated and fresh. In case the new system fails, there is a fallback to the old MCC/MNC-based APN detection.
Drastically reduced memory usage both on Hubs and Nodes.
LAN throughput on Hubs has been drastically increased. Even if the Hub could do more, in previous releases it would at the maximum read around 250 MBit/s from the LAN only. Now it is doing 2 Gbit/s again.
Massive improvement on bonding throughput on most products. We have now seen peek bonding throughputs of >200 Mbit/s on a 310.
Now supports the new LTE-A 4.5G APAC module.
All recent LTE modules now are able to acquire the IP address on connect much faster than before.

Web interface improvements

Using the packet capture tool you can now live-view or download pcap files of traffic at various places.
In the web interface collections you can now not only add new items, but also insert them. If you use insert while being in the collection object (“Tunnels”), the item will be inserted on the top. If you have selected an item (“WurstTunnel”), the new item will be inserted in front of it.
In collections you can now move items to the top and bottom instead of just up/down.
Tunnel items may now be moved, and new tunnels inserted instead of just added.

Bug fixes

Various fixes and changes on how FEC and channel selection for it works.
Various AWS fixes for certificate management.
Some logic bugs in how QoS classes are allowed to send at what speed were fixed. This fixes the broken “guaranteed bandwidth” test cases reported by partners.
Made sure that ALL possible LTE bands are enabled before it is known which bands the module actually supports. This might fix the problems partners had with “Forgotten LTE bands”.
Now accepting silly TCP Option 14 through Viprinet tunnels.
If the internal transfer network was re-configured to something else than the default settings, Virtual Hubs no longer were able to reach the Virtual Hub Verification servers.
For WLAN Client modules, the currently seen WLAN APs are getting listed in the module info again, even if there no connection to an AP.
Previous firmware releases could reboot after running for 49.7 days, due to a 32 bit counter wrap-around. They no longer are doing that.
Fix for a workaround for bugs in some LTE module firmware releases that might cause the LTE modules of a 51x not to detect SIM cards on a cold boot.
Fixed potential KRACK WLAN security issue.
Some fixes for the “Modules are getting stuck in disconnecting state forever” problem that partners have seen.
Fix for Chrome 61 being unhappy about the self-signed SSL certificates that our routers generate for the web interface. Please note that you must manually re-generate a new SSL certificate inside the router to make Chrome happy again.
“Managed SIM Settings” have been removed from the firmware, as our managed SIMs haven't been available for a year already.
The 511 LTE images were reduced by 35MB in size. Now doing an offline update on a 511 works reliably again.
A slave in a stacked router setup was saving the config every time a change was sent from the master. It now only saves every 30 seconds max.
Also the synching now has been throttled to eat less CPU.
Under very rare circumstances, NATted ICMP-traffic coming from multiple sources (tunnels) at the same time could get one or more of these ICMPs flows get stuck.
All download tools now support HTTP chunked encoding.
In the previous stable release the LTE firmware carrier certification was not being displayed in module info.
Made sure that for custom profiles all of its settings are confirmed to really be received by the LTE chipset. This fixes all reported problems when using private APNs.
Some users were reporting the Google maps GPS tool in the web interface to no longer be working. A new Google Maps API key was added to solve this.
Starting December 1^st, all prior firmware releases incorrectly complained in the web interface to be outdated. We are sorry for the confusion.

Known issues

There have been reports that in some installations, VDSL or ADSL modules get stuck in "Disconnecting" state once they receive a new IP address during a 24h reconnect. There had been reports about this in the past, but just as today we are unable to reproduce this. If you are seeing this problem, please contact the Viprinet support team.
Under circumstances, you are not able to enable VPN clients on Virtual VPN Hubs. Please contact support if this happening to you. We will be preparing a Hotfix for this.
Deleting a VPN tunnel that had been connected within the last 3 minutes may cause a VPN Hub reboot. Please wait 3 Minutes before deleting a VPN Tunnel.
After installing the firmware update, a VPN Hub Hotspare may wrongly report the active Hub not being able to reach any of its ping targets on the LAN and WAN, wanting to replace it. This problem is gone after a second reboot. One possible work-around for this problem is to temporarily remove the VPN Hub from Redundancy Group before updating it. If you need assistance in planning the update of a large amount of VPN Hubs, please contact our support for assistance.

RuggedVPN Stable Firmware Release August 23, 2017 – Version 2017081640/2017082100

In addition to the big number of improvements and stability fixes of our July 2017 release, this firmware brings two important additional fixes. All customers should immediately upgrade to this version.

If you haven't already upgraded to the July (2016111640/2017022000) release, please also read the release notes for that version.

If you wish to upgrade from a Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27, 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be in place. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client is available both based on Classic Firmware and alternatively based on the RuggedVPN firmware generation. Both versions are still supported, but we recommend migrating to the RuggedVPN one.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2017021340/2017072200 released on July 31, 2017):

Bug fixes

Under certain circumstances traffic in one or more QoS classes would suddenly stop flowing. This could for example result in the users suddenly no longer being able to resolve IPs via DNS. This issue existed for a long time, but became more frequent with newer firmware releases. The issue now is verified to be fixed.
In some installations, with the July firmware release LTE 450 MHz modules as used in Northern Europe would no longer be detected. They now are detected on all products again.

RuggedVPN Stable Firmware Release July 31, 2017 – Version 2017021340/2017072200

This release brings a big number of product stability and quality improvements, including some important fixes against DoS attacks potentially coming in from the Internet.

The most important new feature is the option to do firmware updates of VDSL modules inside the router. In parallel we are shipping new VDSL module firmware versions that bring a lot of highly desired bug fixes and improvements.

Also this firmware now fully supports the new 4.5G LTE-A modules.

Due to the security fixes included, we recommend all customers to update to this release in a timely manner. We also recommend all customers still using Classic firmware to upgrade to this release now, as support for Classic firmware has ended more than half a year ago.

If you wish to upgrade from a Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27, 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be in place. For more information, please check https://www.viprinet.com/vlm. It is possible to have Routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client is available both based on Classic Firmware and alternatively based on the RuggedVPN firmware generation. Both versions are still supported, but we recommend migrating to the RuggedVPN one.

The list below lists all new features and bug fixes compared to the previous stable RuggedVPN firmware release (Version 2016111640/2017022000 released on February 23, 2017).

New features

You can now update the firmware of VDSL modules inside the routers web interface. New firmware images for the VDSL modules are automatically downloaded as needed, the same way the LTE firmware images are.
Firmware changes for latest VDSL module firmware version 1.91:
- VLANs now work in ADSL RFC1483 mode.
- Module now reports authentication failure to the router if the credentials are wrong during ppp dial-in.
- Ping and traceroute tools in Viprinet work again.
- Now multiple connections via the module into the world work again (for example download test tool).
- Uses most current Datapump (10.23.0.47) this fixes a lot of VDSL related sync issues.
Full support for the 4.5G LTE-A module. The module will now also display the module's Viprinet serial number in the web interface.
Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is protecting both our routers and networks behind it against a huge range of TCP/IP protocol attacks.
New logo animation on router boot-up. Nobody asked for this, but we still did it.

Bug fixes

We now allow VPN Tunnels, VPN Client Tunnels and Channels to be deleted while they still are enabled (but not connected). This is changed to work around a bug in the VPN Client that can get stuck in an unclean state on startup forever, trying to delete an enabled tunnel. But in general this should also improve convenience for all of our users.
This release fixes the problems the LTE Europe/Australia/Africa module has with reading some SIMs.
Fixed wrong time zone calculations being done on 200 and 5xx products, causing wrong log time stamps etc.
Under rare circumstances a channel that was disconnecting uncleanly could get the routing core stuck.
Under very rare circumstances access to some objects that were used by the routing core in that same moment could get it stuck (this could be reading SNMP, web interface, CLI or router stacking communication).
On newer devices that were using an asynchronous hardware crypto accelerator, an unclean channel disconnect could cause the router kernel to crash, panic and reboot.
Stacking masters could sometimes get stuck if a lot of changes were going on on channels and/or WAN modules that were synchronized between routers.
A slow memory leak would cause the Hub to run out of RAM after a few days. This was mostly seen when using FEC.
The Virtual VPN Hub's clone detection potentially could wrongly flag your Hub as a clone if time on our backend server cloud was de-sychnronized.
SSL handshake timeouts are now much more relaxed, which should result in less SSL handshake errors on unstable WAN connections.
In case that the router has to reboot (due to a routing core being stuck, being out of memory, etc), it will now first try to write a copy of the log file to flash memory. This means that in future our support team will be able to diagnose a Hub/Router after a reboot, even if you did not have a local syslog server.
The designated stacking master will now use its own uptime instead of the one reported by the current stacking master. Also the logging has been improved and should be less confusing now.
Fixed timing problem in Dynamic routing which resulted in "Duplicate Route received" on the remote side.
The property "Distribute via Dynamic routing" in Additional LAN Routes was not used.
A node connecting to a Hub could end up with 99% CPU forever in case the TCP connection broke down in the middle of the handshake.
The "Guaranteed delivery" QoS feature/setting under rare circumstances was able to cause router crashes and memory leaks. The feature is disabled in this firmware release and will come back later. No matter what you set in the QoS now, in this build guaranteed delivery will not be used (it does not change your setting).
As a protective measure on the Hub side, we will now close a channel connection if during authentication more than 10 errors have occurred.
Implemented code that checks Ethernet/IP/TCP/UDP/ICMP packets in detail when coming in from the LAN and when going out. This is to make sure that under no circumstances we are sending out garbage that might crash the kernel.
Reduced the number of packets read from the LAN in one go. Before, if you flooded a Hub on the LAN interface with packets, the router was hardly able to handle anything else anymore – it could get the routing core feel stuck.
On Hubs, there is another safeguard that a broken cached SSL session will not be re-used. This fixed the floods of SSL Handshake errors some customers have seen before the routing core got stuck.
Fragmented IP packets that span more than 32kb could cause memory corruption and would then make the router crash. We have seen this in the wild, potentially part of an attack against a customer.
When a Hub was switching from Hotspare to Replacement mode, some part was internally crashing. The Hub recovered from this, but it involved a system reboot. Due to this, failover was slower than intended. It is much quicker again now.
LAN IP Aliases accepted invalid IPv6 addresses. They no longer do.
Applying settings in DHCP services logged an internal error message for no reason.
Changed SSH CLI RSA Key length from 1024 to 2048 bit.
Until now, if you flooded a Viprinet device with ICMP ping packets, after a while it stopped responding and never answered ICMP again.
The tunnel will now auto-reconnect in case a Fatal Error is experienced while trying to read a packet from a channel.

RuggedVPN Stable Firmware Release February 23rd, 2017 – Version 2016111640/2017022000

This release brings two major new features: OSPF and BGP dynamic routing, and SMS support including SMS auto-responders.

In addition, this release brings a very big number of bug fixes. Thanks to our partners and beta-testers, this release has undergone long and detailed testing. We recommend all customers to update to this release in a timely manner. We also recommend all customers still using Classic firmware to upgrade to this release now, as support for Classic firmware has now ended.

It is possible to have Routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client right now is still based on Classic Firmware, and therefore will connect in compatibility mode. A RuggedVPN-based VPN Client will become available soon.

The list below lists all new features and bug fixes compared to the second RuggedVPN firmware release (Version 2016111640/2016120100 released on December 12^th, 2016).

New features

Dynamic routing with BGP and OSPF is now fully supported on both Hubs and Nodes.
LTE modules may now send and receive SMS. There also are auto responders which you can configure to automatically reply to incoming SMS. Using this feature you can now use our products with LTE providers that offer data-plans where you can add data packages by sending an SMS. For example Vodafone Germany will send you an SMS "Your high-speed data has been used up, reply with "5" to book another 5GB". With the auto responder feature you could create a filter on "high-speed data has been used up", and have the router reply "5" in this case to automatically book a data package. Please note that this feature due to chipset limitations sadly does not work on the LTE 450 and 4G Europe II modules.
Viprinet Virtual Hub config is now compatible with hardware hubs, which means you can copy a config file from or to a hardware router and use it.
Internal improvements in RAM management reduce the amount of RAM and address space used a lot. Memory usage on a heavily used Hub should increase much slower than before.

Bug fixes

New improved behavior for disabled tunnels on VPN Hubs: Instead of letting tunnels, clients or channels connect and then have them disconnected again if disabled (or the VVH identity not being ready), we now reject them directly while they are trying to connect. Also added some throttling.
Viprinet Virtual Hub: Improved startup system to make sure the VVH is not flooding with incoming Tunnel connections before being ready to accept them
Viprinet Virtual Hub: If the DNS was unreachable on VVH startup, it would take up to 5 minutes until the identity server's hostname could be resolved again.
Viprinet Virtual Hub: Users can no long acquire a new device identity unless the device is marked to be a "Copy"
Fixed SFTP support
In the WAN module info of LTE modules you could sometimes see garbage text behind "Country:"
Fixed the web interface sometimes not showing the summary list of all items when selecting a list object.
Fixed stacking slaves not having their channels used after restart
Removed lots of JS debug output lines in web interface
Fixes an unsynchronized access inside the web interface Ajax message system. This could cause routers to get stuck and/or the Object tree would no longer being accessible in the web interface, and other errors. This most often appeared when executing "Contact license server" manually from the web interface, or when disabling a Tunnel on the VVH.
Now reports an error in case a license de-activation has failed
Fix for ADSL/VDSL modules sometimes no longer being usable if they get assigned a new IP in a 24h reconnect without the interface going down/up during that reconnect.
Made sure that expired licenses/subscriptions are not counted as valid tunnel licenses on the VVH.
Drastically improved upstream autotuning results on RuggedVPN VPN Client by a factor of 10+.
As our routers, the RuggedVPN VPN Client will now also tune the TCP sendbuffers. We've seen this stuck at 8k for Windows, so this gives a HUGE performance improvement over high-latency links.
The HTTPS download test tool would accept SSL certificates that are valid, but expired
If on the Hub no DNS was configured to be assigned to VPN Clients, the VPN Client would block during connect for 10 seconds. This delay no longer exists, speeding up VPN Client connection time dramatically.
Routes pointing to invalid targets could not be deleted.
2620 routers believed their Bandwidth Capacity to be 200 Mbit/s instead of the 400 MBit/s they can do. They also reported a wrong capacity over the tunnel to the remote device. In practice that should not mean much, but under certain circumstances / loads from LAN this could have limited the total throughput the router can do, and it also would cause the Hub to use a wrong assumption on total capacity for bandwidth auto-tuning.
Made sure HTTPS web server is disabled for the VPN Client
Added log prefix for HTTPS errors showing the remote IP that caused this error
Improved identity handling of Viprinet Virtual Hubs. In case a VVH gets flagged as clone you can now resolve this by shutting down the clones. After a while the one remaining ex-clone then is flagged as verified again.

Known issues

Internal transfer network for virtual hubs must not be changed.
Dynamic routing tries to handle VLANs and segmentation as good as possible, but not all setups may work. There are no separate routing tables.
To configure the SMS features on a 510, a SIM has to be present for the module.
Disabled VPN Bypass for now.

Notes in regards to Dynamic Routing

To active the dynamic routing feature you will need to install the Enterprise Node Features software license on the Node side. So this feature is built-in on any Viprinet Hub and of course on the 2610/2620 for free.

A new web interface object "Dynamic routing settings", also including two new tools "Full routing table" and "Viprinet routing table".
Allows you to dynamically distribute static LAN/WAN Viprinet routes.
Push / Accept routes per tunnel. You can find this setting in each tunnel. The standard use case is to enable Push routes on the node side and enable Accept incoming routes on the hub side. I'm sure you will find a scenario where it is useful to use it in both directions.
You can select which interface should speak in which area and if it should be used for dynamic routing (OSPF/OSPF for IPv6 only).
WAN/VPN routing rules, VPN Client pools, LAN IPs and additional LAN routes can be distributed.
The Viprinet router is able to announce itself as default gateway, but it will ignore default routes announced by other routers.

Two example cases

Case 1: Use the new Tunnel protocol to send all node networks to the hub so the hub can route them (No static WAN/VPN routing rules)

Hub side: Enable "Accept incoming routes" in the selected VPN tunnel
Node side: Enable "Push routes through tunnel" in the selected VPN tunnel

After enabling these settings, the tunnel needs to be reconnected. The Hub should now receive all node networks and route them in the right tunnel.

Case 2: Extending Case 1 with a dynamic routing service

First configure the Node and Hub the same way as in case 1
Additional to that configure/enable on Node and/or Hub side the Dynamic routing service and the service you want to use (BGP, OSPF or OSPF for IPv6)

All networks incoming on node side will be also known by the Hub and can be routed. Make sure you have enabled the check mark "Distribute local Networks" in the service you want to use. Otherwise it will not be distributed. If you also enabled a dynamic routing service on the Hub side it can distribute all Node and Hub networks to the Uplink router.

Warning/Hints

BGP only: To start the service, you need to configure at least one BGP neighbor. You can find the BGP neighbor object under "Integrated services" " "Dynamic routing settings" " "BGP settings".
OSPF/OSPF for IPv6 only: For starting the service, you need to configure an interface to use in the LAN settings object; there, you can also configure the OSPF area.
VPN Tunnels: Changing "Push routes through tunnel"/"Accept incoming routes" needs a tunnel reconnect to take effect.

Known issues

OSPF/OSPF for IPv6: Password authentication doesn't work.
Default routes announced by other routers are getting dropped right now.

RuggedVPN Stable Firmware Release December 12th, 2016 – Version 2016111640/2016120100

This release brings two minor error corrections. All existing customers should update to this release in a timely manner. We also recommend all customers still using Classic firmware to upgrade to this release now, as end of support for Classic firmware is nearing.

The list below lists all new features and bug fixes compared to the second RuggedVPN firmware release (Version 2016100640/2016102400 released on October 28^th, 2016).

New features

There are no new features in this release.

Bug fixes

Starting December 1^st, 2016, all previous releases started to display an annoying pop-up when logging into the web interface, claiming the firmware to be out of date and out of support. This even was the case with the most recent firmware release from October 28, which is perfectly fine and covered by support. The popup has been removed. We apologize for any inconveniences.
This releases fixes an encoding bug that caused VPN Clients connected to RuggedVPN Hubs to be unable to display Downstream and Latency graphs in the Monitor tab.

RuggedVPN Stable Firmware Release October 28th, 2016 - Version 2016100640/2016102400

This release brings very important improvements in regards of product performance, quality and stability. All existing customers should update to this release in a timely manner. We also recommend all customers still using Classic firmware to upgrade to this release now, as end of support for Classic firmware is nearing.

It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client right now is still based on Classic Firmware, and therefore will connect in compatibility mode. A RuggedVPN-based VPN Client will become available soon.

The list below lists all new features and bug fixes compared to the third RuggedVPN firmware release (Version 2016080240/2016080800 released on August 11th 2016).

New features

There are no new features in this release.

Bug fixes

Channel shutdown/disconnect has not been clean for a while. We suspect that this could have lead to system crashes. In less-fatal situations it gave you SSL errors on disconnect, or had channels time out for up to 5 seconds instead of cleanly disconnecting right away.
On certain products (310, 2620, 2030, 5000, 5010) the hardware crypto engine could crash during channel disconnects. We believe that this bug is the reason why customers running routers under high stress (Satellite connections, ships, vehicles with lots of reconnects) are seeing devices reboot, while others don't.
Fixed stacking slaves having a calculated MTU < 1500 not getting that MTU used. This fixed slave channels on a 500 stacking slave (or anything that uses PPP) not getting used.
Fixed automatic connect to the License Server, which did not work before (you had to manually connect to received updated licenses)
Reverting back to not dialing directly for LTE modules, but instead modifying to profile to trigger call. This means that those customers complained about problems with private APNs prior to the current stable release now will have these problems again, but they can use the custom WWAN profile feature to work around. We had to revert this because with the new way of dialing Verizon in the US did not work at all anymore, and also problems have been reported from the UK.
Fixed demo and project routers not being able to use stacking slave channels. Please note that you have to re-select the remote WAN module inside the channel after updating to this fixed firmware.
Fixed popup message on demo routers to not say that the demo runs only 14 days, but correctly state that it is 90 days.
Re-factored the way statistics about flow source and destinations host are managed. Before a DDoS attack using spoofed IP addresses could eat up all the RAM and a lot of performance. The system now no longer can be put out of service flooding it with spoofed IP addresses, and in generally also performs better in scenarios where a huge amount (1000+) of LAN devices are using a Viprinet router.
In case of certain kind of DoS attacks, the routingcore thread potentially could have gone stuck, causing the router to reboot about 90 seconds.
In case a DDoS attack is detected as likely, messages on this are logged, at the maximum once per minute.
A bug in memory handling of IP packets has been corrected. This bug could cause both a small memory leak accumulate over time, but also could cause crashes under certain circumstances.
Setting an IPv6 address as main LAN IP address (instead of adding the V6 address as an Alias) wasn't supported but not prevented, which could result in the router becoming unreachable from the network. It's no longer possible to set an IPv6 address as the main LAN interface address.
The retransmission manager used for QoS classes having "Guaranteed delivery" enabled had a bug which first of all was leaking memory, but also could have resulted in half of the retransmissions not taking place. This means that a flow going through the tunnel could have seen packet loss even with Guaranteed delivery on. This could have dramatic consequences: TCP/IP header compression used builds on the guarantee that there never are lost packets. This means that if a flow used guaranteed delivery and then a channel had packet loss, the flow could get stuck.
Fixed log output of TCP Sequence numbers (the numbers could be logged negative). Also lowered log level of very common TCP violations caused by broken scanners, no longer claiming that you are under attack.
Make sure stuck stream downloads are aborted. This bug could have resulted in download tests doing in the webinterface eating 99% CPU if they get stuck.
The routing core could get stuck on the receiving side of flows. Very rare, depending on timing. You could be running without a stuck routing core for weeks, and then suddenly have it getting stuck all the time.
Individual high-load guaranteed delivery flow receivers could get stuck after a tunnel reconnect, and while doing so could eat up memory.
The receive-side timeouts for non-guaranteed flows that make sure that we wait long enough (but not longer than) for all fragments to arrive is based on the assumed bonding latency of the combination of channels used. The filters used weren't fine-tuned, and not suitable at all for satellite connections. These non-tuned values could cause packets getting dropped receive-side (because the router would not wait long enough for all fragments of that packet to arrive). This could result in the receiver being at fault for not being able to use the full tunnel speed downloading from/through the tunnel. The filters have been completely rewritten.
The "Average latency is ... ms, maximum allowed is ... ms, no alternatives, keeping channel." message is gone, as is the underlying idea: It does not make sense to keep the last channel with a latency higher than the maximum allowed one. If the last channel drops out for a moment, the tunnel layer will do the buffering.

RuggedVPN Stable Firmware Release August 11th, 2016 - Version 2016080240/2016080800

This is the third official stable release of the RuggedVPN firmware. This release brings very important improvements in regards of product performance, quality and stability. All existing customers should update to this release in a timely manner. We also recommend all customers still using Classic firmware to upgrade to this release now, as end of support for Classic firmware is nearing.

If you wish to upgrade from a Classic firmware, please first update the router to the last stable Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Please note that upgrading your firmware from Classic to RuggedVPN requires a Viprinet Lifetime Maintenance license to be in place. For more information, please check Viprinet Lifetime Maintenance.

It is possible to have Routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanently, but it is OK to have a Classic firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client right now is still based on Classic Firmware, and therefore will connect in compatibility mode. A RuggedVPN-based VPN Client will become available soon.

The list below lists all new features and bug fixes compared to the second RuggedVPN firmware release (Version 2016040640/2016061000 released on June 17th 2016.

New features

You can now create custom LTE WWAN profiles, which might be needed for some carriers or users of private APNs. Please note: The default APN profile settings have changed. Please verify that your LTE provider works fine with these new profiles before mass-deploying this release.
Hubs in Hotspare mode now have working ACLs (and internally run our full routing stack, which they did not before). Finally this enables using the Service ACLs. This is important because without them, the DNS service on Hubs running in Hotspare mode could be used as amplifiers in DNS DDoS attacks. Please verify you have ACLs in place after upgrading to this release.
The CPU usage of tunnel channels on Nodes has been decreased. This may result in slightly higher total bonding capacity especially when using a lot of channels (stacking).
The CPU load when a Hub or Node receives a very high number of new connections at the same time (for example during a port scan or DoS attack) has been reduced significantly.
The routing core latency now is as low as never before. You can ping the router with a response time of <3ms now.
LAN throughput has been increased, CPU load for LAN traffic decreased.
LTE-TDD Bands B38 and B40 are now validated to work. The 4G Europe/Australia/Africa module now has a working AT command tool, and is now ready for production use.

Bug fixes

Multiple bug fixed for the WLAN Client module which improves compatibility and now also allows connecting to unencrypted APs.
QoS bonding priorities did not get copied when using QoS restore from/to templates.
On stacking slaves a 24h disconnect or the ISP re-assigning the IP while connected could cause the router to eat 99% CPU permanently.
Hubs in Replacement mode would complain about not having VLM installed. They no longer do that.
Heartbeat diagnostics ("A single router is gone from the network") is now only shown once instead of every second.
Log messages have leaked memory if the web interface was used without web sockets being enabled. This could grow to a significant amount of memory if the web interface was opened for a very long time with the router producing a lot of log lines (very busy Hubs).
Fixed a memory leak when the router was dropping IPv6 broadcast traffic it was seeing on the LAN.
Fixed a small memory leak in the configuration system. On stacked nodes doing lots of configuration syncs (for example because very unstable channels are used), this could grow to a significant amount.
The memory usage of Hubs that see a very high number of concurrent flows (50000+) has been reduced.
The internal packet slicer (which is used to cut IP packets into slices that are then sent over the channels) under circumstances (especially with a high number of channels, unstable channels and/or FEC enabled) could leak significant amount of memory.
The LAN NIC no longer can get stuck, and in worst-case a LAN reset will always actually bring the NIC back to life now.
A WLAN Client module could cause the router to eat 100% CPU. This is fixed.
The default Autotuning mode for newly created channels is now Hybrid instead of Heuristic.

RuggedVPN Stable Firmware Release June 20th, 2016 - Version 2016040640/2016061000

This is the second official stable release of the RuggedVPN firmware. We recommend all customers still using Classic firmware to upgrade to this release.

It is possible to have routers and Hubs running on Classic firmware connect to a device running RuggedVPN firmware. However, a compatibility mode will be used in this case, which limits performance and features. It is therefore not recommended to use such a setup in production permanentely, but it is OK to have a Classic Firmware device talk to a RuggedVPN firmware device while you are upgrading these devices. The Software VPN Client right now is still based on Classic Firmware, and therefore will connect in compatibility mode. A RuggedVPN-based VPN Client will become available soon.

The list below lists all new features and bug fixes compared to the first RuggedVPN firmware release (Version 2016040640/2016040300 released on April 7th 2016.

New features

You can now define preferred LTE bands in the Enabled Mobile Technology settings
Changes in celltowers are now recorded and logged. Also there is a function to manually re-scan all enabled LTE bands. And finally there is an optional feature to automatically scan all enabled LTE bands if we have seen UMTS only on two celltowers. This is useful for moving vehicles which pass through areas of bad coverage, and then come back to an area where LTE is available. Without this feature the module would have been stuck on UMTS forever to not interrupt the channel connection. If this auto re-scan is enabled in this case the module will disconnect the channel and itself to re-scan LTE.
Google maps tool will now live update the markers position when the router is moving, you no longer need to refresh.
Created better QoS default templates including VPN protocols like IPSec. Use the restore Manufacturing defaults function to see those. If you are using the router in a vehicle, we strongly recommend to enable FEC for all QoS classes.
SNMP: added CellID to SNMP and performance data. Also vpnRouterInterfaceIndex is now also right. This was always 0 for WAN modules in the VIPRINET-MIB

Bug fixes

Limit notices on expiring maintenance licenses if the license expires in < 7 days.
Updated all firmware-related warnings, added a warning for unlicensed firmware in case VLM is not installed.
310/2030/2620 did not turn off the logo on system reboot in previous releases.
Fixed log warning for demo routers to no longer count from 14 days downward, but from 90 days.
Updated text inside SNMP Settings to include 2620 and 2030 models.
Added missing maintenance license types for Hub 5000 - before, any maintenance license or warranty extension a Hub 5000 had was fully ignored.
Changed login popup to not warn if a maintenance license runs out in <28 days, but instead only if <7 days. This is because in a subscription, you license always will be only valid for 30 days unless you select a long interval, and therefore constantly warning about it is bogus.
Fixed the way items are deleted - depending on selection order sometimes some items could not be deleted before. Deletion list is now sorted before doing anything, so it also no longer breaks if you select some items from bottom to top holding the CTRL key.
A Loading mask will not be shown on loading objects if a roundtrip of a websocket connection is <500ms. This makes the webinterface snappier if used locally on a router.
Object editors are automatically reloaded if the object was changed. However, now if you are currently EDITING an object (cursor inside any input element) the object editor will no longer be reloaded.
Moving items up and down in the item list of a collection now works as expected without any reload. The tree view is automatically updated while moving items up and down
If an object changes (for example module rename), the tree view now should correctly automatically update again
This release fixes two different bugs that could cause the routingcore to freeze for up to 30 seconds, causing all tunnels on a Hub to disconnect.
Fixed "Slot 6 - 4G Americas for AT&T USA contains illegal characters." message
Fixed / workarounded dhcpd sometimes not starting up in stacking setups
Changed latency autotuning to not go over 1000ms by default. If you are using Satelite, you should not be using latency Autotuning anyway
If you enable FEC in the web interface, it will automatically set the preferred number of channels to something that makes sense - 3)
For WWAN modules, on their first attach to a network in a lot of cases the network name was reported as empty due to Qualcomm bugs. This was confusing the Signal monitor tool, too. In these cases the Networkname is now retrieved using an internal database if not reported by the modem.
The monitor tool for WWAN modules typically would have every slot twice - once as "Slot 1 - WWAN (3G/4G)" and once as the final module name. This is now fixed in the router code. You now should no longer see the "Slot 1 - WWAN (3G/4G)" entry
The whole logic of adapting entries if you set a duplicate entry for first/second/third bonding priority didn't work at all. It's removed now, so you will no longer see one bonding priority suddenly beeing set to none etc.
Once again fixed multiple bugs that on a router power cycle could cause WAN module configurations get lost.
Applying QoS templates did not actually copy most QoS class properties
The GUI and the CLI got unavailable if you had an "empty" routing rule having only a tunnel assigned.
The code reading packets from the LAN NIC had multiple issues: For other Ethernet types than IP/IPv6/ARP, it would still treat this partly as IP, therefore using unknown random data as IP, before then dropping this. This could indirectly also cause access violations. This has caused internal error CA23AA32932FFFF1 (aka BACEE2923EEEEEEB)
For tagged VLAN traffic, multicasts that the router should listen to got completely dropped
Multiple bugs in how IPv6 packets are handled, the flow hashing was completely broken, and you might have seen oversized IPv6 coming out of tunnels (which then might got dropped by user operating systems)
When reading the VLAN Id from the NIC, IEEE 802.1Q / IEEE 802.1p flags weren't filtered, resulting in bogus VLAN Id numbers.
After reading a packet from the raw NIC, some basic sanity checks are now done BEFORE the flowhash is calculated. Without these checks it before was possible to cause an internal error by sending an invalid TCP Header with size 0 to a Viprinet router.
The 55-... demo routers did complain about not having a VLM license, which they don't need at all. They now should no longer complain.
Fixed channel connect error if SSL Resume was enabled on boot-up and was used while it shouldn't (because there can't be a cached session after bootup). Now for the first time it is safe to enable SSL session caching, which speeds up things in mobile scenarios a lot (and lowers CPU usage dramatically)
Removed forgotten debug messages

RuggedVPN Stable Firmware Release April 11th, 2016 - Version 2016040640/2016040900

This is the first official stable release of the RuggedVPN firmware, which has been in beta status for well over a year. We recommend all customers still using Classic firmware to upgrade to this release.

The list below lists all new features and bug fixes compared to the last Classic firmware release (Version 2015081830/2015102900 released on November 27th 2015). Yes, it's a lot.

New features

Full IPv6 support for LAN interfaces and Tunnels
WWAN Image manager and switcher. On modular routers you can now flash firmware images to WWAN/LTE modules, to keep those updated. WWAN firmware images will be downloaded as needed from the Internet and cached.
On 511/512 routers instead all possible WWAN images are shipped in the router firmware, there you have a switcher tool to switch the firmware the module uses (which does not require a download from the Internet).
The CLI is completely reworked. It now includes tons of tools also available in the web interface like ping, traceroute, wan interface info etc.
The web interface finally uses HTTP keep-alive and Websockets. You should see a dramatic increase in responsiveness.
Single and Double forward error correction - similar to a harddrive RAID5 (single parity) or RAID6 (double parity), the router can now automatically correct and replace IP fragments lost on a fluctuating line. Single Parity mode is available without extra licenses, Double Parity requires a Streaming Optimizations license.
New optional Data compression for QoS flows - you can select per QoS class if you want data compression or not. On typical office traffic, data compression will get you additional 25-30% of throughput.
You can select per QoS class "guaranteed delivery" - if this is enabled in worst-case if a packet can not be reconstructed through DFEC it will be retransmitted. You always should have 0,0 packet loss using this mode.
We did a little bit of overengineering here - the retransmission system is extremely clever and needs minimal overhead for acknowledgments, and it does not retransmit actual packets but only the minimum amount of redundancy information missing to enable the other side to reconstruct data. It is MUCH faster and more effective than relying on the TCP retransmissions of your data connection instead. The system however does eat a lot of CPU.
By default guaranteed delivery will be off - only a very limited amount of applications will make use of this feature.
You should use guaranteed delivery for applications that behave really badly on a lost packet - for example video codecs that would drop all further video frames until the next key frames.
Without guaranteed delivery you will get a more stable latency and no jitter, as retransmitting takes time. You will therefore have to test with your application what works better in real-life - having a dropped packet in the very unlikely case that line conditions change that quickly that the DFEC didn't see it coming or having a retransmission in this case which could make your data "stutter" for a short moment.
It is our experience that for hard live (video conferning) depending on the codec guaranteed delivery should be either on or off, and for everything that has a buffer of 1000+ms (video streaming) that guaranteed delivery should be on.
Huge speedup for log output in new web interface. Even with a huge amount of log messages, the web browser no longer should freeze.
The License manager is now able to do an automatic online check. All registered licenses will be automatically fetched to the router (provided the router has access to the Internet).
For 511/512 routers, the WLAN AP can now use AC mode. Also, the WLAN AP code has been rewritten. Depending on what region you are selecting, all channels that are allowed for this region are available.
VLAN tunnel transport
The idea is this:
Inside the Routing object you can create VLAN aliases. You then can refer those both in the Module settings and inside the tunnel settings. For the tunnel, you can select multiple of these VLANs.
Now, all traffic coming in from a LAN VLAN will be forwarded to the tunnel if that VLAN is listed for the tunnel. If it is not listed, the packet will be dropped. The packet inside the tunnel is TAGGED, so on the other side (the HUb) the packet will exit the tunnel with the same VLAN tag - and if you don't have enabled the VLANs for this tunnel on the Hub, the packets will be dropped there. Due to this someone in control of a Node can not just send a VLAN tag that does not belong to him to get access to a different tunnel segment/customer on the hub.
The previous tunnel segmentation ID setting is kept - this is now used for packets coming in from the tunnel which do NOT have a vlan tag (like it was in classic firmware), these packets will get the VLAN tag configured here. This way you can still use VLAN tagging and tunnel segmentation on the Hub, but not doing any VLAN settings on the Node.
If you wish to map multiple VLANs coming from/to the Tunnel to the local LAN interface of a Node, the Node needs to have a "Enterprise Node Features" license installed (with the exception of the 2610/2620 routers, which being Enterprise-level devices get this feature for free.)
Every WAN module now has a subobject "Performance data", which you can access through the web interface and CLI etc, whenever you poll with SNMP, the data will also be updated. At most, internally this will update every 5 seconds if constantly polled. Reading this data using SNMP requires an "Enterprise Node Features" license to be installed (again, 2610/2620 have this feature included for free).
Support for LTE450 modules
Enabled Mobile Technologies now gets defaults set as soon as the modem type and carrier certification is known. For LTE450 for example, only 450 Mhz is enabled by default, for 4G Europe/Australia CDMA is disabled etc.
A total of channel bandwidth for all connected tunnels is now displayed in the Tunnellist object. This makes it easier to see what bandwidth a Hub is using right now.
SSL Session and Channel handshake caching is now used for VPN Tunnel connections. Due to this, Node channels constantly reconnecting to Hubs should no longer cause high CPU load on those. We have seen a dramatic improvement for everyone who is running VPN Hubs for Nodes in moving vehicles. On a customer VPN Hub serving vehicles the CPU load has dropped from 65% down to 2%.
This feature also means that a channel that needs to reconnect on a module with say100ms will no longer need 1+ Seconds to re-establish the channel, but only a fraction of that. We believe that this is a huge improvement, and a lot of customers will love it.
Added VLAN Ids to routing rules and QoS rules. With this new feature you can now limit routing rules and QoS rules to match a TunnelSegmentation / VLAN Id.

Bug fixes

Should during a cold router boot-up a module missing that previously was configured (and is stored in the config) we'll now wait for up to 30 seconds for the module to re-appear. This is because on routers booting up quickly at this point a 4G module might not yet have fully booted and therefore isn't seen at the moment the configuration is loaded and applied. This could with bad timing result in the module losing its configuration.
This should fix all the problems we never before could reproduce where customers had LTE modules lose their configuration if powered up sometimes.
Security improvement: Added a TLS security fix against the RSA CRT attack
Security improvement: SSLv3 and SB_SUITE_RSA_RC4_SHA are no longer used for the web interface (Which means IE6 is no longer supported).
Security improvement: The only ICMP packet types accepted to be sent to the routers are now ICMP_ECHO, ICMP_ECHOREPLY, ICMP_UNREACH, ICMP_TIMXCEED, all other are filtered. This is in response to a security audit - you will no longer be able to get TIMESTAMP replies, which are a potential attack vector, from a Viprinet router.
Hubs now know what model they are even in Hub replacement and hotspare modes. In Hotspare modes therefore licenses are now regarded as valid (before the check failed as the router model wasn't "known"). Also removed text that says you can not use the license manager in Hotspare mode, you now can.
A Classic VPN Client connecting to a RuggedVPN Hub could get sent packets bigger than 1500 bytes (due to a missing unpadding), which would result in Internal Error - Code 12A8922323111132 in the VPN Client.
Hubs will now report an error to the log in case the remote router has sent one during tunnel negotiation. Also the "Connection dropped due to command timeout" message now will only be used if the connection actually was closed due to a timeout.
Sometimes due to a race condition the SIM may be unlocked but reading the IMSI and HomeMCC/MNC will fail due to the SIM not being ready. In this case reading it is retried. However, the code for re-trying to read the MCC was buggy, so this never worked. This is the reason why APN Autodetection was failing on some LTE modules since a couple of releases.
For interface traffic counters, resetting a counter more than once would result in wrong values.
If a WAN module was reconnecting often or didn't get an IP, the channel using it could cause Internal Errors and/or the router to reboot.
Sometimes when rebooting or when switching from slave to master mode on a stacking router, some LAN services would randomly not work.
Resetting a module (manually or automatically) would block the main timer of the router for up to 2 seconds. This could cause unrelated channels to stall and disconnect.
A 511/512 constantly resetting the module after a while could run out of file descriptors and no longer be usable. This should no longer happen.
Fix for VDSL RFC1483StaticIP (a modem fix is also needed)
The maximum number of connections for hotspare config transfers was undefined (never set), and therefore depending on the build random. Due to this on some firmware builds this feature has worked, while on others you could not have Hubs do config transfers.
Multiple crash bugs in the stacking system have been fixed.
If a router was under low memory conditions, it could fail running scripts, causing all kinds of things to fail - for example modules dialing in. If this happened you could typically not even reboot the router.
Assigning an IPv6 address to the main LAN interface caused a reboot loop. This is now forbidden and prevented, v6 addresses may only be used on LAN aliases - different parts of the product still rely on an IPv4 address existing on the LAN main interface.
NTP does now work on Hub Hotspares, too.
The way that the LTE modems are dialing out have been changed for the 4G Europe/Australia, 4G Europe II and 4G Americas modules. This fixes the problem of the modules with recent 05.05.58 firmware no longer being able to connect to AT&T and T-Mobile in the USA.
For some carriers, the new "4G Europe II" module reported the network string in 7bit encoding, resulting in garbage network name.
Fixed 4G Europe II module reporting wrong expected link capacity values, also fixed all other 4G modules sometimes reporting EVDO while on UMTS, also resulting in wrong link capacity values. Wrong link capacity values could result in channels using these modules not to use the full speed they actually could.
Due to a race condition in the module, reading IMSI or Home MCC/MNC from SIM may fail directly after SIM unlock. This in turn could cause the APN Auto Detection not to work. In this case this is now retried later.
Reboots of routers should now never fail even on low memory conditions