A year ago I had both a MikroTik hEX and a pfSense box on a small PC engines APU board, and I genuinely couldn't tell you which one I'd keep. A year later I can, and the answer surprised me, so I thought it was worth writing down before I forget the reasoning.
The short version: pfSense runs the gateway, and the MikroTik does everything clever behind it. I went in expecting to pick a winner and I ended up keeping both, each doing the thing it's actually good at.
what pfSense got right
The thing pfSense does that I undervalued at the start is that it's boring. The web UI is dense and a bit dated, but everything is where you expect it, the firewall rules read top to bottom like you'd hope, and the package ecosystem means I added pfBlockerNG and a couple of bits without leaving the box. When something goes wrong at three in the morning, boring is exactly what I want. I can reason about a pf ruleset. I can read the state table. I'm not fighting the tool to understand what it's doing.
It's also a real BSD box underneath, so when I need to drop to a shell and actually look, tcpdump, pfctl -s state, the lot, it's all there and it behaves the way I expect a Unix box to behave. That familiarity is worth a lot when you're debugging at the gateway, because the gateway is the one place where being wrong takes the whole house offline and someone starts asking why the telly doesn't work.
what MikroTik got right
MikroTik is the opposite kind of pleasure. RouterOS is a strange, dense, slightly intimidating thing, and once it clicks it's astonishing what a cheap box will do. The hEX is what, fifty quid? And it'll do VLANs, policy routing, proper queue trees, a remarkable amount of layer-3 work that you'd expect to pay an order of magnitude more for. The CLI is consistent in a way pfSense's isn't, everything is /interface, /ip, /routing, and once you learn the grammar you can do anything from one prompt.
Where it bit me is the learning curve and the footguns. The bridge and switch-chip behaviour changed meaningfully across RouterOS versions, and there's a real difference between traffic the switch chip handles in hardware and traffic that falls back to the CPU. Get a VLAN config subtly wrong and you'll find your "gigabit" router doing 200Mbps because everything's going through the CPU. The documentation is thorough but assumes you already understand the model, which is a chicken-and-egg problem the first few times.
/interface bridge vlan
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=10
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
That snippet is innocent-looking and I got it wrong twice before it did what I meant, because whether the bridge interface itself is tagged determines whether the CPU can even see that VLAN, and that's not obvious until you've broken it.
The other thing that bit me was assuming a config that worked on one RouterOS version would survive an upgrade unchanged. The bridge VLAN filtering model matured a lot over the releases I ran, and a setup I'd built early on, half switch-chip config, half bridge config, became a hybrid mess that technically worked but that I couldn't reason about anymore. I eventually tore it down and rebuilt it the modern way, all bridge VLAN filtering, and it's cleaner, but the rebuild was an evening I hadn't planned to spend. pfSense, for all its dated UI, has never once surprised me across an update like that.
the throughput question
People always ask which is faster, and it's the wrong question asked twice over. The MikroTik, when the switch chip is doing the work, will saturate gigabit without the CPU breaking a sweat, and it'll do it for fifty quid. The pfSense box on the APU board is CPU-bound and tops out lower, somewhere around 700–900Mbps depending on what packages are doing inspection. So on paper the MikroTik wins handily.
In practice it didn't matter for the gateway, because my WAN link is nowhere near gigabit and the firewall is never the bottleneck. The place throughput actually mattered was internal, VLAN to VLAN, where I do move large files around, and that's exactly the job I gave the MikroTik. So the throughput characteristics didn't pick a single winner, they reinforced the split I'd already fallen into: hardware-accelerated internal routing on the MikroTik, flexible-but-slower firewalling on pfSense at the edge where raw speed isn't the constraint.
the split that stuck
So here's where I landed, and why:
- pfSense is the gateway. WAN terminates there, NAT and the main firewall live there, and it does the job I want a gateway to do, which is be predictable and stay up.
- The MikroTik handles internal routing between VLANs, the inter-VLAN rules, and the queueing. It's faster at this for the money and the CLI makes bulk changes painless.
It's not the elegant single-box answer I set out to build. But each box is doing the thing it's genuinely best at, and after a year of uptime through both, that pragmatism has earned its place. If I had to collapse to one, I'd keep pfSense at the edge, because the edge is where boring and trustworthy beats clever, and lose some flexibility I'd grumble about but survive.
The real lesson is the one I keep relearning in every part of this hobby: the best tool depends entirely on the job, and "which is better" is almost always the wrong question. Which is better at the edge, and which is better for internal routing, have different answers, and a year of running both is what it took for me to actually believe that rather than just nod along to it.