Networking

Public address

public_addr: ["proxy-one.example.com", "proxy-two.example.com"]

public_addr: ["service-one.example.com", "service-two.example.com"]

HTTP CONNECT proxies

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:

• tsh in 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 HTTPS_PROXY and HTTP_PROXY environment variables when running Teleport. You can also optionally set the NO_PROXY environment variable to avoid use of the proxy when accessing specified hosts/netmasks/ports.

For example, when launching Teleport with systemd, you can add the following lines to your systemd unit file, replacing proxy.example.com with the address of your proxy.

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080/"
Environment="HTTPS_PROXY=http://proxy.example.com:8080/"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.0.0/16,172.16.0.0/12,10.0.0.0/8"

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 host:port format:

[Service]
Environment="HTTP_PROXY=http://httpproxy.example.com:8080/"
Environment="HTTPS_PROXY=http://httpproxy.example.com:8080/"
Environment="NO_PROXY=teleportproxy.example.com:3024"

The value of HTTPS_PROXY or HTTP_PROXY should be in the format scheme://[user[:password]@]host:port where scheme is either https or http . If the value is host:port , Teleport will prepend http .

Ports

This section describes the ports you should open on your Teleport instances.

curl https://teleport.example.com:443/webapi/ping | jq

curl https://mytenant.teleport.sh/webapi/ping | jq '.proxy'

{
  "kube": {
    "enabled": true,
    "public_addr": "mytenant.teleport.sh:11107",
    "listen_addr": "0.0.0.0:3026"
  },
  "ssh": {
    "listen_addr": "[::]:3023",
    "tunnel_listen_addr": "0.0.0.0:3024",
    "public_addr": "mytenant.teleport.sh:443",
    "ssh_public_addr": "mytenant.teleport.sh:11105",
    "ssh_tunnel_public_addr": "mytenant.teleport.sh:11106"
  },
  "db": {
    "postgres_public_addr": "mytenant.teleport.sh:11109",
    "mysql_listen_addr": "0.0.0.0:3036",
    "mysql_public_addr": "mytenant.teleport.sh:11108"
  },
  "tls_routing_enabled": true
}

Agent ports

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.

The table below describes the ports that each Teleport Service opens for proxied traffic:

Applications registered with the Teleport Application Service can only be accessed via the Teleport Proxy Service, not directly via the Application Service.