Why We Build Our SD-WAN Firmware on OpenWrt

Mar 26, 2026

Hopbox team

When we started building Hopbox, the firmware question came early. Do we license a proprietary RTOS, fork an existing vendor SDK, or build on top of an open-source network operating system? We chose OpenWrt, and years later it remains one of the best architectural decisions we have made.

This post explains why proprietary firmware is a liability for network infrastructure, what OpenWrt gives us that no closed platform can, and how we contribute back to the project.

The Problem with Proprietary Firmware

If you have spent any time managing enterprise networking gear, you know the pattern. A critical CVE drops. The vendor publishes an advisory. The patch ships weeks — sometimes months — later, locked behind a support contract and a maintenance window you have to coordinate with the vendor’s release cycle.

Proprietary firmware creates three compounding risks:

Vendor lock-in. Your configuration formats, your management APIs, and your upgrade paths are all controlled by a single company. Switching costs grow with every deployment.
Audit opacity. You cannot read the source. You cannot verify that a vulnerability is actually patched. You cannot confirm what telemetry the device sends home. You trust the vendor’s word, or you trust nothing.
Slow patch cycles. Even well-intentioned vendors have internal release processes, QA gates, and legal reviews that delay security fixes reaching production hardware.

For a company building SD-WAN appliances deployed across hundreds of sites, these are not theoretical concerns. They are operational risks that compound at scale.

Why OpenWrt

OpenWrt is a Linux-based operating system targeting embedded network devices. It has been in active development since 2004 and supports a massive range of hardware platforms. But the reasons we chose it go beyond maturity.

Full source auditability

Every line of code running on a Hopbox device is inspectable. When a kernel CVE is published, our engineering team can read the patch, verify the fix, and build an updated image the same day. We do not wait for a vendor to decide our timeline.

The package ecosystem

OpenWrt ships with opkg, a lightweight package manager, and maintains thousands of packages in its upstream feeds. Need WireGuard? It is a menuconfig toggle. Need advanced QoS with nftables? Already packaged. This means we spend our engineering time on SD-WAN logic, not on reinventing basic network plumbing.

# Checking available packages in an OpenWrt build
./scripts/feeds update -a
./scripts/feeds search wireguard

Community-driven security

The OpenWrt security team and the broader community review code continuously. Patches for critical vulnerabilities often appear within hours of disclosure. Compare that to the typical enterprise vendor’s 30-90 day patch cycle.

Hardware flexibility

OpenWrt supports ARM, MIPS, x86, and more. This gives us the freedom to choose the best hardware for each deployment scenario without being locked to a single SoC vendor’s SDK.

Hopbox’s Customization Layer

We do not ship vanilla OpenWrt. Our firmware includes a customization layer that adds:

SD-WAN overlay management — tunnel orchestration, path selection, and failover logic.
Telemetry collection — lightweight agents that feed link quality metrics into our analytics pipeline.
Zero-touch provisioning — devices pull their configuration from our provisioning API on first boot.
Automatic firmware updates — signed OTA updates with rollback support.

This layer is built as a set of OpenWrt packages in a custom feed. It sits cleanly on top of the base system, which means we can rebase onto new OpenWrt releases without massive merge conflicts.

# Simplified Hopbox feed structure
feeds/hopbox/
    hopbox-core/        # SD-WAN daemon and CLI
    hopbox-telemetry/   # Metrics collection agent
    hopbox-provisioning/# ZTP client
    hopbox-ui/          # Local web management interface

Upstream Contributions

Using open-source software comes with a responsibility to contribute back. We actively participate in the OpenWrt ecosystem:

Bug reports and patches submitted to the OpenWrt core and package feeds.
Testing and validation on hardware platforms we deploy in production.
Documentation improvements for areas we found under-documented during our own onboarding.

We view upstream contribution not as charity but as enlightened self-interest. Every bug we fix upstream is a bug we do not have to carry as a local patch.

Security Patching Workflow

Our patching workflow is built for speed and auditability:

Monitoring. We track the OpenWrt security mailing list, kernel CVE feeds, and NVD entries for all packages in our firmware image.
Triage. When a relevant CVE is published, our team assesses exposure within hours. Most OpenWrt devices have a minimal attack surface — no X server, no desktop libraries, no unnecessary services.
Patch and build. We apply the fix (often cherry-picked from upstream within a day of disclosure), build a new image, and run automated regression tests.
Staged rollout. Updated firmware is pushed first to internal test devices, then to a canary group of production sites, then fleet-wide.

Because we control the entire build pipeline, there is no waiting for a third party. The bottleneck is our own testing, which is as it should be.

Build Reproducibility

Reproducible builds matter for trust. If you cannot rebuild the exact same binary from source, you cannot verify that the binary you are running matches the source you audited.

Our build system produces deterministic images given the same configuration and source tree. We version-lock all feed revisions and use diffconfig to track exactly which options differ from the OpenWrt defaults:

# Generate a minimal config diff
./scripts/diffconfig.sh > hopbox.diffconfig

# Reproduce the build from the diff
cp hopbox.diffconfig .config
make defconfig
make -j$(nproc)

This diffconfig file is checked into version control. Any engineer can reproduce the exact firmware image for any release.

Closing Thoughts

Choosing OpenWrt was not the easy path. The build system has a learning curve. Debugging cross-compiled code on embedded targets is harder than debugging on your laptop. Keeping custom packages compatible across OpenWrt releases takes ongoing effort.

But the tradeoff is clear. We get full control over our firmware, the ability to patch vulnerabilities on our own schedule, a thriving upstream community, and the transparency that lets our customers verify what is running on their network infrastructure.

If you are building network appliances and considering the firmware question, we encourage you to look seriously at OpenWrt. The investment pays for itself many times over.

v1.7.9