Why We Rewrote the Tunnel Stack in Rust

Building a reliable tunnel server is more complicated than simply forwarding network traffic. A production-grade secure tunnel needs to handle TLS connections, authentication, concurrent sessions, routing, unexpected input, graceful shutdowns, and failures without taking down unrelated connections.

That is one reason Rust is becoming an interesting choice for networking infrastructure.

The original engineering story behind 21tunnel describes a deliberate move from the common Go-based approach to a Rust tunnel stack, with strict compile-time rules designed to make unsafe failure paths difficult to introduce. The project uses #![forbid(unsafe_code)] and denies patterns such as unwrap, expect, panic, and todo! through its lint configuration.

Why Rust for a Tunnel Server?

The most important advantage is memory safety.

Rust's ownership system allows the compiler to enforce memory-safety rules without requiring a garbage collector. If ownership or borrowing rules are violated, the program does not compile.

For a tunnel server handling untrusted network traffic, this provides an important foundation.

A tunnel may have hundreds or thousands of active connections. A memory-related bug, unexpected panic, or poorly handled failure can affect more than a single request—it can potentially impact many active sessions.

Rust helps move some of these problems from production debugging into compile-time verification.

Making Failure Paths Explicit

Network applications fail constantly.

Connections disappear. TLS handshakes fail. Databases become unavailable. Clients send malformed data. Services restart during deployments.

Rust's Result type encourages developers to handle these conditions explicitly instead of assuming every operation will succeed.

Strict linting can take this approach further. The 21tunnel implementation uses compiler and Clippy rules that reject several common failure-prone patterns, forcing error paths to be handled during development.

This leads to an important principle for infrastructure software:

Make failures boring and predictable.

A malformed request should result in a controlled error—not a process-wide crash.

Async Networking with Tokio

A tunnel server needs to manage many connections concurrently, making asynchronous networking essential.

Tokio provides an asynchronous runtime for Rust and the building blocks needed to develop network applications. Its runtime supports concurrent tasks and networking workloads ranging from large servers to smaller systems.

A simplified Rust tunnel architecture might look like:

Internet
   |
   v
Tunnel Server
   |
 TCP + TLS
   |
Multiplexed Session
   |
Tunnel Agent
   |
Private Service

The tunnel server accepts an agent connection, establishes TLS, authenticates the session, and then routes traffic through the appropriate tunnel.

Tokio's asynchronous task model makes it possible to manage many independent connections without dedicating a heavyweight operating-system thread to every connection.

Why TCP + TLS Instead of QUIC?

The choice of transport is another important engineering decision.

The 21tunnel engineering notes explain that an early prototype used QUIC but ultimately moved to TCP + TLS. The reasoning included compatibility with restrictive networks, smaller agent binaries, and easier troubleshooting with familiar TCP/TLS tools.

This highlights an important lesson: the newest networking protocol is not automatically the best protocol for every deployment environment.

For tunnel agents running from laptops, corporate networks, mobile connections, or public Wi-Fi, compatibility can be just as important as raw protocol capabilities.

Multiplexing Multiple Connections

A tunnel can also use multiplexing to carry multiple logical streams over a persistent connection.

Instead of establishing a separate transport connection for every request:

Connection
 ├── Stream A
 ├── Stream B
 ├── Stream C
 └── Stream D

multiple streams can share the same underlying connection.

The 21tunnel implementation uses Yamux alongside tokio-rustls for its TCP/TLS architecture.

This approach can reduce connection overhead while keeping the tunnel architecture relatively straightforward.

Rust Has Real Trade-Offs

Rust is not a free performance upgrade.

The engineering team behind 21tunnel notes several costs: longer release build times, a smaller hiring pool, some ecosystem gaps, and a steeper learning curve around ownership and lifetimes.

These are important considerations for any team evaluating Rust vs Go for networking.

Go remains an excellent choice for network infrastructure because of its simple concurrency model, mature ecosystem, fast builds, and large developer community.

Rust becomes particularly attractive when compile-time guarantees, memory safety, predictable resource usage, and strict failure handling are high priorities.

Final Takeaway

Rewriting a tunnel stack in Rust is not simply about chasing performance.

The bigger motivation is reliability and engineering discipline.

A secure tunnel sits at the intersection of networking, security, concurrency, and infrastructure. Rust's ownership model, async ecosystem, explicit error handling, and compile-time checks can provide strong foundations for that environment.

The most useful lesson is therefore not that Rust is universally better than Go.

It is that the language should help enforce the reliability properties your infrastructure depends on.

For developers building tunnel servers, remote-access tools, proxies, edge agents, or other security-sensitive networking software, Rust offers an increasingly mature platform for building systems where safety and performance need to coexist.

Key Takeaways

• Rust provides strong compile-time memory safety guarantees.
• Tokio provides a mature foundation for async Rust networking.
• TCP + TLS can be preferable when compatibility and debugging matter.
• Multiplexing allows multiple logical streams over persistent connections.
• Strict compiler and Clippy rules can improve network security and reliability.
• Rust has trade-offs, particularly build times and its learning curve.
• The best technology choice depends on the project's operational requirements.