Skip to main content
A function on the Network acme-prod connects to 10.20.3.7:8080, an address that a route sends to the tunnel chicago-dc. The diagram follows that one request:
  1. The tunnel process opens an outbound TLS connection to Telnyx and sends its token. Telnyx checks the token and confirms on the first stream of the connection. The process then waits. It opens nothing else toward Telnyx.
  2. The function opens TCP connection A to 10.20.3.7:8080. The route on acme-prod brings A to Telnyx, which terminates it.
  3. Telnyx opens a new stream on the connection of one tunnel process and sends a connect request. The request names the protocol, the destination address and port, the Network, and the client’s address. It is a message on a stream, not a packet. Nothing is encapsulated, and no route is exchanged.
  4. The process dials 10.20.3.7:8080 from its own host. Connection B is an ordinary connection from the tunnel host, so the destination needs no route to Telnyx and sees the tunnel host as the source.
  5. The process answers ok, or refuses. A refusal resets A, and the function’s request fails with a reset connection.
  6. Bytes then flow across A, the stream, and B until either side closes.
A and B are network connections. The stream between them relays bytes and is not a connection to anything. No packet from the function crosses the tunnel. For the same reason, hosts behind the tunnel cannot start connections through it, and a stream that the tunnel process opens toward Telnyx goes nowhere. The process stores no configuration. Routes, private services Preview, and public hostnames Preview live in Telnyx, and Telnyx asks the process to dial only the destinations that they declare.

​
One Connect Request per Flow

Each flow reaches a tunnel process as its own connect request, which names one destination. The process dials that destination and nothing else. Each flow is placed on its own as well. With two tunnel processes connected, three requests from the function reach the web service as three connections, from the two tunnel hosts in turn:
10.20.3.7 access log
By default the tunnel process logs nothing for a flow. With -v, it logs each flow that it relays, and each destination that refuses a connection:
Tunnel host
Output