Any day now is good, looking forward to it. As for keeping with the facts, I feel it was clearly demonstrated by @DN3092 and @ebuckland81 that the IPS capability is not working. Threats were passed by the Route10 to the endpoint (as evidenced by Bitdefender detecting it at the end-point) and where the conntrack -D call failing due to the queue being saturated. These are the facts.
My last post was deleted - let me try one more time.
Any day now is good, looking forward to it. As for keeping with the facts, it has been clearly outlined by @DN3092 and @ebuckland81 that the current IPS does not, in fact, work at least not reliably. As @DN3092 has shown, end points are receiving the threat (as evidenced by Bitdefender detecting it on the end point). As @ebuckland81 has shown, conntract -D does not reliably delete the session (as evidenced by the log files showing failure of conntract and saturated queue). These are the facts.
It wasnât actually flagged by any humans, just our spam bot, so I removed the flag.
Hi Alta Members! Been looking at Alta Route10 device and thinking of obtaining one for testing purpose. Which is on hold for now, as from my understanding IPS is not blocking all hits.
Does it mean, that IPS up to this day is still allowing traffic to pass even though it is detected?
The initial/first connection attempt / traffic may sneek through, from my testing and understanding, as the IPS application is reacting to the event that Suricata/IDS detected, rather than filtering the event inline. Please feel free to correct me there.
Then, after some short time, the IPS application should be able to delete the connection. For how long this initial/first traffic may go on I am not sure of.
Also, worth noting, one of the later firmware upgrades introduced a configurable block duration for which any further traffic is temporarily blocked between the two IPs involved. ![]()
![]()
Well after a couple weeks im convinced that there has been no improvement to IDS/IPS on this product unfortunately.
I took a chance and got a ucg fiber, and not a single threat touched the device requiring bitdefender to stop the threat.
Meanwhile on the route10
âNo improvementâ is certainly a stretch as you yourself confirmed that the number of threats went down immediately after enabling the Block Duration option.
As we and @ebuckland81 noted, the first threat detection cannot be blocked due to the current passive architecture of our IDS/IPS, but subsequent attempts that match the IP address pair will be blocked, as you have confirmed this yourself.
We may consider adding support for inline operation which should be able to block even the first attempt, but it severely limits the amount of throughput that can be handled by the device (and this is the case with any vendor that performs inline operation - it depends solely on CPU processing power and bypasses any advantageous hardware acceleration).
Is there a way to do that now manually? I only have 500down and 20 up so i donât need super fast speeds.
Perhaps, but it requires modifying core iptables/firewall rules, and the suricata config, as outlined here: 23.2. Setting up IPS/inline for Linux â Suricata 9.0.0-dev documentation
This right here is my issue, I personally donât want to sacrifice security for speed.
Sure, weâre definitely looking into it.
WowâŚ.just wowâŚ
@DN3092 this is great feedback after giving it some time to see how it performs. Iâm a little put off by the reaction it has received which is unfortunate.
Our team works incredibly hard to improve the product directly based on feedback given here, so I hope you can understand the frustration when we receive mixed messages. We are already looking into adding a fully inline option even though the Blocking Duration option has been proven to block credible threats after the first attempt, but once again, your patience will be appreciated.
Yeah, not too much to add aside from being generally fine with the current tradeoff myself, but I think a combination of the ability to switch between the current mode and an inline mode plus documentation and tooltips stating the expected behavior and tradeoffs between the modes would probably nip most of this in the bud ![]()
Noting that the IDS/IPS solution used is passive and not inline should be noted in their documentation imo. I bought the product expecting inline, which unfortunately isnât the case.
I completely understand the frstration around receiving mixed messages. I work incredibly hard for my money and when I buy a router that states it has an Intrusion Protect System only to then be told, well, it doesnât really block everything, but we fixed it, well, it still doesnât actually block the initial attack, yea, I get the frustration around mixed messaging very well. I donât know that there is any patience left at this point.
Weâre going to keep asking for it, nonetheless! While the current implementation may not meet your specific needs, it definitely meets othersâ. Weâll keep working towards meeting your needs, as well.
@DN3092 @ebuckland81 @jmszuch @ecs-solutions
Sorry to spam you all, but was hoping you could revisit your testing after the recent 1.4t update. Time permitting of course. Thanks!
Iâm no longer using Alta equipment.
Weâve listened to everyoneâs feedback here specifically and delivered inline IPS, as promised.
PBR (IP, subnet, and domain-based) is coming along quickly, as well. Weâre committed to improving Route10 with free updates.



