For a while I’ve been using OPNsense for my custom router. I recently decided, though, to migrate away from that over to Arch.
Hardware
I haven’t changed anything on the router since the last hardware update, so here’s a recap:
- CPU: Intel Xeon E5-2667v4 with Cooler Master Hyper 212 Black
- Mainboard: Machinist MR9A Pro MAX (find on eBay)
- RAM: 16GB (4x4GB) Kingston DDR4-2400 Registered ECC
- Chassis: NZXT H440 Black
- Power: EVGA 1050 GS
- WAN: 10Gtek X540-10G-1T-X8 10GbE RJ45
- LAN: Mellanox ConnectX-2 10GbE SFP+
Correction, the LAN card was upgraded to the ConnectX-3, but everything else has stayed the same.
Why not OPNsense (or pfSense)? And why Arch?
The router’s first incarnation was at the tail end of 2022, built using leftover AMD FM2+ parts, after I got frustrated both with Google Fiber’s router interface and MikroTik’s RouterOS… non-performance.
And in the 2+ years since, it’s become very apparent that… for a home router, OPNsense (and pfSense) is overkill. Very, very much so. And I don’t need… the vast majority of what OPNsense provides. I almost never log into the OPNsense front-end except for package upgrades.
But updates can end up looking like… this:

This was the proverbial straw in this instance. os-wireguard
is the OPNsense Wireguard plugin. And it appears to have been replaced by something else. Meaning to upgrade OPNsense, I would need to back up my Wireguard configurations, remove everything Wireguard-related, upgrade, add the new Wireguard plugin, then add back my configurations, provided I could actually do that cleanly… Really?
Does FreeBSD not allow packages to be declared as replacements for something else? Good thing I haven’t needed to restore my router from a configuration backup… Anyway…
Routers are typically one-and-done like most servers. Once you have it set up and configured to your liking, there isn’t much need to pay it any mind except for periodic software updates. The virtual machine that serves this website, for example, is like that. Once I have everything on it that needs installed, there’s nothing more for me to do except keep the software up to date.
And those software updates shouldn’t require removing anything to upgrade them. Anyway…
Why Arch?
OPNsense, pfSense, and other similar distributions are built with general purpose in mind along with providing a clean, hopefully intuitive UI for configuration. (Though minus the “clean, hopefully intuitive UI” for VyOS.) They try to anticipate what you’re going to use based on feedback from their audience. This is, by the way, why Windows and a lot of Linux distributions (most distros anymore, it seems) don’t give you any option on what to install, pushing a pre-determined set of software.
Which is why I looked to Arch.
Arch provides two significant benefits: it’s lean, and it’s a rolling release. The latter means I don’t have to worry about a distro going end-of-life, like what’s happening with Ubuntu 20.04 LTS in April 2025. Meaning I don’t have to worry about replacing an entire distribution to keep everything up-to-date, with the downtime that comes with that.
Which is a consideration for OPNsense and pfSense, since both ride on FreeBSD, which are definitely not rolling-release operating systems. And while OPNsense’s upgrade is typically pretty smooth, it isn’t perfect – see the above screenshot. In all seriousness, though, if OPNsense migrated everything to sit on top of Arch – similar to how TrueNAS created SCALE, which rides on top of Debian – I think they’d be much better positioned given the far superior hardware support the Linux kernel offers. Along with not needing to create a magic file to enable the Mellanox driver.
Then there’s how lean you can make an Arch installation.
The base installation instructions on the Arch Wiki start you with only three packages: base
, linux
, and linux-firmware
(plus their dependencies, obviously). You add whatever you need on top of that – and you’ll definitely need more than just that. But it’ll probably surprise you how little you need for a router.
The final install footprint for this project is… under 3GB. Tempting, then, to run this off a USB drive but, for the sake of stability and performance, especially reboot performance… definitely don’t do that. There’s a reason even TrueNAS doesn’t recommend doing that, even though they once did. And I initially ran it that way until switching to an SSD when the USB drive started showing issues.
Though if you really wanted to take things to the edge (pun intended), you could rebuild the kernel with it stripped down to the essentials and nothing more.
Who is this NOT for?
I need to stress that this is NOT a project for the inexperienced. At minimum you need to be comfortable with Linux.
And reasonably comfortable with Arch. The install steps aren’t written with the expectation you’re daily driving it, you should be familiar with Arch’s concepts and how they differ from the other root distributions like RedHat and Debian so you can, at the least, keep it up to date. If you’ve never installed Arch to even a virtual machine to create a simple web host or even a desktop for limited purpose, get comfortable doing that first.
And you absolutely need to be familiar with IP networking concepts – e.g., IPv4, DHCP, DNS, subnets, etc.
Setting it up
All the scripts and configurations I created to set this up are over on Github, along with the instructions for setting this up for yourself.
For Dynamic DNS updating, there are a few options available. OPNsense relied on ddclient, so that’s what I kept. And I migrated my previous Wireguard configuration as well – thankfully it wasn’t difficult to do by hand. Though without a UI, adding another Wireguard configuration will be a little more involved, but not substantially difficult.
Which, in the end, OPNsense is really just a UI on top of existing services.
You must be logged in to post a comment.