mrkeyoor.com_
Sat 31 Oct 05:58 UTC
Open Source3 min read

Firezone announces sanstun for parallel WireGuard packet processing

The Rust library separates protocol state from cryptographic work. Applications still handle I/O, queues and routing checks, and sanstun has no formal security audit.

Firezone announced sanstun on October 31, 2026, a Rust implementation of WireGuard that lets applications move packet encryption and decryption onto worker threads. Its announcement describes a way to parallelize work within one tunnel while keeping protocol state on an owner thread. Actual throughput gains remain a deployment question.

The Apache-2.0 project replaces Firezone's deprecated BoringTun fork. It is a library for developers building networking software. It needs an application around it to move packets.

Where the work splits

Firezone's API explanation separates bookkeeping from cryptography. Before encryption, the tunnel reserves a packet counter and updates its state. The resulting work can move to another thread. That gives implementers a way to distribute expensive computation without sharing all the tunnel's mutable state between workers.

Firezone publishes timings for these individual operations, but cautions that its projected speedup excludes thread-handoff costs and other overhead. We haven't run the benchmarks or tested a deployment. Those timings don't establish an application's throughput.

The repository also leaves out internal packet buffering, network I/O and TUN-device I/O. An application supplies the event loop. That makes queue management an integration task, with consequences for both performance and resource use.

What the application must still enforce

The API documentation, labelled version 0.1.0, tells callers to bound queues that dispatch cryptographic work. A pending decryption is cheap to create but expensive to process, so a flood can exhaust memory. Adding workers therefore brings a queue-sizing decision with it.

The same documentation requires applications to check that a decrypted packet's source IP is allowed for the sending peer. They must also validate packet lengths and remove padding before forwarding. Successful authentication alone doesn't authorize an IP address. These are documented caller responsibilities, not findings from our own security testing.

The README says sanstun has not received a formal security audit. Developers evaluating it can inspect a specific division of responsibility: the library handles protocol mechanics, while their application controls packet movement and routing policy. Independent audit results and measurements of complete integrations, including queue and thread costs, are the evidence to watch next.

Sources

  1. Introducing sanstun: A sans-IO, parallel-friendly, userspace WireGuard implementation in Rust
  2. firezone/sanstun repository and caller responsibilities
  3. sanstun 0.1.0 API documentation