On 2023-10-10, Courtney <courtney@courtnix.systems> wrote: > Maybe I am wrong, but I thought that relayd was not capable of doing > TLS pass through? That would be preferable if it is possible.
If you do TLS passthrough (i.e. passing packets directly to the origin rather than doing "back to back" and terminating one TLS connection and making a second one) then the renewed certs need to be copied on to the backend machines, which was a thing you were asking about avoiding. Obviously you don't have access to HTTP headers at that point so you can't inspect Host, but you can look at SNI from the TLS ClientHello. (encrypted SNI doesn't matter much here - a small server will be sufficiently identifiable from the IP address alone so there's little benefit in using eSNI, so you can simply not configure tge server to use it). If you *do* want that, sniproxy is made for doing just that, so should be simple to configure, but it's also possible with at least haproxy and nginx. https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Passing the client's source IP through to the origin server can be a bit fiddly with this method. haproxy has a proxy protocol which can be used to pass it through but the origin server needs to understand it. It can also be done by essentially 'spoofing' the original client IP for the TCP connection to the origin - which works with any origin server software, but the proxy needs to be on a machine on the normal network path between the client and origin. (For a normal "back to back" proxy with two separate TLS connections, for https this would normally be done by adding X-Forwarded-For or similar header). relayd can definitely pass a TCP connection to a different backend based on IP address or port. There should probably be a way to use https Host headers as part of the decision by doing back-to-back TLS connections though like everything with relayd filters it will probably require hitting your head against a wall repeatedly before getting it to work ;) I don't _think_ there's any way to use SNI to make that decision in relayd. > > > On 10/9/23 00:42, Kapetanakis Giannis wrote: >> On 08/10/2023 04:00, Courtney wrote: >>> Ultimately, I want to serve a handful of services on 80/443 that are >>> easily accessible internally and externally, and I don't want to have >>> unencrypted traffic between relayd and my server for the services that >>> are passing sessions and such. >> >> Then don't terminate the connection on relayd. Use redirect instead of a >> relay and terminate on the web server itself. >> >> It will also be a little faster since the router/relayd will only route/pass >> the packets to the appropriate backend server. >> >> For internal traffic you have to use appropriate DNS (local IP) and maybe a >> different certificate. >> >> G >> > > -- Please keep replies on the mailing list.
