What is http://teleport.cluster.local EOF error?

Ported from community slack

Where does the address teleport.cluster.local comes from? I never supplied it in the configuration

INFO [PROC:1]    Proxy failed attempt connecting to auth server: Get https://teleport.cluster.local/v2/authorities/host/grv8-teleport?load_keys=false: EOF

This is a confusing error message on Teleport’s part that we are going to improve. Internally, teleport sets up addressing and naming convention that uses teleport.cluster.local to dial auth server by this constant name regardless of the real IP/DNS name that is taken from the configuration.

This is done to make sure that X509 TLS certificates will verify when clients connect to servers regardless of the real IP/DNS name address.

We are going to improve the error messaging, but meanwhile just ignore this value. Most likely the real IP/DNS name is not accessible.

Auth server is a simple HTTPS server, one can check connectivity using curl -k command:

curl -k https://<auth-server-ip-or-dns>:<port>

If available, users will get 404 response instead of timeout.

This appears to be an actual error with the k8s deployment.

-> % curl -k https://auth-env-1.test.example.com:3025
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

WARN [AUTH:1]    Client sent unsupported cluster name "auth-env-1.test.example.com", what resulted in error unrecognized name, expected suffix teleport.cluster.local, got "auth-env-1.test.example.com". logrus/entry.go:188
2019-10-07 16:29:45.447064 I | http: TLS handshake error from access is denied

I am on the same boat than drewwells.

In teleport I only have the teleport daemon (auth, proxy, and node) connected to Kubernetes, and all the other nodes are unable to join the teleport cluster due to the error drewwells shown.

I had this error when fronting Teleport with a TLS-terminating load balancer (Istio in my case). I switched over TLS negotiation to Teleport directly and that fixed the issue. Given the lack of ability to route based on SNI, this has meant that instead of using the standard port (443) for https, I’ve now exposed the Teleport ports directly - which is the default behaviour anyway.

1 Like

As @lw346 has helpfully pointed out, this error is often caused when a load balancer in front of Teleport terminates TLS or attempts to intercept/redirect traffic. In AWS this can often be due to use of an ALB where an NLB would be more appropriate. In Kubernetes this could be due to an Ingress or similar.