Improvements
- Highly improved channel bandwidth autotuning. You will now get much better results for all kinds of lines, especially Sat links. Hybrid autotuning will now get much better results on its initial tests on VPN Tunnels that are idle. Congestion on the channel will much less drastically slash down Max Bandwidth To WAN, which means you will see better performance on WAN links that have surges of packet loss.
- VLANs on Nodes are now supported in the following way:
- In the LAN settings, there is now a "Allow route-back" option. If enabled, traffic coming in from a VLAN can be routed back to the same or a different VLAN – in other words, VLAN segments may talk to each other. If disabled, traffic coming in from the LAN with a destination on the LAN instead will be dropped, so the VLANs are completely separated in this case and all may only talk to the VPN Tunnel.
- On the Node, you have the option “Allow all VLANs to talk to tunnel”. If that is enabled, all VLANs can talk to the tunnel; if disabled, only VLAN0 can.
- In the WAN/VPN Routing settings on the Hub, you also have an “allow route-back” option. If disabled, traffic coming in from the Tunnel which would go back to the same tunnel (see above) again will be dropped.
Using these features, you can implement both a Node which has a local VLAN that is not allowed to talk to the VPN but to the remaining LAN, and you can also have a setup where you have multiple VLANs that really should be separated from each other but be able to speak to the VPN (for example, both a corporate network and a public visitor WLAN).
Please note that VLAN tags are NOT transported through the tunnel. On the Hub side, all traffic still will come out of a single tunnel with a single Tunnel Segmentation ID. If you need to deal with the networks routed separately, you need to create a VLAN on the Hub and route all traffic from the tunnel to a next-hop in this VLAN, where you separate the traffic according to their source IPs into different multiple VLANs again.
- All Routers and Hubs now have an integrated HTTP test traffic generator which can be enabled at [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads
If enabled, HTTP test downloads can be done from this router without requiring any sort of authentication. This should only be enabled while you are running tests yourself and turned off for production systems.
If enabled, a stream of random data can be downloaded from this router using the following URL:
http://[your router IP]/exec?module=download&speed=Speed&size=Size
Speed is in Bits per Second, 1K means 1 Kbit/s, 1M means 1 MBit/s, 1G means 1 Gbit/s. The speed parameter is optional. If this parameter is not given, the maximum possible link speed will be used. The maximum allowed value is 1G.
Size is the Size to download in Bytes, 1K means 1 KByte, 1M means 1 MByte, 1G means 1 GByte. The size parameter is optional, if not given, 16 GByte is assumed, which is also the maximum allowed value.
- Viprinet routers now contain a security feature to protect against the most common form of the DNS amplification attack – a single IP now is only allowed to do 2 ANY requests within 60 seconds. We still recommend implementing more advanced DNS Amp attack protections in your core firewall.
- The download test tool available in the LAN settings and module settings has been extended and improved a lot. It can now download test files from a world-wide content delivery network provided by Viprinet, which will automatically chose the Edge server nearest to you, or – if the Hub is using the Cutting Edge firmware – download from the Hub traffic generator. You now therefore have a tool which you can easily use to test for connectivity and throughput problems with WAN interfaces, and can easily check where your bandwidth bottleneck is. Use it!
- In the channel fine tuning settings, you can now define a minimum Link stability a channel is expected to have, with a warning getting sent to the log system in case the link stability goes lower than this value. For non-moving installations, a non-broken link should have more than 90% of stability, for moving vehicles it depends on the typical coverage. Using this setting, you can make it easier to automatically get notified of link problems (for example, a SIM card running into the traffic limit).
- The monitoring API used by the Viprinet Monitoring tool caused quite a lot of CPU load on the monitored router. That load has been decreased.
- In the past, the configuration system (both web interface and CLI) would use a global lock which could lock up the routing core for several seconds – for example, while you were applying LAN settings, the router would not route packets. This global lock now has been removed, and working in the web interface should no longer have drastic effects on the routing performance of Viprinet routers.
Bug fixes
- A high number of SNMP bugs has been fixed. Most importantly, Hot spare Hubs that take over / replace a Hub now will correctly report normal full Viprinet SNMP on the IPs taken over, and give Hotspare SNMP replies on the Hotspare IP.
- SNMP no longer will change OIDs of other Tunnels if a Tunnel got deleted.
- SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature are now implemented.
- Due to a race condition, Node Stacking would sometimes crash in failover situations. Also, the “Failed to open slot for stacking” bug is fixed, as is the internal error 23239482394811Aa.
- Turning off configured stacking would result in the wrong error message “[Stacking] This router does not have the stacking featured licensed. Can not start stacking!”
- A Node Stacking slave would not stop the internal DHCP server in some cases. This would cause two DHCPs to run on the LAN, which caused problems.
- The firmware online updater always required you to click “check for updates now” TWICE to get an actual result. Now the first click works.
- ADSL modules sometimes have problems to get the module info read. We have increased the timeout for waiting for the modems diagnostics report reply. Please report to Viprinet in case you still get error messages trying to read module info from an ADSL module.
- Everything related to “Ethernet speed and auto-negotiation settings” has been reworked. There had been bugs that turning off auto-negotiation didn't work for some products and some Ethernet modules, bugs that turned off auto-negotiation was ignored on next router reboot, and tons of more bugs. All of these have been fixed, and we have validated that manually setting Ethernet parameters now works with all products and modules, also across reboots.
- The “Reconnect” function of Fast/Gigabit Ethernet modules no longer causes a PHY Reset / Ethernet Autonegotiation to restart. If you want that, reset the module instead.
- Using VLANs and an MTU of 1500 didn't work with Fast Ethernet Modules (but it did with Gigabit Ethernet modules). It now works with both.
- In reality, the routing core often would send more average bandwidth on a Channel than the Maximum Allowed Bandwidth to WAN would allow due to rounding errors. On some link types, this resulted in the link getting overloaded and the latency going up despite of perfectly correct autotuning results. These rounding errors have been fixed.
- In the current stable firmware release, changing anything about LAN settings including LAN Aliases will become effective even before you hit “Apply Settings”. This could also cause unclean state if you were in the middle of creating a LAN Alias.
- If “Allow remote service connections” was turned on, then turned off, remote service connections actually still were possible until your rebooted the router. Turning this off now will have immediate effect as expected.
- The download test tool very often would abort “due to high CPU load”, even if the CPU load wasn't that high.