Skip to main content
A tunnel has two sides. Within the user’s network it is a process. Within Telnyx it is the next hop of a route on a Network, or the target of a private service Preview or a public hostname Preview. The examples on this page run on the Quick Start setup.

From the User’s Network

A Process on One Host

The tunnel process holds a long-lived TLS connection that it opened to Telnyx. An inbound connection would need a public address, a port forward on the router, and a firewall rule. An outbound connection needs none of them, because networks already let hosts open outbound connections. The router and the firewall stay as they are. The tunnel host has only private addresses, and its one connection to Telnyx is one it opened:
Tunnel host
Output
The one established connection is the tunnel’s. The router forwards no port to the tunnel host.

No Root

The tunnel process runs as a normal user. It creates no interface and changes no route, so it needs no administrator rights on the host:
Tunnel host
Output

Streams on That Connection

The process sends its token as soon as it connects, and Telnyx confirms the token on the first stream of the connection. Telnyx then opens one more stream for each flow, and each stream opens with a connect request that names the destination. Connections follows one flow through every step.

A Client Like Any Other

The process dials each destination as any program on its host would, and copies bytes between the stream and that connection until the flow ends. On the web service, a request that curl makes on a tunnel host and requests from the function look the same:
Tunnel host
10.20.3.7 access log
The first line is the curl on dc1-tunnel-a. The other two are function requests, which arrived from dc1-tunnel-a and dc1-tunnel-b.

From the Network

The Next Hop of a Route

A route that names a tunnel hands each flow in its CIDR to the tunnel process. The route list shows the tunnel as the next hop for 10.20.0.0/16:
Workstation
Output

Telnyx Terminates the Client’s Connection

Telnyx terminates the client’s connection itself and opens a stream to the process for it. When the destination refuses, the process reports the refusal and Telnyx resets the client’s connection. A request to a closed port shows it:
Function
The fetch rejects with TypeError: fetch failed, and its cause is ECONNRESET. Run with -v, the tunnel process that received the connect request logs the refusal:
Tunnel host
Connections follows one request through every step.