This Cutting Edge Firmware brings a couple of big improvements in regards of LTE modules in Europe and North America, the Hub Redundancy System, and for users of IPSec gateways setting up IPSec tunnels through Viprinet VPN Tunnels.
This release is fully compatible with the Stable Firmware released on August 12th. It is therefore OK to run the Cutting Edge Firmware on Routers, while the Hubs are running the Stable release. The improvements on IPSec and Hub Redundancy however require the Hub to also run the Cutting Edge release. If you are using this cutting edge release on a VPN Hubs, it is recommended that you update all VPN Hubs that are part of the same redundancy group.
Important notes for users upgrading from a Stable Firmware Release
Compared to the current stable firmware, this cutting edge release also includes all the changes of the September 14th, 2013 cutting edge release. If you are ugprading from a stable firmware to this release instead of the previous cutting edge firmware release, please also consult the releases notes of the September 14th, 2013 cutting edge release. The most important change compared to the last stable release is:
Viprinet now supports access control lists. Using this you can define which IPs and subnets from LAN or WAN/VPN may access services. Upon firmware upgrade, a set of default rules will be created. These are designed in a way not to interfere with existing installations, and it is recommended to tighten them.
For example AdminDesk access currently is allowed both on HTTP and HTTPS from everywhere, while we recommend only allowing HTTPS from the Internet.
Due to the new ACLs the AdminDesk SSL certificate settings have moved from "[ AdminDesk ] LAN settings" to "[ AdminDesk ] Integrated services". Should you have installed your own custom SSL certificate, you will have to re-install it after firmware upgrade.
All SNMP settings also got moved to "[ AdminDesk ] Integrated services". After firmware upgrade, you will have to re-configure SNMP.
List of changes compared to the previous Cutting Edge Firmware Release
- 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.
