We’re thrilled to unveil the latest Route10 firmware update—featuring two major new features that together redefine your network experience.
Add support for multi-WAN, including fast failover and load balancing. *See notes below
Add support for traditional WireGuard S2S VPNs.
Notes:
Control 1.0w (or later) is required to leverage these new features.
To enable load balancing, assign the same metric value to each WAN interface.
Multi-WAN is IPv4 only in our initial release; IPv6 support is on the roadmap for a future release.
IPv6 will continue to operate as it has in previous releases, independent of multi-WAN configuration.
This update is being rolled out now. You can manually initiate the upgrade if you’d like, or it will automatically update overnight (if auto-updates are enabled). The complete, up-to-date changelog is available here:
As always, if you have questions or encounter any issues, feel free to reply here or start a new topic. Please include details about the issue so we can assist you effectively.
Thanks Mike and Alta Team. Definitely an improvement. Keep up the good work. I will provide more detailed testing on the load balancing in the coming weeks. So far it is distributing the load between both ISPs.
I think this is causing some issues with my VPNs now, my wireguard client is trying to listen on the same port as my wireguard server so the client interface never comes up.
If I manually set network.<wginterface>.listen_port= to something other than 51820 it will then come up.
On the self hosted controller I cannot see anywhere to change the listen ports through the control UI.
Also I have multiple clients, all of which are trying to bind the same 51820 listen port.
Seems like another QA miss, unless I am just missing something , very frustrating.
We’ve just released 1.0w bringing on-premises Control in-line with the cloud service, exposing the updated options and adjusting provisioning.
If you are using an existing WireGuard server and client simultaneously, please note that after the update, you will need to manually verify there are no port conflicts or, if preferred, bind to the server’s port. Further changes are under discussion, but this reflects the current state as of writing.
EDIT: Fixed my statement about WG port handling with relation to the new changes.
To follow up on this, seems to be functional if anyone wants to mess around in the shell. Needs to have hardware acceleration turned off in order to function though (not terribly surprising there).
I have a 500Mbps down 20Mbps up connection and it definitely seems to handle that just fine, even with IPS enabled.
Here’s the commands I used to save anyone else some time if they want to play around
#eth3 being the WAN port
#egress
tc qdisc add dev eth3 root cake bandwidth 20mbit nat docsis ack-filter diffserv4
#ingress
ip link add name ifb4eth3 type ifb
tc qdisc add dev eth3 handle ffff: ingress
tc qdisc add dev ifb4eth3 root cake bandwidth 500mbit nat docsis ingress bes
teffort
ip link set ifb4eth3 up
tc filter add dev eth3 parent ffff: matchall action mirred egress redirect d
ev ifb4eth3
This isn’t a bufferbloat test, but doing some quick speedtests this morning with 2.5Gbps PHY only, Route10 handling PPPoE, with Cake enabled, and I get the throughput below. I’m testing just by setting rates in Control, using a pre-release version. IPS/IDS not currently enabled, although I’ll check there too. I intend to switch over to SFP+ PHY for both later to push my WAN, but it’s only 3Gbps symmetrical. Thought it may be interesting to see raw throughput in my early testing…
Sorry, apparently I was living in my own little world for a bit there. Yes, it determines the type of connection tracking monitor—whether ping or HTTP/HTTPS. The latter is particularly useful in environments where ICMP is filtered, and in the case of HTTPS, it verifies that a secure handshake can be completed, not just that packets reach the host.
It’s surprising how many people configure their gear to drop ICMP along the network path, especially considering that many devices rely on PMTUD, which depends partly on ICMP. Ultimately, dropping ICMP doesn’t obscure anything—it only breaks modern network features that depend on it
, very frustrating.
