
Teleport
Networking
- Version 15.x
- Version 14.x
- Version 13.x
- Version 12.x
- Older Versions
- Available for:
- OpenSource
- Team
- Cloud
- Enterprise
Public address
All Teleport services (e.g., the Proxy Service, Auth Service, and agents) 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 agent 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
.
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.
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
This section describes the ports you should open on your Teleport instances.
Proxy Service ports
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.
Port | Downstream Service | Description |
---|---|---|
443 | Proxy Service | In TLS Routing mode, the Proxy handles all protocols, including Web UI, HTTPS, Kubernetes, SSH, and all databases on a single port. |
3021 | Proxy Service | Port used by Teleport Proxy Service instances to dial agents in Proxy Peering mode. |
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.
Port | Downstream Service | Description |
---|---|---|
3021 | Proxy Service | Port used by Teleport Proxy Service instances to dial agents in Proxy Peering mode. |
3023 | All clients | SSH port clients connect to. The Proxy Service will forward this connection to port 3022 on the destination service. |
3024 | Auth Service | SSH port used to create reverse SSH tunnels from behind-firewall environments into a trusted Proxy Service instance. |
3080 or 443 | Proxy Service | HTTPS connection to authenticate tsh users into the cluster. The same connection is used to serve a Web UI. |
Auth Service ports
Port | Downstream Service | Description |
---|---|---|
3025 | All Teleport services | TLS port used by the Auth Service to serve its gRPC API to other Teleport services in a cluster. |
Proxy Service ports
Cloud-hosted Teleport deployments allocate a different set of ports to each
tenant's Proxy Service. To see which ports are available for your Teleport
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.
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:
Port | Service | Traffic Type |
---|---|---|
3022 | SSH Service | Incoming SSH connections. |
3026 | Kubernetes Service | HTTPS traffic to a Kubernetes API server. |
3036 | Database Service | Traffic to MySQL databases. |
5432 | Database Service | Traffic to Postgres databases. |
27017 | Database Service | Traffic to MongoDB instances. |
6379 | Database Service | Traffic to Redis instances. |
3028 | Windows Desktop Service | Teleport Desktop Protocol traffic from Teleport clients. |
Applications registered with the Teleport Application Service can only be accessed via the Teleport Proxy Service, not directly via the Application Service.