Why we built it
The router is the least trustworthy computer most organisations own. It runs a vendor’s fork of an old kernel, a tangle of shell scripts around utilities nobody has audited, and a web interface that stops receiving security updates about eighteen months after purchase. When one misbehaves, there is usually no way to find out why.
corerouter is the opposite proposition: there is no component on the box whose behaviour we cannot account for line by line, the whole stack is small enough to audit in full, and a bad change undoes itself.
What is actually on the box
The entire attack and audit surface is first-party: built against the standard
library and libc and nothing else — no async runtime, no serialisation
framework, no third-party crates in the running system. There is no upstream CVE
feed to track for this stack, because there is no upstream.
- A DHCP server and a DHCP client, both written to the RFCs rather than wrapped — and structured so that an entire lease lifetime, including a misbehaving upstream server, is exercised in automated tests rather than discovered in the field.
- A caching DNS forwarder with TTL ageing, negative caching, anti-spoofing and a compression-pointer loop guard.
- A firewall policy compiler that renders nftables from typed configuration and validates the ruleset before applying it.
- Multi-WAN failover — and failback — with per-uplink probe threads and three-state hysteresis, so a flapping link does not flap your traffic.
- CAKE/SQM shaping on egress and ingress, a metrics API and dashboard, and the initramfs PID 1 that chooses between A/B root filesystems.
They run as static binaries under systemd, each with an exact capability set and
a strict sandbox, with every unsafe block confined to an audited syscall
wrapper. No container runtime on the device, and nothing compiled on the
device.
Configuration that cannot strand you
Configuration is where routers get compromised and where administrators get locked out. corerouter treats a change as a transaction, and the guarantees are the product:
- A change applies everywhere or nowhere. If any part of the system does not end up running the new configuration, the whole change is undone automatically and you are told what refused it.
- A change that severs your own connection undoes itself. Commit with a confirmation window and the box restores the previous configuration on its own if you never confirm — surviving a crash or a reboot in the process.
- Configuration values cannot become instructions. Injection through a configuration field into the firewall, the radio or a command line is eliminated by construction rather than filtered case by case.
These are the properties we would want if we were operating the box. Almost no consumer or small-business router offers any of the three.
What we can show you
The stack runs in service on single-board ARM64 hardware — access point up and bridged into the LAN, leases issued, DNS resolving, NAT and firewall in place, the dashboard reachable, no failed units. A single-NIC board: the built-in Ethernet is the WAN, the radio is the LAN.
Behind that sits an automated verification suite that runs against a live kernel in isolated network namespaces — a three-node topology taking live DHCP leases, failover and failback against an off-link probe target, an nftables ruleset asserted default-deny, and the A/B boot chooser walked through arm, three failed boots and automatic revert. Failure paths are tested by injecting failures: kill a daemon mid-commit and the suite asserts the rollback.
The build pipeline never executes target code. It cross-compiles to static musl binaries and then places files into an image, so it runs on an ordinary laptop with no emulator and no root, in rootless containers, leaving the host untouched.
Where it goes next
Current scope is IPv4 edge routing. A full feature and validation matrix — what is proven, what is asserted, and what is not built — is part of any evaluation.
What this demonstrates
corerouter is the clearest single artefact of what this practice does. It spans board bring-up, kernel-adjacent networking, systems programming in a memory-safe language, and the release engineering to turn all of it into an image you can flash. In most organisations those are four separate teams. Here they are one codebase, one accountable engineering team, and a verification suite that runs in minutes.
Talk to us about
Custom network appliances, embedded Linux platforms, control-plane and data-plane software, or replacing an ageing vendor stack with something you own, can audit, and can change without asking permission.