Any advantage to TNSR on slow WAN connections? (e.g. 100 Mbps)
-
If you have a slower WAN connection (e.g. 100Mbps) is there any advantage at all to TNSR over pfSense?
Most of the marketing material seems to be spruiking the awesome packet-processing capabilities, which I'm sure are great - just now sure if that will help if our uplink is the bottleneck.
And do we know if a Web GUI for TNSR is on the roadmap?
(The API for integration with things like SaltStack or Ansible seems like it could be neat, as we have quite a few boxes to manage, but trying to figure out if it's worth switching yet).
-
Hi @victorhooi,
I think I just replied to you on Reddit as well.
Advantage to TNSR in 100Mbps scenario.
The first thing that comes to mind is programmability. If you're using this in a home lab, that might not be a big deal, but in a DevOps or distributed environment, TNSR's API will help you automate. As you said, SaltStack, Ansible, and other frameworks are great ways to wrap policy or updates into code.
...no Web GUI at the moment.
That's true, but the reason we started with an API is so TNSR can be easily extended. That could mean a GUI in the future, but for right now we've worked with partners who use TNSR via the API to extend their own products. For example, Fidelis Networks uses TNSR to mirror traffic for inspection in AWS.
Will packages such as nTopNG be available for TNSR?
I don't know if that package specifically will be available, but extensibility was central to the design of TNSR. Here's an example of how TNSR can work with Snort: https://github.com/Netgate/TNSR_IDS
You can probably see how this architecture would be really beneficial once bandwidth exceeds a couple of Gbps. With TNSR+Snort, routing and traffic inspection won't end up competing for CPU resources so you can scale them independently.
If nothing else, grab a TNSR trial and run it your lab environment.
