Skip to main content

Tunnel (Secure Port Forwarding)

The Tunnel tab creates a secure, on‑demand TCP tunnel from your browser to a service running on the device. Common use cases include accessing a local admin UI (e.g., http://localhost:8080) or debugging a service that is not publicly exposed.

How it works

  • Your browser connects to Daployi, which bridges an encrypted tunnel to the device’s agent. Traffic is forwarded between your local machine and the target on the device.
  • Tunnels are user‑scoped, temporary, and audited in Events.

Creating a tunnel

  1. Open Devices > select a device > Tunnel.
  2. Click New Tunnel and fill the fields below, then Start.

Fields (explained)

  • Local Bind Address (optional): The interface on your machine to bind to. Defaults to 127.0.0.1 (loopback). Use 0.0.0.0 only if you need to share the tunnel with others on your network.
  • Local Port: The port on your machine you will connect to (e.g., 18080). If unspecified, a random free port may be chosen.
  • Remote Host: The target host on the device side. Usually 127.0.0.1 (the device itself). For container UIs bound to the host network, 127.0.0.1 is appropriate; for bridge networks, use the container’s IP if needed.
  • Remote Port: The target port on the device to forward to (e.g., 8080 for a web UI).
  • Protocol: TCP (default). Use HTTP label if the UI provides helpers to open a browser; underlying transport is TCP.
  • Description (optional): A note for audit (e.g., “temporary access to admin console”).

Using the tunnel

  • Once active, the UI shows a clickable URL like http://127.0.0.1:18080.
  • Multiple tunnels can run simultaneously if ports do not conflict.
  • The list shows status, uptime, and data transferred.

Lifecycle

  • Active until you click Disconnect, close the tab (may auto‑terminate), or an idle timeout occurs.
  • All open/close events are logged with user, device, and parameters (not including secrets).

Security

  • Principle of least exposure: Keep Local Bind at 127.0.0.1 unless you have a specific reason.
  • Use short sessions and close tunnels when finished.
  • Access is permission controlled (e.g., devices.tunnel). Ensure roles are appropriate.

Troubleshooting

  • Connection refused: Verify the service is listening on the device at Remote Host:Remote Port.
  • Port already in use (local): Pick a different Local Port (e.g., 18081).
  • No response in browser: Confirm protocol (HTTP vs custom TCP). For HTTPS with self‑signed certs, accept the warning or use HTTP if appropriate.
  • Container networking: If the service runs in a bridge‑networked container, use the container’s IP or expose the port via the template.