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
Thanks, I need to pass the ip information when running in tcp, how would I do it?
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.
@hphillips @Loni If it helps your team to understand why this should be prioritized and why DO recently launched support for this:
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
@lunaru: If you use Let's Encrypt, you could use Linode's API to automatically swap the cert/key programmatically. This article shows an example of doing just that.
@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.)
I'm new to this discussion. Basically I have a Linode with traffic that has grown. I can mirror the Linodes, but I need to put them behind a node balancer.
The Linode is using https connections and I just want to know the easiest way to deal with this in the node balancer setup. Should I remove SSL connections from my nodes and give the cert for my domain to the node balancer and let it communicate with my domains in plain text?
Should I attempt to get certs for each of my nodes? I haven't the faintest idea of how to get authenticated certs for my nodes, but I can created self-signed certs if the node balancer doesn't complain.
What is simplest?
Which solution is simplest depends on your application or systems requirements.
For example, if you would like to quickly scale your back-end nodes to keep up with demand and do not want to go through the process of creating certificates for each backend, you can terminate the HTTPS connection at your NodeBalancer. Communication with the backend Linodes will not be encrypted in flight, but all communication with backends is done over the private network and you can set up firewall rules to immediately drop all other connections. That may be the simplest option.
If you are okay with generating SSL/TLS certs for you backend nodes or you are programmatically generating them using a service like Let's Encrypt, you can just use your NodeBalancer as a method of simply balancing connections to your backends.
We have a couple of great articles that go in-depth about the pros, cons, and use cases for each of the setups here:
Getting Started with NodeBalancers
NodeBalancer Reference Guide
Using linode nodebalancers are a non-starter for anyone that needs to make sure they maintain their site up on both IPv4/6, iptrasfer only seems to allow IPv4 not IPv6.
With all the big cloud providers supporting PROXY protocol its a big problem that Linode does not.
Thanks for calling that out @cmg. For anyone following along, we just published a guide on how to use that new functionality: