Route10 Firmware 1.4p Released!

This release enhances Route10’s performance and security foundations, helping networks operate more efficiently while reducing the risk of unintended traffic behavior.

  • Add “vlan” acceleration method for enabling hardware acceleration on many VLANs.
  • Add support for blocking based on IP lists, including specific countries and against malicious IP databases.
  • Update IDS Suricata to version 8.0.2.

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:

If you have questions, feedback, or run into any issues, feel free to reply here or start a new topic. Including configuration details or relevant logs where possible helps us troubleshoot and respond more quickly.

5 Likes

Just as a little “would be nice” feature would be being able to “Block all except” for countries and malicious databases, that way we wouldn’t have to select everything we want to block, only select what we want to allow (for example only US traffic) or blocking all of the malicious databases without having to select each one.

For the record, update seemed to go great, no issues with that! Thanks again for the continued support.

3 Likes

Any chance you could share the IP databases you use for Block regions and Block lists, and the process to check against said database and the process to get something recategorized?

Had an outage after the update today.

Route10 was always connected to the cloud controller and could view and manage via the app. however no internal network traffic was able to access the internet.

After +3 reboots the route10 finally provided internet connectivity again.

I made no changes other than using the android app to click the update now button.

I have DoH disabled if that is an issue.

Any ideas - not the first time Ive had to a second reboot after an upgrade, but multiple is not normal.

1 Like

…1.4p Released on 01/12/2025 Add “vlan” acceleration method….

The year of 1.4p release date is incorrect, it is still 2025

1 Like

Following the auto update, several of my WiFi IoT devices stopped being able to reach the internet until I manually rebooted the router via the app portal. Devices were google speakers, wiz lights, and smart plugs.

As feedback, I think it would be helpful if the controller’s app was more explicit about recent updates applied, as it would have saved me some time debugging.

We cannot reproduce anything like this in our testing, but if you can enable Persistent Logging, then reboot the device a few times, and mark the timestamps of when/if the device is not providing Internet properly, then share the logs with us, we can take a look.

Mixed feelings now :joy: I might just have scrap my own custom bogon, abuse and geo block tool. Great :smiley:

Edit: Linking backwards to a few topics that addressed or touched this, of whom some are now locked:

1 Like

Any chance you could share the IP databases you use for Block regions and Block lists, and the process to check against said database and the process to get something recategorized?

The geolocation is from db-ip, which is a highly accurate and frequently updated source so I don’t expect there will be many issues there. Likely only when IP space moves, which tends to be updated quickly by the IP space owner in all the major geolocation databases, often before it’s in use in the new location. Any geolocation updates can be reported upstream to db-ip.com, or reported to us and we’ll report to them.

The bad actors list is where we consolidate and de-duplicate multiple quality, actively maintained block lists of clearly malicious actors. One of the reasons we’re doing it the way we are is so we can modify those databases if/as needed, and can remove lists which become unmaintained or poorly maintained, and add new ones if other trustworthy sources of data become available. If we notice one of those having true false positives too often, we’ll remove the list. If there are one-off true false positives we could remove them. But all the lists we’re using automatically drop off IPs that are no longer attacking things and aren’t part of an extremely bad neighborhood on the internet (abuse-friendly datacenters, known cyber-crime operations, etc.). Like Spamhaus DROP list is one of them, for example, which is only prefixes used by the absolute worst of spammers, malware, botnet command and control, etc. If you notice any false positives there, please let us know.

The other lists come straight from their sources (though we host a copy of them, which is what Route10 pulls from, so we can modify if needed). Like if something is listed in the FireHOL lists, the source it comes from has to be updated (they’re also consolidating multiple list sources).

You can check and see whether an IP is listed in any of your currently loaded block lists by running the following on Route10.

/etc/init.d/banip query x.x.x.x

It’s also possible to exempt IPs/networks via uci commands to banip, and we’ll add a UI field for that if demand materializes.

5 Likes

For geolocation, yes that would be nice to have. At a minimum maybe we could add continents so you only have to pick a smaller number of entries. Allowing only specific countries is more complicated but we could hide that complexity on the back end.

We’ve consolidated and de-duplicated most of the malicious IP/network databases into the one “bad actors” list which has the highest quality sources, for exactly the reason you describe - we didn’t want people to have to pick 8-10 different lists of bad actors and consider which ones are appropriate, and then keep that list up to date as new lists are created and old ones become deprecated or poorly maintained. We’ll do that for you. The remainder are possibly more false positive prone, or are policy violations rather than malicious IPs/networks (like the DoH lists).

3 Likes

Thank you for the explanation. Keep up the great work!

3 Likes

Just wanted to chime in and say that so far, no issues upgrading to this firmware on any sites on my end :slight_smile:

@Alta-MikeD would it be possible to have some more information on the VLAN hardware acceleration? I see from the most recent Control release notes it seems it’s recommended mainly for sites with five or more VLANs. Is there a potential drawback for sites with fewer VLANs? Thanks!

Love to see more blocking functionality added, as I feel the Route10’s firewall is currently its weakest point. I believe it is still very lacking due to no aliasing/grouping options for ports or IP addresses. What could be 2-3 firewall rules for me is several pages due to individual port and IP limitations.

3 Likes

This looks similar to the block list scripts that I’ve been running on the route10. Very nice! A couple of questions:

Any reason not to support different block sets for incoming and outgoing? Some of the firehol lists are more appropriate for one or the other.

How often do you update the lists?

1 Like

Figured I’d post this here in case anyone else was curious. Here’s a quick overview of some of the improvements going from Suricata 7 to 8 (since I believe that’s what happened with this firmware release):

2 Likes