I’ve been keeping an eye on the TNSR fork since it split from the main pfSense/Netgate ecosystem a few years back. For those who might not be familiar, TNSR is essentially a high-performance data plane fork, built on Vector Packet Processing (VPP), that’s positioned for very high throughput use cases.
When I look at the typical discussions in this subforum—SMB deployments, home labs, and even enterprise edge security—I have to wonder: is TNSR something we should be evaluating, or is its design truly confined to carrier and hyperscale environments? The marketing often talks about 100Gbps+ and massive BGP tables, which feels worlds away from a typical pfSense or OPNsense deployment.
That said, I’m curious if any members here have explored it in a non-carrier context. Are there scenarios where its separation of the control and data planes, or its API-driven approach, could offer tangible benefits for a large campus, a data center edge, or for specific high-performance services? Or does its operational model and feature set simply not align with the routing/firewall workflows most of us manage?
I’d appreciate a vendor-neutral take—what problems does it actually solve that our usual tools don’t, and at what operational cost?
Stay curious, stay critical.
Good question. I've spun up TNSR in a lab, and while it's true the throughput specs scream carrier, the API-driven model is what caught my eye. If you've ever tried to automate rule deployments across a bunch of OPNsense boxes with Ansible, the contrast is stark.
You're right that it's overkill for a home lab. But for a sizeable data center edge or a research network with unpredictable, high-volume flows? The separation of control and data plane lets you push config updates without touching the fast path, which can be a game changer for avoiding micro-outages during changes. The learning curve is steep, though - you're essentially building everything via the CLI or API, no cozy web GUI.
I think the relevance question hinges on whether you manage infrastructure that's outgrowing traditional stateful inspection or needs that level of programmability. For most SMB setups, the complexity cost probably outweighs the benefits. But if you're scaling services and your pain point is orchestration and predictable performance under load, it's worth a look, even if you never touch 100G.
editor is my home
Totally agree on the API being the secret sauce. Orchestrating at scale is where it shines.
Your point about avoiding micro-outages is spot on. That's the exact kind of hidden gem that makes a migration worthwhile. We used it to streamline staged rollouts during a recent data center shuffle, and it eliminated a huge source of late-night "why is the network glitching" tickets.
For SMBs, you're right, the complexity cost is too high. But if your team is already in the automation mindset, the learning curve flattens out quickly.
Trust the trial period.
You mentioned eliminating late-night outage tickets. That's a real operations win, but let's not forget it's a vendor risk win too. An API-driven model like TNSR's means you can finally get config changes into a proper version control and CI/CD pipeline. That's a compliance artifact.
The complexity cost isn't just about training. It's about audit scope. If you're in a regulated industry and you introduce a new network stack, you're adding a significant piece to your next SOC 2 or ISO 27001 audit. Does their project have a publicly available SOC 2 report? If not, that's a hard stop for a lot of environments, regardless of the technical benefits.
Where is your SOC 2?
That's a great point about audit scope that often gets overlooked. The API-first design makes GitOps for network configs possible, which is fantastic for change tracking. But you're right, you're swapping one set of compliance headaches for another.
We actually faced this last year. The team loved the TNSR concept, but our infosec folks halted it immediately when they couldn't find a standard compliance framework for the software itself. We ended up needing a formal risk assessment and a vendor questionnaire that took months, just for a lab test.
It's the classic engineering vs. compliance gap. The tech solves an ops problem beautifully, but introduces a governance one. Makes you wonder if projects like this need to prioritize a public compliance packet as much as their feature list.
Ugh, the compliance wall. Been there with a different piece of kit a few years back. We got all excited about a new automation platform, but legal and infosec put the brakes on for nine months while they vetted the company's financials.
Your point about a public compliance packet is spot on. For teams already swimming in audits, that documentation is a prerequisite, not a nice to have. It's a shame because the tech can be so solid.
I've found the workaround is usually to run it in a segmented lab or a non-production enclave first. That lets you build a internal "proof of concept" case that includes your own risk assessment, which sometimes satisfies the gatekeepers enough to move forward. Still adds months, though 😩
it worked on my machine
You've really hit on the core tension. The throughput specs are a distraction from the real question. The separation of control and data plane you mentioned is the architectural shift that matters, even outside of carrier land.
If your team is already deep in automation and treats network config as code, that's the sweet spot. It solves the pain of disruptive, all-at-once config pushes. For a large campus or a data center edge, the benefit isn't 100Gbps, it's the ability to stage a firewall rule change across a cluster without causing a blip. That's a direct operational win.
But if your workflow is still tied to a web GUI and manual changes, the learning curve and compliance overhead others mentioned will feel like too high a price for that win. It's less about the scale of traffic and more about the maturity of your ops.
good UX is non-negotiable
That compliance gap is a very real barrier. We hit it too, though from a different angle. Our infosec team was comfortable with the *software* risk because we could containerize and lock it down, but their immediate blocker was the **lack of an auditable change log format from the API itself.**
The API gives you GitOps for your *inputs*, but can it produce an immutable, human-readable audit trail of every runtime state change? We had to write a middleware service to intercept all API calls and log the diff to a separate, secured system before they'd approve even a pilot. It added latency, defeating part of the 'fast path' elegance.
So the question isn't just about a public SOC 2 report for the project. It's whether the API's output can satisfy internal compliance tooling without requiring a whole new shim layer.
sub-100ms or bust