Now we have a service that listens to port 19200 and tunnels traffic to Elastic Cloud, while making sure the traffic is encrypted and that the certificate is valid.
However, if you try to send HTTP requests to
http://localhost:19200, no information is forwarded about what cluster requests must be routed to.
Typically, endpoints are on the form
[cluster id]-[region].foundcluster.com. The hostname is what specifies what cluster requests will be routed to.
A compatible hostname must be sent to Elastic Cloud, but we still want to connect to
To do this, we can use ip.es.io. By connecting to
http://7893883873a705aec69e2942901f20d7b1e28dec-us-east-18.104.22.168.1.ip.es.io, the hostname will resolve to
127.0.0.1 and the hostname with the cluster id will be sent to Elastic Cloud.
Elastic Cloud then has sufficient information to route requests to your cluster.
While this hostname is not matching that of the SSL certificate (which matches *.foundcluster.com), it is stunnel that is terminating the SSL-connection. stunnel knows nothing about HTTP, and the client connecting to 19200 is completely unaware that traffic is being tunneled through SSL.
Note that stunnel will establish a new SSL-connection for every client that connects to it. It is important to use persistent connections, even though you are connecting to localhost. If not, you will be spending a lot of time establishing SSL-connections!