Fork me on GitHub

Teleport

Networking

Improve

Public address

All Teleport services (e.g., the Proxy Service, Auth Service, and Nodes) have an optional public_addr property that you can modify in each service's configuration file. The public address can take an IP or a DNS name. It can also be a list of values:

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

Specifying a public address for a Teleport service may be useful in the following use cases:

  • You have multiple identical services, e.g., Proxy Service instances, behind a load balancer.
  • You want Teleport to issue an SSH certificate for the service with additional principals, e.g., host names.

All Teleport services (e.g., the Application Service and Database Service) have an optional public_addr property that you can modify in each service's configuration file. The public address can take an IP or a DNS name. It can also be a list of values:

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

Specifying a public address for a Teleport Node may be useful in the following use cases:

  • You have multiple identical services behind a load balancer.
  • You want Teleport to issue an SSH certificate for the service with additional principals, e.g., host names.

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 .

Note

localhost and 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.

Note

The proxy service also respects HTTPS_PROXY and HTTP_PROXY when connecting to a local kubernetes cluster, which may not work. To fix this, add kube.teleport.cluster.local to NO_PROXY.

Ports

Teleport services listen on several ports. This table shows the default port numbers for each service.

Note

To get a listing of the assigned ports for an instance of the Teleport Proxy Service, use the following command:

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

Note that if auth_service.proxy_listener_mode is set to multiplex in your Teleport configuration, that means only a single port is used for multiple services through the Proxy.

Ports with TLS routing

TLS routing is enabled by default. In this mode, all connections to a Teleport service (e.g., the Teleport SSH Service or Kubernetes) are routed through the Proxy Service's public web address.

Read more in our TLS Routing guide.

PortServiceDescription
443ProxyIn TLS Routing mode, the Proxy handles all protocols, including Web UI, HTTPS, Kubernetes, SSH, and all databases on a single port.
3021ProxyPort used by Teleport Proxy Service instances to dial agents in Proxy Peering mode.
3022NodeSSH port. This is Teleport's equivalent of port #22 for SSH. Only used when Teleport Node is replacing SSH.
3025AuthTLS port used by the Auth Service to serve its API to other Nodes in a cluster.
3028DesktopWhen using Desktop Service windows_desktop_service.listen_addr

Ports without TLS routing

In some cases, administrators may want to use separate ports for different services. In those cases, they can set up separate listeners in the config file.

PortServiceDescription
3021ProxyPort used by Teleport Proxy Service instances to dial agents in Proxy Peering mode.
3022NodeSSH port. This is Teleport's equivalent of port #22 for SSH.
3023ProxySSH port clients connect to. The Proxy Service will forward this connection to port #3022 on the destination Node.
3024ProxySSH port used to create "reverse SSH tunnels" from behind-firewall environments into a trusted proxy server.
3025AuthTLS port used by the Auth Service to serve its API to other Nodes in a cluster.
3080 or 443ProxyHTTPS connection to authenticate tsh users into the cluster. The same connection is used to serve a Web UI.
3026KubernetesHTTPS Kubernetes proxy proxy_service.kube_listen_addr
3027KubernetesKubernetes Service kubernetes_service.listen_addr
3028DesktopDesktop Service windows_desktop_service.listen_addr
3036MySQLMySQL port proxy_service.mysql_addr

Teleport Cloud allocates a different set of ports to each tenant. To see which ports are available for your Teleport Cloud tenant, run a command similar to the following, replacing mytenant.teleport.sh with your tenant domain:

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

The output should resemble the following, including the unique ports assigned to your tenant:

{
  "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
}

This output also indicates whether TLS routing is enabled for your tenant. When TLS routing is enabled, connections to a Teleport service (e.g., the Teleport SSH Service) are routed through the Proxy Service's public web address, rather than through a port allocated to that service.

In this case, you can see that TLS routing is enabled, and that the Proxy Service's public web address (ssh.public_addr) is mytenant.teleport.sh:443.

Read more in our TLS Routing guide.