Use case

Private TCP service tunneling

The problem

Not every Service is SSH, RDP, or HTTP. Redis, MySQL, message queues, and proprietary TCP protocols all need the same kind of scoped, temporary access as more common protocols.

Why traditional network access is excessive here

A general-purpose private network treats every TCP service the same way: reachable to anyone with network membership. That gives no more precision than the network boundary itself.

How TunnelCrib handles it

The TunnelCrib Agent can advertise any TCP port as a named Service, using the same registration, Agent-access policy, and Tunnel mechanism as the built-in ssh/rdp/winrm protocols.

Setup example

$ tunnelcrib connect broker-01:redis

device identity verified
direct Tunnel negotiated
Service Tunnel active
localhost:49318

$ redis-cli -p 49318

Authorization example

Each custom Service is authorized independently, the same way SSH or RDP would be — per Client, per Device, per Service.

User experience

The user points their existing client tool (a Redis CLI, a custom client, a database driver) at localhost:<port>; TunnelCrib carries the TCP stream without interpreting the protocol.

Audit trail

The connect request and session lifecycle are recorded the same way as any other Service (see audit events).

Security considerations

Because TunnelCrib only forwards TCP bytes, it does not validate or filter the protocol itself; Service-level authentication (e.g. a Redis password) remains the responsibility of the Service.