Compared with OPNsense#

Where OPNsense is ahead#

• Maturity. Years of releases, a large user base, and behaviour that has been beaten on by many more people than have ever run Wheelhouse.
• Hardware reports. People have installed it on hundreds of boxes and written down what happened. Wheelhouse has no compatibility list: it installs to a disk and reboots into itself on one physical machine, and it has never run on any other.
• A public issue tracker and a community. You can search for your problem and often find it. Wheelhouse's forge is private, there is no public tracker, no forum and no chat channel.
• A large plugin ecosystem, with plugins for things Wheelhouse's 40-entry catalogue does not cover.
• A real company with real terms. Wheelhouse has neither yet: no licence agreement, no terms of service, no prices.

If those matter more to you than what follows, stay where you are.

The configuration model#

This is the difference that is not a feature comparison, because it goes all the way down.

Commit-confirm is not a timer in a web page. It is the operating system's own mechanism, so it survives the management agent crashing, the browser being closed and the link going down; none of those is what holds it.

Linux, not FreeBSD#

The base decides what is on the table. VyOS is Debian with a configuration layer, so:

• nftables rather than pf.
• tc and CAKE for shaping.
• In-kernel WireGuard, not a port.
• Podman containers as configuration objects, which is how the add-on store can make an install into a reviewable diff.
• FRR for BGP, OSPF, IS-IS and BFD, rather than a thin plugin.
• VRFs and network namespaces — VRFs on a page of their own, namespaces at the console.

A FreeBSD appliance is structurally locked out of all of it. That is not a criticism of OPNsense's engineering; it is a consequence of the kernel underneath it.

Accounts#

OPNsense and pfSense have local users and, in OPNsense's case, LDAP or RADIUS. What Wheelhouse puts in front of a network team is this combination:

• OIDC single sign-on with group-to-role mapping;
• four roles enforced server-side on every route, with a denied request logged as such;
• API tokens that carry a role and an expiry, stored only as a SHA-256 and shown once;
• TOTP with ten single-use recovery codes issued at enrolment and shown once, and an administrator who can clear another account's second factor from Admin → Users when the codes went with the phone — or wheelhouse-rescue totp --user NAME at the console when nobody can sign in at all;
• an audit entry naming the actor, their role, their address and, for a commit, the commands it sent.

The API#

Wheelhouse's interface consumes the documented API. Anything a page can do, curl can do, with a token instead of a cookie. There is no private endpoint set and no second protocol.

GET /api/openapi.json serves an OpenAPI 3.1 description of every route the agent registers, each one carrying the role its wrapper enforces and whether it needs a licence, and wheelhouse-agent openapi prints the same document without a router, a key or a licence. It is generated from the agent's own route table rather than written by hand, as is the endpoint table in the operator reference, and a build fails when the two disagree.

Migrating#

wheelhouse-opnsense-import reads a config.xml and writes VyOS commands plus a report of what came across, what came across differently, and what could not. --check-against then compares a running router with the configuration it should have.

It is not one click. It writes commands and a report a person reads.

Read on#

• The configuration model.
• Getting onto it — the importer, in more detail.
• What is finished, and what is not.
• The parity matrix — the same argument as a table, losses included.