Tunnels — using the connectors, step by step

This guide assumes your Tunnel is deployed and online — if the Tunnels list doesn’t show a green dot yet, start with the Quickstart. Everything below happens in Conduit; nothing more is installed on the Tunnel host.

There are two different ways a Tunnel carries traffic, with two different setup surfaces:

You want	Where you set it up	Guide
A built-in connector running next to the system (read-only SQL, a local MCP server, an echo test)	The tunnel’s detail page — Connections → Tunnels → your tunnel → Add connection	this page
A cloud vendor (e.g. ConnectWise PSA) whose server lives on your network	The vendor’s connect form — Connections → Catalog → the vendor → Connect	On-prem vendors via Tunnel

Step 0 — open the tunnel’s page

Connections → Tunnels lists every tunnel your org has registered with its live status. Click into your tunnel and press Add connection. The modal lists the built-ins; ticking one reveals its fields. Config you save here is encrypted at rest in Conduit and pushed down the tunnel — the Tunnel holds it in memory only and re-receives it automatically after a restart.

Echo — prove the round-trip first

Always start here on a fresh deploy: it has no fields and no external dependencies, so it isolates “is the tunnel path working” from “is my database reachable”.

1. Tick Echo, press Save & push.
2. Watch the tunnel host’s logs (sudo journalctl -u conduit-tunnel -f) for config applied including echo.
3. Grant access to echo for whoever will test.
4. From any MCP client connected to Conduit, call the echo__echo tool. The text you send comes back through the tunnel.

When that works, the whole chain — client → Conduit → relay → WSS tunnel → connector — is proven. Untick Echo and save again when you’re done; it has no business value beyond the test.

SQL Server (mssql)

Read-only queries against a Microsoft SQL Server database (see the SQL Server guide for the full walkthrough, including creating the scoped login).

1. Tick SQL Server. Fill in:
   • Host / Port — the database server’s address on your network (e.g. 10.0.0.5, port 1433).
   • Database — the target database name.
   • Read-only login / Password — a SQL principal scoped to SELECT on exactly the tables you intend to expose. The password is encrypted at rest in Conduit and never written to disk on the Tunnel host.
   • Require TLS to SQL Server — leave checked unless it’s a lab database with no TLS at all. A self-signed SQL certificate must be trusted on the Tunnel host for this to pass.
2. Windows Integrated Auth (gMSA) — tick this instead of entering a login/password to authenticate as the Tunnel’s own Windows service identity. Requires a Windows host whose service was installed with install.ps1 -ServiceAccount 'DOMAIN\gmsa$'. With a gMSA there is no stored SQL credential anywhere — not in Conduit, not on the host.
3. Save & push, watch for config applied, then grant access to mssql.
4. Verify with the connector’s own tools: mssql__list_tables, then a mssql__query with a simple SELECT. Writes and multi-statement batches are refused by design — see the reference for the tool contract and row caps.

PostgreSQL (postgres)

Same shape as SQL Server: host/port/database, a scoped read-only role, and a TLS toggle (Require TLS to PostgreSQL). Same three tools (query / list_tables / describe_table), same read-only guarantees. Save & push → config applied → grant access to postgres → verify with postgres__list_tables.

Generic MCP server (mcp-proxy)

Fronts any MCP server that can run on the Tunnel host — for example the Veeam MCP server — without that server needing to know Conduit exists. The Tunnel launches it as a child process and forwards its tools over the tunnel.

1. Tick Generic MCP server. Fill in:
   • Command — the executable (e.g. node).
   • Arguments — space-separated (e.g. /opt/veeam-mcp/build/index.js).
   • Working directory — optional.
   • Environment — KEY=VALUE, one per line. This is where that server’s own credentials go — they’re encrypted in Conduit, pushed over the tunnel, and handed to the child process’s environment only.
2. The command runs as the Tunnel’s own unprivileged service identity (DynamicUser on Linux), so the host binary must be executable by an arbitrary uid — a system-wide install like /opt/... works; a home directory usually doesn’t.
3. Save & push → config applied → grant access → the child server’s tools appear under the connector’s slug (e.g. mcp-proxy__list_backups).

To run more than one local MCP server, see named instances.

Granting access

Connector tools go through exactly the same access-grant enforcement as every cloud vendor — a tunnel changes where requests exit, never who may make them. A freshly enabled connector is callable by no one until the org grants it, and calls fail with one of:

You do not have access to <connector> in this organization.

Tool "<name>" requires a higher access tier than your grants permit.

Fix both from the org’s access editor (Access in the sidebar): grant the connector’s slug (echo, mssql, postgres, mcp-proxy, or your named instance’s slug) to the members or teams who need it, at a tier that covers the tools they’ll call. Read-only SQL tools sit in the read tier; unclassified tools of a proxied MCP server fail closed to the admin tier — deliberately — so grant accordingly or classify them.

Lifecycle notes

• Push is confirmed, not fire-and-forget. The tunnel page shows what the Tunnel actually ACKed. applied listing your connector = live.
• Restarts self-heal. The Tunnel holds config in memory only; after a restart it re-registers empty and Conduit re-pushes within ~60 s.
• Removing a connector is the same modal — untick and Save & push.
• Credentials rotate in Conduit, not on the host: edit the field, save, and the new value is pushed down the tunnel.