Noise Handshakes for NAT Traversal: Rathole Multiplexing Architecture

Carrier-Grade NAT (CGNAT) and multi-layer firewalls frequently isolate edge servers from direct public ingress. While engineers often default to reverse SSH tunnels or heavy VPN daemons, modern systems architectures increasingly deploy lightweight user-space tunnels built on the Noise Protocol Framework. We sat down with Nathan Graves, an infrastructure engineer who designs edge networking systems, to examine the performance limits, multiplexing mechanics, and security trade-offs of Noise-based reverse proxies.

Interview: Protocol Design and Multiplexing Mechanics

Q: Why do traditional SSH reverse port forwarding tunnels struggle under sustained connection loads behind CGNAT, and how does the Noise Protocol approach change that dynamic?

Answer: SSH was built as an interactive secure shell protocol rather than a high-throughput multiplexer. When you establish an SSH reverse tunnel using ssh -R, every tunneled TCP connection shares a single encrypted TCP stream managed by the OpenSSH process. If the upstream provider drops packets or introduces jitter, TCP head-of-line blocking stalls the entire channel. Every multiplexed connection suffers latency spikes while the kernel waits for missing TCP segments to reorder. Furthermore, SSH cipher renegotiation and channel window management introduce measurable CPU overhead under thousands of short-lived sockets. Noise-based systems like Rathole strip away terminal handling, shell negotiation, and subsystem state machines. They run a lean Noise handshake, pin symmetric session keys, and route raw byte streams directly through Tokio asynchronous runtimes without nested protocol bloat.

Q: How do modern reverse proxies avoid the classic TCP-over-TCP meltdown when forwarding application traffic through an intermediate relay server?

Answer: The TCP-over-TCP breakdown happens when an outer TCP layer and an inner TCP stream run competing congestion control and retransmission timers against each other on lossy lines. High-performance reverse tunnels avoid network-layer encapsulation altogether. Instead of establishing a tunneled virtual network interface (such as TUN/TAP devices) that carries encapsulated TCP packets, the client and server maintain a lightweight control connection alongside dedicated worker streams. Each forwarded client connection maps directly to a discrete multiplexed channel or an independent TCP transport stream between the edge client and the public relay. Congestion control remains isolated at the transport boundary between the browser and the relay, while the internal hop runs on tuned TCP window buffers without recursive backoff loops or conflicting retransmission logic.

# /etc/rathole/server.toml - Public Relay Configuration
[server]
bind_addr = "0.0.0.0:2333"

[server.services.http_edge]
token = "9f8a3c2b1e4d5a6b7c8d9e0f1a2b3c4d"
bind_addr = "0.0.0.0:8080"
nodelay = true

# /etc/rathole/client.toml - Private Edge Node
[client]
remote_addr = "relay.example.net:2333"

[client.services.http_edge]
token = "9f8a3c2b1e4d5a6b7c8d9e0f1a2b3c4d"
local_addr = "127.0.0.1:80"
nodelay = true

Interview: Security Boundaries, Handshakes, and Failure Modes

Q: What security boundaries and cryptographic guarantees must operators verify when routing internal backend ports through a public VPS relay?

Answer: A public relay sits in a high-risk network zone exposed to hostile Internet traffic and continuous port scans. If an adversary compromises the relay host, a naive transport proxy could allow the attacker to forge upstream requests and inject payload data directly into the private backend services. When using authenticated Noise handshake patterns like Noise_NK or Noise_KK, the client authenticates the server static public key before sending sensitive authorization tokens, and mutual key exchange ensures the relay cannot spoof its identity. However, operators must remember that the relay terminates external TLS if you choose to terminate certificates there. To maintain strict zero-trust network isolation, you should pass raw TLS traffic end-to-end through the proxy, letting the private origin backend handle cryptographic termination and mutual TLS verification independently.

Terminating TLS on an untrusted relay turns your reverse proxy into a plaintext inspection point. Pass raw TCP streams directly to the origin whenever possible.

Q: What operational failure modes occur during upstream network drops, and how do you monitor client reconnect loops in production?

Answer: CGNAT gateways and stateful firewalls drop silent TCP connections aggressively to conserve state table memory under heavy loads. When an intermediate router silently purges the NAT translation entry from its table without sending a TCP RST flag, the client assumes the socket remains open while the relay believes the client disconnected. To prevent ghost connections, you must enforce low heartbeat intervals and configure TCP keepalive probes at the socket level. Additionally, when the network recovers from an outage, hundreds of reconnecting edge clients can cause a severe thundering herd on the relay daemon. Production services must implement exponential backoff with jitter on the client side, along with strict systemd watchdog timers, health checks, and connection rate limiting to avoid denial of service conditions.

# Verify active socket states and TCP keepalive timers on Linux
ss -tioenp '( sport = :2333 or dport = :2333 )'

# Inspect systemd journal for heartbeat timeout and reconnect loops
journalctl -u rathole -n 50 --no-pager -g "heartbeat|timeout|reconnect"