Firmware Cutting Edge

A valid Warranty extension license that has not expired is now also counted for "Under Maintenance Contract". If your router still has Warranty left you therefore now are able to upgrade to RuggedVPN even if you haven't yet converted your Warranty license to a Viprinet Lifetime Maintenance contract. For warranty extensions we now also display how much days are left on it.

• A rare crash bug on VPN Hubs caused by outdated VPN Clients connecting was fixed.
• After router boot, a stacking master node could fail to bind its communication socket under rare circumstances, causing stacking slaves not to be able to connect to the master, which in turn would cause a split brain situation.
  In this worst case, the stacking master will now instead reboot to resolve this split brain.
• In very rare circumstances two stacking nodes right now being in a split conflict while at the exact same time reconnecting to a Hub with the tunnel previously having been disconnected for less than 3 minutes could cause the Hub to crash.
• In SNMP, vpnRouterCPULoad was exported as string instead of integer as it should be.
• For VDSL Modules the sync speed reported in the log ("Synched Downstream/Upstream Rate") was swapped. The actual values used were correct, so this is a display issue only.
• In case a VPN Hub had an invalid DNS resolver configuration, doing the DNS reverse lookup for incoming channel connections could take very long. In case of a lot of channels reconnecting, this could delay any connects to complete for a very long time. Now, incoming channel connections are no longer reverse-resolved.

• Using multiple of the new 4G modules could completely block the router in case the module had been unable to read home network information from the SIM.
• Network name display for some carriers (e.g. T-Mobile) was broken for the 4G Europe II module.
• Under very rare circumstances, corrupted SSL data could cause the Hub 5010 to crash and reboot.
• 4G modules used in a stacking slave for some mobile networks have been unable to connect.
• Under rare conditions WWAN modules may fail to read the IMSI and Home MCC/MNC from the SIM, causing Automatic APN Detection to fail.
• APN Database entries updated for AT&T USA, Rogers and Telus Canada.

• Default congestion control now is cubic, default autotuning Hybrid. There have been significant improvements to the Hybrid autotuning mode.
• Full support for final version of VDSL modules.
• A new HTTPS CA database is now used, which includes support for various CA's customers have requested.

• Managed SIMs got disabled after an hour of the activation server being unreachable, while they are meant to be disabled after 24 hours.
• When a VPN Client disconnected and a different client user later connected with the IP of the previous user getting re-used, this could cause to the VPN Hub crashing and rebooting.
• Access Point Settings were missing the option to configure administrative rights.
• On router startup, the error message “The tunnel password for the tunnel contains illegal characters” was printed to the log.
• If two or more WAN modules were power-cycled exactly at the same time, sometimes the modules would not come back, with a router reboot needed to get back the modules.
• TKIP is now disabled for HT clients on 5XX WLAN AP in 802.11n.
• Manual firmware updates may now also be uploaded if the automatic firmware check resulted in the “UpdatesAvailable” status.
• All 51X routers have their configuration files now marked as compatible to each other. Before 511, 512 and 513 weren't allowed to use 510 configuration and vice versa.
• Fixed Hub 5000/5010 picture size in web interface.
• If the SSH CLI was activated, a connection flood to port 22 could be used to run a DoS attack against the router.

• Sadly, the Cutting Edge Firmware released in July is suffering from a compiler bug on the Multichannel 200, 500 and 51X series. This bug can cause some subtle and hard-to-notice weird behavior. But even worse, with hosts doing lots of traffic flows, the router sooner or later can have all traffic flows stuck, wrongly accusing that host of doing a DoS attack and no longer allowing new flows from that host.
  This bug effectively can make some or all of your hosts in the LAN to sooner or later to no longer be able to talk to the router or the VPN/Internet!
  We therefore urge all our customers who have updated 200, 500 and 51X routers to July's Cutting Edge firmware releases to immediately update to the August release! No other product is affected by this bug. We apologize for any inconvenience. We have updated our internal test suites to be able to detect similar bugs in the future.
   
• New channel finetuning option “Save traffic when idle”: needed for Vodafone UK not to kick out idle channels out of the UMTS cell into some weird high-latency idle mode. This idle mode causes modems doing very low traffic to constantly getting thrown out of UMTS cell towers, with the need for them to then re-register. This idle mode causes an idle link latency of about 350ms, and a surge in packet loss and/or latency of up to 2500ms each time the channel starts to transmit significant amounts of bandwidth again – after that surge the behavior of the network turns back to normal. All of this can cause lots of troubles with achievable throughput and channel autotuning. We think that what Vodafone is doing here is a terrible idea and a standards violation, but we have to deal with it.
  The new “Save traffic when idle” option is enabled by default, which is identical to the behavior in previous firmware versions when this option didn't exist. If you disable the option, more idle ping traffic (about 10–15 KBit/s) will be generated, making sure the modem is not kicked out of the UMTS cell. However, you will burn more data traffic for this. We recommend disabling this option for the Vodafone UK network only.
  An alternative solution to the problem is to Disable Latency Autotuning for channels using Vodafone UK networks and inside the channel finetuning settings choose a “Optimal Latency below” value of 400ms, and a “Maximum allowed latency” value of 2500ms. This way the channel stays usable even if Vodafone UK enables the idle mode.
  Also 3G monitoring code can now detect this weird idle mode and will properly report it through monitoring tools as registration state “Normal / Idle”.

• If you have Streaming Optimizations licensed, there now is a new bandwidth autotuning mode available: “Rapid Autotuning”. This mode is optimized for 3G/4G links used in vehicles moving at high speeds, while using multiple different carriers at the same time. Rapid Autotuning is similar to Passive Autotuning as it does not generate any artificial test traffic; it is, however, far more aggressive. In a moving vehicle, cell tower changes will happen very often, as will short spikes of packet loss. With existing autotuning modes, these often would cause the channel to re-start testing at very low speeds. Rapid Autotuning instead aggressively re-establishes the previous bandwidth after a short spike of packet loss and/or a cell tower change. Compared to Hybrid and Passive Autotuning, the amount of throughput with Rapid Autotuning has doubled in our tests in high-speed vehicles. If you are using bonded 3G/4G in moving vehicles, you most definitely should start using this mode.
• The new LTE module “10-01036 LTE/UMTS/HSPA+/GPRS/EDGE (AUS)” for Australia is now fully supported.
• The performance of the new web interface for Hubs where a lot of log messages are scrolling through has been highly improved. It's now finally usable even on busy Hubs.
• For all password fields, there now is a “change password” dialogue, which also measures and displays password strength.
• LTE modules that get rejected from the network now behave much nicer. Instead of  constantly hammering the carriers' networks, they now exponentially back off in case of multiple connection failures.
• The APN database got updated. Now, there internally is also a dedicated APN database  for carriers that uses an APN on LTE that is different from the one on UMTS. Due to this, it is now possible to have APN Auto Configuration enabled for almost any carrier. Also, APN Auto Configuration from now on is by default turned on for all UMTS/LTE modules (before it had been turned off by default).
• Internal time-outs for packet flows have been reduced. This is especially the case for TCP connections through the tunnel that ended by both sides having done the FIN/ACK close. These changes should be invisible to customers, with one exception: During a DoS attack against a network connected by a Viprinet router, the system load will now be dramatically lower.
• When a tunnel was down, every packet arriving for this tunnel would generate a “Dropped packet from LAN as Tunnel is down” warning log message. This message has been removed.
• The “AT command tool” is now also available for CDMA450 modules.

• On 5XX Routers, viewing configuration objects that contained combo boxes (Drop-down selection lists) could result in an internal error.
• The module info could not be read from VDSL modules in the new web interface, only in the old one. It now works in both.
• If an Ethernet module had its “Expected Link Speed” setting not on automatic mode but manually configured, this could confuse the “Online” LED control of that module if you pulled out the Ethernet cable and plugged it back in again.
• Even if the registration on a network hadn't been completed yet, LTE modules would already try to establish a data connection to that network. This would cause log messages complaining that the data connection failed due to lack of service. The modules now won't try to establish a data connection before coverage exists and network registration has been completed.
• Since the current Stable Firmware release, the routers would automatically save the configuration after start-up. This was done so that automatically generated SSL/SSH private keys would get stored to disk. However, in rare cases, modules in the router would not have fully started up by the time the configuration was saved, causing the router to save a config with some modules missing. If you now at some point rebooted the router without ever before having changed something in the web interface (causing the config to be saved), you could lose your module config on the next boot. Now, whenever a module is inserted or removed into a router, the configuration automatically will be saved. Due to this, you will no longer lose your configuration in the case described above.
• The Hub Redundancy System in the latest Stable Firmware release contained forgotten debug log messages. These have now been removed. Also, the amount of logging for the Hub Redundancy System during times where everything is fine has been drastically reduced.
• Some recent versions of our CDMA450 modules would always start up in power-save mode, never waking up from that. With this firmware release, these modules are now woken up during initialization.
• In some cases, uploading files to the router (QoS configuration restore, manual firmware update) through HTTPS could fail with a “Bad Request” error.
• In the current Stable release, every request to the old web interface is delayed between 1–2 seconds, making things really slow. While we highly recommend to move to the new web interface, this “punishment” for using the old web interface surely wasn't intended and is now fixed.
• In a stacking setup, the log message “New effective physical link capacity to WAN (based on remote report)...” for remote interfaces (those located on a slave router) would cause internal errors on the stacking master. After 1000 of these internal errors, the stacking master would reboot. This is now fixed.

• The new web interface is now feature complete, and all known bugs are fixed. It is now also used as a default.
• HTTPS usage for web interface access is now highly encouraged.
• The encryption for the web interface has been highly improved. We are now using 2048-bit RSA key + SHA256 certificated, TLS 1.2 and perfect forward secrecy (Elliptic curve Diffie–Hellman). At SSLabs, Viprinet routers score with an “A” mark.
• The encryption for the VPN Tunnels has been updated accordingly. In addition, the VPN Routers will now take a fingerprint of the VPN Hub’s SSL certificate, and reject re-connecting to it in case the fingerprint changes. This is done in a way that the fingerprint will neither change when changing VPN Hub Redundancy settings nor if you move over the VPN Hub configuration to a new VPN Hub. The new system prevents a theoretical Man-in-the-Middle attack against our products, where an attacker would place a device in front of the VPN Hub, stealing the VPN Hubs IP and pretending to be that device.
• For multiple authentication failures on the SSH CLI, further login attempts from the same IP are now throttled. This makes brute force attacks on SSH unfeasible.
• Channel Bandwidth Autotuning by default will no longer generate log messages. This highly reduces the number of log lines generated on busy VPN Hubs with lots of Tunnels/Channels. Logging can be turned back on a per-channel basis.
• Channel and WAN bandwidth reports now are only logged every 10 seconds, and if the link speed of a WAN device is unknown, it is no longer reported instead of reporting “0/0”.
• Our new VDSL modules are now fully supported.

• We have fixed a potential VPN Tunnel protocol downgrade attack. In a man-in-the-middle-attack an attacker could force a VPN Router to fall back to an outdated Viprinet VPN Tunnel protocol version where the Tunnel password would be sent over in clear text over the SSL connection. This way the tunnel password could be stolen, and a rogue VPN Router operated by the attacker could be connected to the VPN Hub instead of the real one, gaining access to the VPN. We would like to thank Portcullis Security for their research and advisory on this issue. The old VPN Tunnel protocol versions are now disabled.
• Both inside the old and new web interface, input filtering wasn't done properly, enabling all kinds of cross-site-scripting attacks (XSS) for logged in users. All known attacks are now properly filtered.
• From this release, you can no longer create objects (Tunnels, Channels etc) that contain illegal characters. Existing objects will still load. Check your log files for critical warnings on this, and rename all objects with illegal special characters in them – in the next firmware release, these objects will no longer be loaded.
• Hybrid autotuning had a bug that could lead to MaxBandwidthToWAN being set to “0” and staying there.
• If multiple users with the same user name were logged in to the web interface (new or old one, doesn't matter), every user would only receive a part of the log messages.
• If Channel Bandwidth Autotuning was turned off for a connected channel and MaxBandwidthToWAN manually set to “0” (as it is sometimes done on the VPN Hub to not use the downstream of an expensive UMTS/LTE link, but only use it as an upstream booster), various weird effects could occur. If the channel had the lowest latency, best LinkStability or lowest Cost, QoS classes could select this channel as the preferred one to use while not being able to actually transfer any traffic through it. Due to this, these QoS classes would no longer transport any traffic. Channels that have zero bandwidth now are ignored by the QoS system.
• In a Node Stacking setup, sometimes on the Slave device a DHCP service would be running while it should not.

• Complete overhaul of the LTE module monitoring code. This firmware now for the first time fully supports our 10-01031 and 10-01032 modules designed for USA and Canada. It also is much better at analyzing used technologies, and will also report the current frequency/Band that is used.
• The Viprinet router startup code has been optimized. Starting a Viprinet Hub that has tons of Tunnels is now much quicker than before.
• The routers now have a maximum number of Tunnels that can be configured. 
  PLEASE NOTE: This doesn't mean the router will actually be able to serve this many tunnels at the same time at acceptable performance - this also depends on the number of Channels per tunnel and complexity of QoS rules.
  ​Here are the maximum number of tunnels per product:
  • 300: 25
  • 500: 25
  • 1600/1610/2610/1620/2620: 50
  • 1000/1020: 100
  • 2000/2020: 150
  • 5000/5010: 500
• Until now, the Hub redundancy system was exclusively using Ethernet broadcasts for the Hubs to communicate with each other. Due to a technical limitation in the used communication protocol, Hubs could only share configuration files if their compressed size has been below 64k. Sadly there was no way for the user to judge on how big the current configuration would be. If the compressed config was above 64k, the Hub Redundancy system would fail syncing configuration files. For some Hub 5010 installations with a high number of tunnels and QoS configs this limitation was hit in real life.
  In addition the broadcasting protocol had a design problem - with a lot of VPN Hubs operating at the same time, it was possible for multiple Hubs to send their configuration to the Hotspare at exactly the same time. In this case due to fragmentation this could result in no config being received by the Hotspare. This problem got worse if multiple Hotspares were running for a single redundancy group.
  We have improved the Hub redundancy system in that the main communication still runs over Broadcasts, but that for config transfers now a direct TCP connection to the Hotspare is established. Due to this, the size of Hub configs to be synched now is unlimited. The new protocol has been designed in a way that is downward-compatible. This means that Hotspare Hubs running the current cutting edge firmware can still serve production Hubs who run the stable firmware and don't yet are able to sync configs using TCP. We still recommend having all Hubs in a redundancy group using the same firmware release, though.
• Until now, Viprinet routers would sometimes mark traffic flows as unroutable if the tunnel was down while the flow got established. Since the last stable firmware release, this got even stricter: Any traffic flow that was established before the tunnel was up would be marked unroutable forever. This was not expected to be a problem - most sane protocols would abort and reconnect. This isn't the case for e.g. ISAKMP of IPSec, which is a brain dead protocol - it always uses UDP source and destination port 500 by convention. This makes it impossible to differentiate these ISAKMP flows, and obviously causes also huge problems with NAT gateways. In Viprinet, if an IPSec Gateway would establish an IPSec tunnel before the Viprinet tunnel was up (for example because the Viprinet router got rebooted, but the IPSec gateway didn't), this would cause the ISAKMP flow to be marked unroutable forever. This is because the IPSec Gateway would never "abort", and even if it would, a new IPSec setup would look like the old one - as UDP source and destination ports would never change.
  Due to this, if the IPSec Gateway didn't use sane timeouts, this could lead to IPsec tunnels through a Viprinet tunnel to get stuck forever.
  This didn't cause any problem with IPSec gateways we have tested internally because with these, if the ISAKMP handshake fails, they wait a couple of seconds before retrying. By then, in the Viprinet router the UDP port 500 flow will have timed out, and the new ISAKMP setup will be regarded as a new flow, which due to the Viprinet tunnel now being up is marked routable.
  As we have learned, that's not how all IPSec gateways behave - some are hammering without any back-off in case the ISAKMP handshake doesn't work. That's a stupid design, but it is what it is.
  We have changed the routing design inside the Viprinet router to cope with these kinds of problems, while still getting optimal performance.
  Traffic flows marked as invalid/unroutable will now be rechecked every 2 seconds if in the meantime it became possible to route them. This way we neither have high load caused by systems flooding the router with unroutable destination IPs (which would enable some form of DoS), nor do we have a problem with protocols that hammer with always the same flow while the Viprinet tunnel is not up yet.
  ​It is impossible to test with all available IPSec gateway combinations, but with those that we have tested IPSec tunnels now typically get (re-)established within a couple of seconds after the Viprinet VPN Tunnel has come (back) up.

• The previous cutting edge firmware release didn't work with 50-00500 project router series. This one does again.
• A bug was fixed which could in rare situations cause a tunnel channel to abort connecting to the VPN Hub with an SSL handshake error.