- Available for:
Some networks funnel all connections through a proxy server where they can be audited and access control rules can be applied. For these scenarios, Teleport supports HTTP CONNECT tunneling. HTTP CONNECT applies to:
tshin all cases.
- Teleport services, such as the SSH Service and Database Service, that dial back to the Teleport Proxy Service.
To use HTTP CONNECT tunneling, set the
environment variables when running Teleport. You can also optionally set the
NO_PROXY environment variable to avoid use of the proxy when accessing
By default, Teleport installations based on package managers (such as
yum) configure The
teleport systemd unit to read environment variables from
To configure HTTP CONNECT tunneling, you can assign these environment variables
/etc/default/teleport on machines that run Teleport binaries. Use the
following example, replacing
proxy.example.com with the address of your proxy:
When Teleport builds and establishes the reverse tunnel to the main cluster, it will funnel all traffic through the proxy. Specifically, if using the default configuration, Teleport will tunnel ports
3024 (SSH, reverse tunnel) and
3080 (HTTPS, establishing trust) through the proxy.
If you don't want to proxy some of this traffic (for example, proxying HTTPS but not SSH), assign
NO_PROXY to the address of the Teleport Proxy Service endpoint you want to exclude from HTTP_CONNECT tunneling in
For example, you can modify the environment file at
each machine that runs a Teleport binary to resemble the following:
The value of
HTTP_PROXY should be in the format
scheme://[user[:password]@]host:port where scheme is either
http . If the value is
host:port , Teleport will prepend
127.0.0.1 are invalid values for the proxy host. If for some reason your proxy runs locally, you'll need to provide some other DNS name or a private IP address for it.
The proxy service also respects
HTTP_PROXY when connecting to a local kubernetes cluster, which may not work. To fix this, add
This section describes the ports you should open on your Teleport instances.
Teleport agents dial the Teleport Proxy Service to establish a reverse tunnel. Client traffic flows via the Proxy Service to the agent, and the agent forwards traffic to resources in your infrastructure.
As a result, for Teleport processes running agents, e.g., instances of the SSH Service, Kubernetes Service, and other services that protect resources in your infrastructure, there is no need to open ports on the machines running the agents to the public internet.
Some Teleport services listen for traffic to one of their proxied resources, meaning that you can expose ports on that service's host directly to clients. This is useful when you need to connect to resources directly if the Proxy Service becomes unavailable.
In Teleport Cloud, the Auth and Proxy Services run in Teleport-owned infrastructure. For this reason, Teleport Cloud customers must connect their resources via reverse tunnels. Exposing ports for direct dial is only supported in self-hosted deployments.
The table below describes the ports that each Teleport Service opens for proxied traffic:
|Incoming SSH connections.
|HTTPS traffic to a Kubernetes API server.
|Windows Desktop Service
|Teleport Desktop Protocol traffic from Teleport clients.
You can only access enrolled applications and databases through the Teleport Proxy Service. The Teleport Application Service and Teleport Database Service use reverse tunnel connections through the Teleport Proxy Service and cannot expose ports directly.