How do I configure my NodeBalancer to pass through SSL connections to the back-end nodes?
I want my back-end nodes to process the SSL connection from my website visitors. What changes do I need to make to my NodeBalancer configuration?
You should just need to configure that port on your NodeBalancer to use the TCP protocol instead of HTTPS! This will cause the TCP connections to be passed to the back-end nodes instead of taking over as the HTTP/HTTPS session endpoint.
You can find more information on the NodeBalancers supported protocol settings on this helpful support article
The HTTPS protocol setting for the NodeBalancer is designed to pass the X-FORWARDED-FOR header to the backend, so it needs to terminate the HTTPS session in order for this to work. As you would like your backends to terminate the HTTPS session, you will need some other way to get the source IP to them.
The TCP protocol setting does not have a mechanism for passing the source IP address to the backend, so this turns out to be an either/or situation.
One could conceivably setup a hybrid solution where an HTTPS connection is used to establish the connection, acquire the X-FORWARDED-FOR header, associate the IP with a cookie, and then forward the client to a subdomain running through TCP mode, but this is quite a work around.
If you really need the backends to terminate the session and acquire the source IP, you may wish to consider setting up your own load balancing solution with software such as Neutrino, HAProxy, or nginx.
Additionally here are two guides that can help:
@hphillips are there plans for Linode to support transparent origin IPs without SSL Termination?
And on a more detailed level, are Linode Nodebalancers HAProxies? If so, why not support the "Proxy Protocol" to send the source IP to the backend nodes?
@hphillips Just wanted to follow up on Lunaru's question and see if there was an plans to support this?
I know it's been a bit since this question @lunaru and @jale but I just wanted to jump in and address this.
Integrating TCP proxy protocol with our NodeBalancers is something that's on our roadmap but we don't have an ETA for it yet.
The momentum of sites moving to SSL with Let's Encrypt is fairly strong. But with the way Let's Encrypt works, it's much better to handle dynamic cert generation and verification at the app layer where this is more context as to the allowability of a certain domain needing a cert. (e.g. some domains my app should allow, others shouldn't, for security reasons and this can change dynamically)
This means it no longer makes sense for modern apps to SSL-terminate at the load balancer level. This means the load balancer needs to be a dumb TCP connection with faithful reflection of the IP of the end user. This is the direction where standard practice is headed, particularly in Node apps.
EDIT: I also want to chime in and mention that your 10k connection limit is problematic as well, but that's a separate issue.
thank you for sharing the information about passing the ip information when running in tcp. it was quite helpful
@hphillips @Loni: TCP Proxy support would be good but being able to handle more than config/per port would be more useful IMO. This would allow multiple SSL domains to work on a single nodebalancer. (LE supports multiple domains on a single cert but for different websites that aren't related to each other/multiple clients that's a hairy workaround.)
I agree with [@Dave] (/community/user/Dave), if the NodeBalancers could support multiple SSL certs per port (using SNI) the source IP isn’t too much of an issue, as it could get passed to the backend in the HTTP headers.
I recently contacted support about this, and for my situation, currently I’d have to have 6 NBs ($60/mo) if I want to keep the client IPs, using SSL termination, one cert per NB.
With SNI I could easily handle all my traffic with just one ($10.)