How Takelan Omnigate relays work

A short tour of the parts that carry a visitor's request to your machine and back.

The path of a request

A visitor opens your public name, for example shop.example.net.
The request reaches the edge, the public front door. The edge ends TLS, applies the tunnel's access rules and writes the request log.
The edge hands the request to the relay that your tunnel is attached to.
The client on your machine holds an outbound connection to that relay and passes the request to your app, for example localhost:3000.
The answer travels back the same way.

The numbers match the steps above. The tunnel is opened from your computer, so your network never has to accept a connection from the internet.

Because the client connects out, you do not open a port or change your router.

The parts

Client: tlomnigate, the program you run next to your app. It also shares folders as read-only sites.
Edge: The public front door for web tunnels and the dashboard: TLS, HTTP/1.1, HTTP/2, HTTP/3, WebSocket, access rules, visitor passwords and an optional cache.
Relay: Carries raw TCP and UDP tunnels, and the connections from clients (QUIC, with a TCP fallback for networks that block UDP).
Satellite: A relay in another place. First-party satellites add regions; a private relay is a satellite that you run yourself.
Control plane: The API and dashboard. It issues names and certificates, writes the edge's configuration and keeps the audit log.

Regions and the closest relay

Tunnels can be served from more than one relay. A client attaches to the relay with the lowest round-trip time, and where regional DNS is switched on, visitors are steered to the region closest to them. The dashboard shows where the relays are and which one a tunnel uses.

Where several relays serve a tunnel, visitors are steered to the closest region and your client attaches to the relay with the lowest round-trip time.

A tunnel can also allow a direct path, an opt-in setting that lets visitors connect straight to your machine when it has a public address.

Where TLS ends

On Takelan relays, the edge ends TLS with a certificate for your tunnel's name. Takelan manages and renews the certificates.
On a private relay, TLS is not ended by Takelan. The relay on your server ends it with a certificate for your tunnel's name, and the private key stays on that server. See private relays.

Tunnel types

Type	Use it for	How visitors connect
HTTP	Web apps, APIs, webhooks, file sharing	A public HTTPS name, with HTTP/1.1, HTTP/2 or HTTP/3 and WebSocket
TCP	Databases, SSH, game servers, anything over TCP	A public port on the relay
UDP	DNS, VPN, game traffic, anything over UDP	A public port on the relay

Some ports that are widely abused, e-mail first, are blocked for everyone. See features for what you can control per tunnel.