sanstun: A sans-IO, parallel-friendly WireGuard implementation in Rust
wh33zle
99 points
17 comments
October 30, 2026
Related Discussions
Found 5 related stories in 122.5ms across 11,107 title embeddings via pgvector HNSW
- Open WireGuard Endpoints mlhpdx · 33 pts · August 14, 2026 · 50% similar
- GPU Offload in Rust: Portable, Safe, and Fast linggen · 185 pts · August 17, 2026 · 49% similar
- Async Rust vs RTOS showdown (2022) kooi · 71 pts · September 02, 2026 · 49% similar
- Show HN: MCP-stama – An ultra-fast Rust MCP server with no dependencies stammanif · 71 pts · August 13, 2026 · 48% similar
- How Our Rust-to-Zig Rewrite Is Going jorangreef · 467 pts · July 16, 2026 · 47% similar
Discussion Highlights (7 comments)
temp0826
Mullvad spun their own implementation off of boringtun as well (called gotatun[0]) [0] https://github.com/mullvad/gotatun
monocasa
Sweet, this is basically how I design my protocol implementations in rust as well. Way more testable, the bulk can be shared between async and blocking IO, it's a lot easier to completely ban unsafe in your dependencies (excepting std and core), etc.
asdf88990
From their website about their product: > Hardware does the heavy lifting. > Your operating system and network card take over the repetitive jobs whenever they can. Your CPU gets room to breathe, and your battery stays full longer. Where does this operating system run? Where does the power come from to run it if not battery? Pure rubbish ai slop. While the software might actually be ok upon inspection but this kind of ai slop nonsense copy doesn’t inspire confidence in using their software considering how security critical the vpn is.
lakeviewterrace
WireGuard implementations that are not Jason's reference implementation are stupid and an explicit invitation for issues. I will die on this hill. WG is like 2k LOC why the fuck do we need 30 different versions? Audit what you have.
Twey
It was all going great until I read > The design also avoids problems like function coloring and plays well with Rust's ownership rules. Async is not I/O. It can be used for I/O, but it's just a way of writing pure, deterministic state machines that keeps a logical flow together instead of scattered over a bunch of transitions. Even if you choose to manually compile your async flows into explicit state machines, you still have to deal with ‘function colouring’ (a.k.a. typing): a flow that crosses several state transitions (and may have other disjoint parts of the state updated in the meantime, via other transitions) now has to be rewritten as a (series of) state transitions, and can't be called from a blocking function. If anything, rewriting all your state machines without `async` makes the function colouring ‘problem’ worse, because multi-transition flows are even more different from normal functions.
clivedup
I've wanted Wireguard on some MCUs. Great!
mlhpdx
One of the fundamentally great things about the Wireguard protocol is the simplicity. A small codebase can implement it, and that’s lead to some great libraries and innovation. Another great (and subtle) thing is the monotonically increasing sequence number. Note that it isn’t incrementing, like DTLS. This small thing makes it so much easier to implement with efficient concurrency, and event external state (i.e. distributed concurrency). That latter bit we’ve done in our own library. Edit: typo, don’t -> done