DEV Community

Cover image for Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"
Ali Alp
Ali Alp

Posted on

Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"

#opensource #security #productivity

Your MRI scanner needs to talk to a cloud AI platform. Your vendor needs to reach a single maintenance port on a factory-floor PLC. Your data scientist needs to query an on-premise database from a cloud notebook. The firewall says no to all of them.

Tunnel Whisperer says yes.

Github page

The Problem Nobody Talks About

Enterprise networks are getting stricter. Firewalls block everything except port 443. Deep Packet Inspection kills anything that doesn't look like genuine HTTPS. Legacy devices — hospital scanners, industrial controllers, aging servers — can't run modern VPN clients. And even if you could install one, IT won't open a single inbound port.

This is the Connectivity Gap: the space between what your applications need and what your network allows.

Traditional solutions don't fit:

  • VPNs (WireGuard, Tailscale) require UDP ports or custom protocols — blocked by DPI.
  • Reverse proxies (ngrok) expose services to the public internet — a non-starter for healthcare and manufacturing.
  • SSH tunnels get flagged and dropped by next-gen firewalls.

We built Tunnel Whisperer to close this gap.

What Is Tunnel Whisperer?

Tunnel Whisperer is an open-source tool that creates resilient, port-to-port bridges across separated private networks. It wraps your TCP traffic inside a genuine TLS-encrypted HTTPS stream using Xray's VLESS+XHTTP protocol. To the network, it looks exactly like someone browsing a website.

Client Network             Public Cloud               Server Network
+--------------+        +------------------+        +--------------+
|  tw connect  |--443-->|     Relay VM     |<--443--|   tw serve   |
|              |  HTTPS |  Caddy + Xray    |  HTTPS |              |
| local ports  |        |  (reverse proxy) |        | SSH server   |
| :5432 :3389  |        |  Firewall: 80+443|        | port fwd     |
+--------------+        +------------------+        +--------------+
Enter fullscreen mode Exit fullscreen mode

Your PostgreSQL client connects to localhost:5432. Your RDP client connects to localhost:3389. The traffic flows through an HTTPS tunnel to the server network, where it reaches the actual services. The applications on both ends have no idea a tunnel exists.

Why We Built It

We kept running into the same scenario: a customer with a legitimate connectivity need, a network that blocks everything, and no tool that threads the needle between "too broad" (VPN) and "too public" (ngrok).

Tunnel Whisperer is designed around three principles:

1. Surgical access, not broad connectivity. Each user gets access to exactly the ports they need — nothing more. No host-to-host networking, no route tables, no exposure of adjacent services.

2. Invisible to the network. The traffic is indistinguishable from regular HTTPS. No special ports, no unusual protocols, no signatures for DPI to flag.

3. Zero trust at the relay. The relay VM is a dumb pipe. It stores no SSH keys, no passwords, no application data. If it gets compromised, the attacker gets nothing useful — all plaintext remains encrypted by the SSH layer inside the tunnel.

How It Works: Three Layers of Encryption

Tunnel Whisperer stacks three encryption layers, each serving a different purpose:

Layer What It Does
TLS 1.3 (outer) Makes the traffic look like HTTPS. Caddy handles automatic Let's Encrypt certificates on the relay.
Xray VLESS + XHTTP (middle) Routes users by UUID through the relay. XHTTP splits data into standard HTTP requests for resilience against connection timeouts.
SSH Ed25519 (inner) End-to-end encryption between client and server. Public-key only — no passwords, no brute-force surface. Per-user permitopen restrictions lock each client to specific ports.

The relay terminates TLS but never sees the SSH-encrypted payload. Even if someone owns the relay, they can't read your data.

Real-World Use Cases

Healthcare: DICOM Through a Firewall

A hospital's MRI scanner needs to send images to a cloud AI platform for analysis. The scanner speaks DICOM on port 104 and can't install any software. Tunnel Whisperer runs on a gateway machine on the scanner's LAN, forwarding port 104 through the HTTPS tunnel to the cloud. The scanner sends to localhost:104 as if the AI platform were next door.

Manufacturing: Vendor Access to a Single Port

A machine vendor needs remote access to a PLC's maintenance port for diagnostics. Instead of a VPN that exposes the entire factory network, Tunnel Whisperer gives them access to exactly one port on one device. When the job is done, revoke the key — access gone.

Data Science: Cloud Notebook to On-Premise Database

A data scientist running Jupyter in the cloud needs to query a PostgreSQL database behind a corporate firewall. With Tunnel Whisperer, they connect to localhost:5432 and run queries as if the database were local. No VPN client, no firewall exceptions, no IT tickets.

Getting Started in 5 Minutes

Tunnel Whisperer ships as a single binary for Linux, Windows, and macOS. Build from source with Go 1.25+:

make build          # builds bin/tw
Enter fullscreen mode Exit fullscreen mode

Server Side 

tw dashboard                # open the web UI
tw create relay-server      # 8-step wizard: provision a relay VM
tw create user              # 5-step wizard: create a client with port restrictions
tw serve                    # start the server
Enter fullscreen mode Exit fullscreen mode

The relay provisioning wizard handles everything: spinning up a VM on Hetzner, DigitalOcean, or AWS, configuring Caddy for TLS, installing Xray, and locking down the firewall to ports 80 and 443 only.

Client Side

The server admin sends you a config bundle (a zip file with your config and SSH keys). Then:

tw dashboard                # drag-and-drop the zip file
tw connect                  # you're in
Enter fullscreen mode Exit fullscreen mode

That's it. Your configured ports are now available on localhost with automatic reconnection if the connection drops.

The Web Dashboard

Both server and client modes come with a browser-based dashboard for managing everything visually:

Server dashboard — create users, provision relays, monitor connected clients, stream logs in real-time, and open an interactive SSH terminal to the relay — all from the browser.

Client dashboard — upload config bundles, connect/disconnect with one click, and see your active tunnels with bandwidth stats.

No separate web app to deploy. The dashboard is embedded in the same tw binary.

Per-User Access Control

Every user gets:

  • A unique Xray UUID for relay routing
  • An Ed25519 key pair for SSH authentication
  • A permitopen directive restricting them to specific ports 
# authorized_keys (auto-generated)
permitopen="127.0.0.1:5432",permitopen="127.0.0.1:3389" ssh-ed25519 AAAA... alice
permitopen="127.0.0.1:104" ssh-ed25519 AAAA... vendor-dicom
Enter fullscreen mode Exit fullscreen mode

Alice can reach PostgreSQL and RDP. The vendor can reach the DICOM port. Neither can reach anything else. Revoking access is instant — remove the key from authorized_keys and the UUID from the relay config. No server restart needed.

Built for Resilience

Connections drop. Networks hiccup. Tunnel Whisperer handles it:

  • Auto-reconnection with exponential backoff (2s up to 30s max)
  • SSH keepalive every 15 seconds to detect dead connections early
  • XHTTP transport splits data into HTTP requests, surviving connection resets that would kill WebSocket-based tunnels
  • System service mode (tw service install) for auto-start on boot — Linux systemd, Windows SCM, or macOS launchd

Performance

We won't pretend there's zero overhead. Two relay hops and three encryption layers have a cost. Here are real numbers from our benchmarks (relay on Hetzner, ~30ms RTT):

Metric Direct SSH Tunnel Whisperer
Throughput (100 MB transfer) 112 MB/s 21 MB/s (~168 Mbps)
Database TPS (pgbench, 50 clients) ~1,790 ~80-95
Database latency ~28 ms ~530-630 ms

Tunnel Whisperer excels at bulk transfers, streaming, and interactive sessions where human-speed interaction or continuous data flow hides the latency. For high-frequency RPC workloads with many small round-trips, you'll want to use connection pooling and place the relay geographically close to both endpoints.

The tradeoff is clear: you lose raw speed, but you gain connectivity where no other tool can get through.

How It Compares

Tunnel Whisperer VPNs (Tailscale/WireGuard) Reverse Proxies (ngrok)
Scope Surgical (port-to-port) Broad (host-to-host) Public (port-to-web)
DPI Resistance High (genuine HTTPS) Low (custom protocols) Medium (standard HTTPS)
Deployment Gateway/sidecar Agent on every host Dev/test
Infrastructure Self-hosted SaaS/hybrid SaaS
Relay Compromise No credential exposure Varies Provider-dependent

What's Next

Tunnel Whisperer is currently in alpha. The core tunnel, user management, dashboard, and multi-cloud relay provisioning are all working. Here's where we're heading:

  • UDP support for protocols that need it
  • Multi-relay topologies for geographic distribution
  • Observability — OpenTelemetry-format logging is already in progress
  • Pre-built binaries and package manager distribution

Get Involved

Tunnel Whisperer is MIT-licensed and open source.

If you've ever stared at a firewall rule that blocks everything and thought "there has to be a better way" — give Tunnel Whisperer a try. We'd love your feedback, bug reports, and contributions.

Tunnel Whisperer — because sometimes the only way through is to whisper.

Top comments (0)