Zero-Trust Tunnels: Rathole Setup for Secure Edge Access

Aug 21, 2026 2 min read cybersecurity, Development

Exposing internal edge services behind NAT or CGNAT usually forces operators to choose between slow VPN overhead and exposed public ports. While SSH remote forwarding works for temporary debugging, it lacks automatic reconnection state handling and multiplexing efficiency under high packet loss.

Why SSH Remote Forwarding Breaks Under Scale

Standard SSH tunnels allocate dedicated TCP connections per forwarded stream. When network latency spikes or local interfaces drop, SSH client sessions stall indefinitely until TCP keepalive timeouts expire. Running continuous reverse proxies over SSH requires brittle wrapper daemons like autossh that churn process IDs without solving head-of-line blocking.

Exposing raw SSH sockets to public IPv4 addresses creates persistent authentication noise. Moving tunnel initiation to Noise protocol handshakes eliminates public attack surface entirely.

Rathole replaces SSH tunneling by establishing a single persistent control connection using the Noise protocol over TCP or UDP. Edge clients initiate outbound connections to a central server, mapping internal local ports directly to remote endpoints without exposing local firewall ports to incoming traffic.

Configuring a Rathole Server and Client Pair

Deploying Rathole requires a lightweight TOML configuration file on both the public gateway server and the remote client node.

On the public server (server.toml):

[server]
bind_addr = "0.0.0.0:2333"

[server.services.web_service]
bind_addr = "0.0.0.0:8080"
token = "c8f92a10e4b37d61f"

On the internal edge client (client.toml):

[client]
remote_addr = "203.0.113.10:2333"

[client.services.web_service]
local_addr = "127.0.0.1:3000"
token = "c8f92a10e4b37d61f"

Execute the binary on both nodes using Systemd units to enforce automatic restart policies:

# Start server daemon on public node
rathole --server /etc/rathole/server.toml

# Start client service on edge node
rathole --client /etc/rathole/client.toml

Operational Advantages Over Traditional Proxies

Zero incoming open ports required on the local edge node firewall.
Noise protocol encryption ensures low memory consumption and high throughput compared to user-space TLS proxies.
Instant connection recovery when underlying network interfaces reset or switch IP addresses.

For self-hosted infrastructure operating behind strict ISP firewalls or mobile broadband connections, Rathole provides reliable port forwarding without relying on third-party cloud relays.