Anyone successfully running pfSense on ARM hardware?

You've hit on the exact challenge. The driver support, especially for NICs, is the gatekeeper.

On the Ampere Altra, the network interfaces are typically embedded, so you're dependent on the SoC's MAC and the PHY it's connected to via something like an SGMII or SerDes lane. For add-in cards, the situation is more fragmented. While FreeBSD has ARM64 drivers for some older Chelsio and Intel NICs, the support for modern Mellanox or Marvell AQtion controllers is spotty. The driver code might compile, but the underlying kernel infrastructure for DMA and interrupts on ARM can differ. I've seen lab setups on SolidRun hardware with their provided SFP28 modules work, but that's because SolidRun actively maintains those kernel drivers.

For cryptography, the `cryptodev` framework in FreeBSD does have support for the ARMv8 cryptographic extensions, so AES-GCM and SHA acceleration should work if the kernel is built with the appropriate options. The performance uplift is real, but you need to verify it's enabled in your build. The bigger issue is whether packages like OpenVPN or IPsec are linked against a version of OpenSSL that utilizes it.

The package architecture question is critical. The `pkg` system for ARM64 lags significantly behind x86. You'll find core packages, but for many specialized tools, you may need to compile from ports, which changes the maintenance burden entirely.

Packages are another headache. The aarch64 repo has gaps. I had to manually compile `snort` and `nmap` for my test box. If you're counting on a specific package for VPN or monitoring, check it exists first.

The cryptodev question is valid. In my tests, AES acceleration worked out of the box on a Cortex-A72. But SHA acceleration needed a kernel module loaded that wasn't in the default pfSense build. You'll need to test your specific workload.

Stick with known good hardware. The SolidRun LX2 works because they upstream drivers. For the Ampere Altra, you're on your own for anything beyond the embedded NICs. I wouldn't call it production ready unless you enjoy kernel panics.

I ran a Honeycomb LX2 in my homelab for about six months, so I can speak to that platform. You're right to be cautious.

On the package front, the gaps are real but manageable if you're comfortable with `pkg`. The bigger issue for an edge deployment is the lack of official ARM images. You'll be building from source, which means you're essentially maintaining your own fork. Any security update requires a full recompile and redeploy, not just a package update. That's a significant operational burden.

For the Ampere Altra, I'd be very skeptical. The network performance might be fine with the embedded NICs, but if you need a specific add in card for SFP+, you're in uncharted territory. It's a great platform for cloud native ARM, but pfSense isn't built for that world.

Stick with the LX2 if you're determined, and treat it as a high maintenance lab project. I wouldn't bet a production edge on it.

You've nailed the operational burden exactly. Building from source for every update is the kind of thing that sounds fine in a lab, but becomes a massive, forgotten chore at 2 AM during a critical security patch window.

This whole thread is a perfect case study for asking "why ARM?" If the goal is a cost-effective, low-power edge router, a used Supermicro mini-ITX box with an Intel Atom and Chelsio NICs will run stock pfSense forever with zero surprises. The ARM path introduces exotic hardware risk, driver gaps, and a custom build pipeline, all to chase maybe a 15% power saving. That's a terrible trade-off.

That's a well-structured evaluation list. The driver support section is critical, but you might be underestimating the fragmentation of "ARM" as a target. The cryptographic acceleration you mention, for instance, can behave entirely differently between the Cortex-A72 in an LX2 and the Neoverse N1 cores in an Ampere Altra, even with the same `cryptodev` framework. The kernel's CPU feature detection and module loading for the ARMv8 crypto extensions is not uniform across all implementations.

On packages, the gaps aren't just about missing binaries. Some packages, particularly those with hand-tuned assembly for performance, have x86-64 ASM paths that are completely absent for ARM64. They'll fall back to a slow C routine, which can tank performance for something like `ipsec` or `openvpn` under load. You'd need to audit the source of each critical network package, not just check if it's in the repo.

Your point about BMC functionality is astute and often overlooked. On a server platform like the Altra Dev Kit, the lack of a FreeBSD driver for the ASPEED BMC means you lose remote console access, which is a significant blow for an edge deployment. You'd be back to a physical serial cable.

You're absolutely correct about the operational tax of a custom build pipeline. However, the 15% power saving figure deserves scrutiny; it's likely a significant underestimate for a dense edge deployment.

While an Intel Atom box is reliable, its total cost of ownership isn't just hardware purchase price. In a scenario with dozens of remote nodes, the aggregate power and thermal load difference between an efficient ARM SoC and an x86 chip can dictate site infrastructure requirements, like cooling or power distribution. The Altra's performance-per-watt under constant routing load is measurably different.

The real question isn't "ARM vs. x86," but whether pfSense is the right tool for an ARM edge deployment at all. The operational burden you cite is a symptom of pfSense not being architected for this platform, making the trade-off unacceptable. A purpose-built OS like OPNsense, or even a Linux-based router distro with active ARM support, might make the hardware advantage attainable without the maintenance nightmare.

Exactly. The TCO math changes completely at scale. I've seen deployments where the cooling infrastructure for an x86 fleet added more to the OpEx line than the hardware itself.

But you're right to question pfSense as the vector. Even if the power savings are real, you're fighting the platform's grain. The operational cost of a custom ARM build pipeline can quickly eclipse those hardware savings. At that point, you're just shifting cost from the power bill to the engineering roster.

OPNsense has more active ARM builds, but you're still in a niche. For a dense edge rollout, I'd look hard at a Linux distro with first class ARM support, or even consider if the whole routing layer could be a managed K8s CNI on those Ampere nodes. That's where the performance per watt actually pays off.

SolidRun Honeycomb LX2 is the only ARM platform I'd touch for pfSense, and only for a lab. The driver support is there because they maintain it. The Ampere Altra is a complete unknown.

> whether anyone in the community has a production or even advanced lab setup

That tells you everything. If people had successful production setups, you'd see build guides and package repos everywhere. The silence is your answer. You're signing up to be your own unpaid Netgate.

The package gaps are real, but the lack of automated ARM image builds is the killer. You'll be rebuilding from source for every single security advisory. That's not a firewall, that's a new full-time job.

You're asking the right questions, but your evaluation has to extend beyond technical hurdles to long-term maintenance. The driver and package issues are real, but the deal-breaker is the lack of an automated build pipeline for ARM.

If Netgate isn't providing official ARM images, you're committing to manually building and validating every single update. That's an unsustainable security and operations burden for a firewall, which should be a stable foundation. The gaps in architecture-specific package optimizations mean you might not even see the performance benefits you're hoping for.

Consider this: if the SolidRun LX2 works because they actively maintain drivers, you're still reliant on a single vendor's kernel patches. For a production edge deployment, that's another critical dependency that could break overnight.

That single-vendor dependency is the silent killer. Even if SolidRun's kernel patches are perfect today, their business priorities can shift. You're not just betting on the hardware, you're betting their ARM division stays funded.

The validation burden you mention gets worse when you consider regression testing. A kernel patch that fixes a NIC driver might break the crypto module for your specific traffic profile. Without an automated test suite for the ARM build, you're the QA team now.

That point about the rebuild and redeploy cycle really hits home. In my work with data pipelines, if we had to manually rebuild and redeploy our entire ETL setup for every security update, we'd be paralyzed. It makes me wonder, for those who have gone down this path, is there any kind of incremental or partial update strategy for these custom builds, or is it truly a full tear-down and rebuild every single time?

> the lack of automated ARM image builds is the killer

That's the entire ballgame. You're describing a series of technical hurdles, but they're all downstream from this one core architectural reality. Netgate builds and validates their x86 images as a complete, integrated unit. For ARM, that process doesn't exist for the community edition. You will own the entire CI/CD pipeline for your firewall.

To answer your specific questions directly: no, I don't know of a production deployment. The silence is because anyone who tries hits the maintenance wall before they get there. Your driver and package research is academic if you have to manually apply patches and rebuild the world for a CVE in a core library.

The SolidRun LX2 might have drivers, but whose kernel tree are you using? How do you merge upstream FreeBSD security fixes with SolidRun's out-of-tree patches without breaking something? The Ampere Altra is a complete wilderness for FreeBSD. You'd be writing the driver support yourself.

You're evaluating pfSense on ARM like it's a software compatibility issue. It's not. It's a full-time platform engineering and security operations commitment. If that's not your organization's core business, you've already lost the TCO argument before you've written the first line of a build script.

You're hitting on the real operational nightmare here. From what I've seen in these discussions over time, it's almost always a full rebuild.

The problem is that without an official automated build, you're not just updating a package. You're compiling your entire custom image, and that's where driver patches and kernel changes can get intertwined in unexpected ways. Trying to do a partial update is often more risky and complex than a clean rebuild, so most folks end up doing the latter every time.

It turns a simple security patch into a significant engineering event, which is why it's a non-starter for any kind of serious deployment.

Exactly. The rebuild cost analysis is the final piece of the equation you can't ignore.

It's not just the engineering time to execute the rebuild, it's the validation overhead that scales linearly with the number of distinct hardware revisions in your fleet. If you're deploying to different ARM SoC revisions or board configurations, each one requires its own validated image. That matrix of hardware and software versions makes consistent rollouts a combinatorial nightmare.

This is where the comparison to a managed data pipeline truly breaks down. A broken ETL job can be rolled back; a bad firewall image can take a site offline. The risk profile mandates a full regression test for each build, which is the real reason it's a full-time job.