Sanstun: The WireGuard Library That Makes You Own the Edges

A VPN can encrypt every packet correctly and still be the wrong system to trust. The missing piece may be a routing decision, an overloaded queue, or a timer that behaves differently after a laptop wakes up. Firezone’s newly announced sanstun puts that distinction in focus. Its introduction reached more than 100 points on Hacker News, but the interesting story is not another implementation of a familiar protocol. It is the boundary between a protocol library and the application that turns it into a working network. For anyone building remote-access software, that boundary is where operational responsibility begins.

The Coe Lab’s view: sanstun is worth evaluating as an architectural building block, not as an upgrade that ordinary WireGuard administrators should rush to install. A better library can make the hard parts easier to isolate. It cannot make the surrounding system somebody else’s problem. The practical opportunity is to design those surrounding responsibilities explicitly before they turn into production incidents.

Background: a protocol engine is not a complete VPN

Firezone describes sanstun as a Rust, userspace WireGuard implementation with a sans-IO interface. Its announcement explains that the project follows years of adapting a BoringTun fork. The new API separates protocol bookkeeping from encryption work so applications can dispatch the latter to workers. Firezone presents this as a way to improve integration and enable parallel processing, not as a new VPN protocol. Source: Firezone’s launch announcement, linked below.

WireGuard’s protocol documentation describes encrypted transport over UDP, periodically renewed sessions, and counters used in replay protection. These mechanisms establish important properties of communication between peers. They do not, by themselves, answer every deployment question: who should be enrolled, which destination should be reachable, how keys should be distributed, or what a stalled application should do. Those are system-design decisions layered around the protocol.

Think of the distinction as the difference between a database storage engine and an entire database service. The engine can be excellent while the service has inadequate admission control, unsafe administration, or an unusable recovery procedure. A networking component deserves the same separation in review. Ask first which guarantees belong to the component, then which guarantees depend on the integrator. Buying or adopting one layer should never silently count as validating all the others.

Sans-IO moves the operating environment into view

In its repository, sanstun says it performs neither UDP nor TUN-device IO and requires an event loop. The README also identifies responsibilities left to callers: cryptokey routing, validation of inner IP packets, adequate seed entropy, and monotonically increasing time inputs. These are not small-print exceptions to a complete appliance. They define the integration contract. Source: the project README, linked below.

Our analysis is that making this contract visible is useful precisely because it prevents a seductive kind of ambiguity. When a component owns its own sockets, timers, queues, and worker pool, an application can become dependent on behavior it never deliberately selected. A more explicit boundary makes those decisions reviewable. The trade-off is additional integration work, and teams should budget for that work rather than treating a smaller protocol core as a smaller total product.

A useful design exercise is to write an ownership ledger before writing the adapter. Give every queue, clock input, routing table, key source, and shutdown transition a named owner. For each one, record the failure behavior. Does a queue drop newest traffic or oldest traffic? Does shutdown drain work or cancel it? Can configuration change while packets are already being processed? If a design document cannot answer these questions, the implementation will still answer them, just accidentally.

This is especially relevant for teams integrating networking into an existing service. The right answer may be to reuse the service’s event loop and observability rather than introduce a second runtime. But reuse should be a measured choice. If the same loop also processes expensive application tasks, a burst of unrelated work could delay protocol maintenance. Explicit control is valuable only when somebody verifies how that control behaves under contention.

Parallel encryption is a scheduling problem, not a free speedup

The launch article’s microbenchmarks illustrate a split between relatively short bookkeeping steps and more expensive cryptographic processing. Firezone explicitly cautions that its theoretical speedup discussion excludes real-world overhead. That qualification matters more than an impressive multiplier. A component benchmark can identify an optimization opportunity; it cannot establish the throughput or latency of your finished gateway.

Consider an illustrative gateway serving both interactive terminals and large backups. Moving packet work to multiple workers might increase aggregate throughput while making the terminal less responsive. The workers might receive oversized batches, share a saturated memory path, or complete work in an order the application handles poorly. None of those outcomes contradicts a fast encryption benchmark. They reveal that scheduling, fairness, and buffering are separate performance dimensions.

Start with a deliberately simple implementation and measure where time goes. Record queue residence time separately from cryptographic execution time. Compare one busy peer with many moderately busy peers. Include small packets, mixed packet sizes, and bidirectional traffic. Then repeat at the CPU allocation the gateway will actually receive, including container quotas if applicable. A result gathered on an otherwise idle workstation is a hypothesis about production, not a production capacity plan.

Batching deserves its own experiment. Larger batches can amortize dispatch overhead, but waiting to fill them can increase latency. A sensible acceptance criterion therefore combines throughput with a latency ceiling and a bounded memory budget. If a change improves total bytes per second while violating either of those constraints, it may be the wrong optimization for remote administration even if it would help an overnight transfer service.

The dangerous gap between peer identity and network permission

The repository states a particularly important boundary: successful decryption establishes which peer sent a packet, but checking whether its source IP is allowed belongs to the application. It also leaves destination-based selection of the outgoing tunnel to the caller. Those statements are a useful reminder that authenticated identity and authorized reachability are different questions.

Imagine a test deployment with two enrolled peers: one for an administrative workstation and one for an untrusted automation runner. Both possess legitimate keys. The security goal is not merely to reject strangers. It is also to stop the runner from claiming traffic associated with the workstation or reaching management-only services. An integration test that proves both peers can connect would miss the more important negative cases.

Build a small authorization matrix. Rows represent enrolled identities; columns represent source ranges and destination services. Mark allowed and denied combinations, then turn the denied combinations into executable tests. Include configuration transitions: remove a peer, narrow an address range, and change a route while traffic is active. The exact enforcement mechanism depends on the application, but the expected behavior should remain understandable without reading the packet-processing code.

Also distinguish this integration review from a cryptographic audit. Safe language choices and thoughtful APIs can reduce classes of mistakes, but they do not establish that a complete deployed system has been independently assessed. We are not reporting an audit or a hands-on security evaluation here. The point is to make evidence requirements specific: protocol correctness, authorization correctness, and operational containment each need their own review.

A practical evaluation plan for developers and homelabbers

For an application developer, the first milestone should be a narrow laboratory adapter, not production migration. Connect a controlled pair of peers, expose the state transitions through logs or metrics, and write down what the adapter must provide. Avoid using production credentials in deterministic test fixtures. Reproducibility is useful for investigating failures, but a repeatable test setup and a safely initialized live service have different requirements.

1. Define the actual problem: runtime integration, an observed bottleneck, or better failure simulation. Do not adopt a new implementation solely because it is new.
2. Specify ownership of time, randomness, sockets, packet buffers, worker scheduling, and route policy. Review those responsibilities before adding concurrency.
3. Test packet loss, duplication, reordering, stalled workers, and peer restarts. Measure recovery behavior as well as successful steady-state traffic.
4. Set bounded queues and explicit overload behavior. Verify that rejected or dropped work produces useful metrics without logging sensitive packet contents.
5. Keep a rollback path using a separate management connection. Run a limited canary only after compatibility and authorization tests pass.

For most homelab administrators, the appropriate action is different: keep the currently working VPN and use the architecture as a checklist for evaluating future products. Ask whether management access depends on the experimental path. Check that a routing mistake cannot expose every internal service. Keep configuration backups that can actually be restored. A library announcement is not evidence that your existing deployment has become obsolete.

For IT leaders, ask teams to price the whole lifecycle. A dependency that fits an existing runtime may reduce adapter complexity, but someone still owns upgrades, regression tests, incident diagnosis, and release monitoring. Compare the cost of maintaining a custom networking service with using a supported solution. The important unit of analysis is the operational service, not the number of lines imported into the codebase.

What This Means: test the seams before trusting the center

Our central takeaway is that infrastructure quality often depends on the seams rather than the algorithm at the center. An explicit protocol interface creates an opportunity to test those seams under controlled conditions. It does not guarantee that a team will take that opportunity. The difference will show up in the quality of the adapter, its failure tests, and the clarity of its operational ownership.

A productive acceptance test would ask more than whether encrypted traffic flows. Can the service refuse unauthorized inner addresses? Can it keep memory bounded when a worker stalls? Can an operator identify whether packet loss came from ingress, a queue, cryptographic processing, or egress? Can a restart restore connectivity without manual intervention? These questions convert an architectural preference into outcomes an operator can verify.

This also suggests a better way to discuss performance claims publicly. Instead of repeating a theoretical multiplier, publish the workload, hardware limits, queue policy, latency distribution, and failure conditions alongside a baseline. A smaller throughput gain with predictable tail latency and clear overload behavior may be far more valuable than a larger headline number. Networking exists to support applications, not to win isolated benchmarks.

What to watch next

The most useful next evidence would be independent integrations with documented operational results: how much adapter code was required, which responsibilities proved easy to misunderstand, and how behavior changed under load or failure. Watch for API evolution as well. A clean initial interface is encouraging, but maintainability becomes clearer when multiple applications with different runtimes and traffic patterns depend on it.

Our prediction is modest: the strongest benefit of this style of library will often be easier reasoning about failures, not a universally dramatic throughput improvement. That is an analytical expectation, not a measured finding about sanstun. For teams building networking products, the immediate task is to identify their ownership boundary and prove it with tests. For everyone else, the lesson is equally practical: a trustworthy VPN is a complete operational system, not just correct encryption.

Sources and context

This is an Opinion analysis by The Coe Lab, based on the primary materials linked below. No original benchmarks were performed. Hacker News scores are a snapshot of interest at research time, not an endorsement of technical claims.

Firezone: introducing sanstun

Sanstun repository and integration responsibilities

WireGuard protocol and cryptography documentation

Hacker News discussion