Skip to main content
A tunnel carries flows from a Network to hosts behind it. It never joins the two networks. A VPN joins two networks, so that hosts on each side can send packets to the other, subject to firewalls. A tunnel carries only the flows that Telnyx hands it, and only to the destinations declared for it: The examples on this page run on the Quick Start setup.

​
From the User’s Network

Starting the tunnel process adds no interface and no route to the tunnel host. The host’s interfaces and routing table read the same before and after telnyx-edge tunnel run:
Tunnel host
Output

​
No Route Back to Telnyx

Hosts behind the tunnel need no route to Telnyx either. Every connection reaches them from the tunnel host, so their replies stay within the user’s network. The web service’s routing table holds only its own subnet and the site’s default route:
10.20.3.7
Output
A request from the function at the same moment returned 200, through the tunnel host 10.20.0.11.

​
No Listening Port

The tunnel opens no port within the user’s network, so there is nothing to scan or attack, from the internet or from the site’s other hosts. A scan of dc1-tunnel-a from dc1-tunnel-b, while both run the tunnel process, finds every port closed:
Another host
Output

​
No Way Into Telnyx

No host within the user’s network, the tunnel host included, can open a connection through the tunnel toward the Network. A WireGuard peer is a host on the Network. It sends packets for the function’s address, 172.27.0.2, into its WireGuard interface:
WireGuard peer
Output
A tunnel host is not on the Network. It sends packets for the same address to the site’s default gateway, where they lead nowhere:
Tunnel host
Output
Both answers were taken while the function reached 10.20.3.7 through the tunnel.

​
No Address of Its Own

The tunnel has no IP address. Only the tunnel host has one. On the Network, the route names the tunnel as its next hop, where an attachment’s route names the attachment:
Workstation
Output

​
From the Network

​
No IP Packets

The tunnel process re-originates each TCP connection. No packet from the Network crosses the tunnel, so routing protocols, other IP protocols, and multicast never reach the hosts behind it. A capture on the web service during two function requests shows two connections from the tunnel hosts, and no packet from the Network’s subnet:
10.20.3.7
Output
Each [S] line opens a connection from a tunnel host. None of the 26 packets comes from 172.27.0.0/24.

​
Not the Client’s Address

The destination sees the tunnel host, never the client’s address on the Network. The function is 172.27.0.2 on acme-prod, and the web service logs its request from the tunnel host 10.20.0.10:
10.20.3.7 access log
A firewall rule that admits the tunnel host therefore admits every flow through the tunnel.

​
Nothing That Is Not Declared

Telnyx asks the tunnel process to dial only the destinations declared for the tunnel. The tunnel host reaches 10.30.0.7:8080:
Tunnel host
Output
No route sends 10.30.0.0/24 to the tunnel, so the function cannot reach it:
Function
The fetch rejects with TypeError: fetch failed once its connect timeout passes. Telnyx never sends it to the tunnel, so neither tunnel process receives it.