Best proxy for a simple task?

I hope this question is not too dumb or has been answered before. I have searched the web and did a search on the forums, and didn't find what I was looking for.

What I am trying to do is set up, basically, a reverse proxy for webzfs. Webzfs listens on http://127.0.0.1:26619. So what I would like to do is to set up a proxy so that I can pull up webzfs from another host, as well as providing https access. apache is way too much for what I need, and it appears that nginx is as well... Other things I have seen are all load balancers (e.g. haproxy, and relayd) or the newer ones seem to all be vibe coded as far as I can tell.

Is there one that will just allow me to, as simply as possible, stick a certificate between my webzfs install, and redirect from https://hostname.domain/webzfs to http://127.0.0.1:26619 from a remote host?

The goal of this exercise is, eventually, I am looking at testing using webzfs to manage the ZFS pools and datasets on a NAS, and replacing TrueNAS Core. I can set up an ssh tunnel to get to port 26619, however, I would rather splat down certificates and an https reverse proxy on each host, and be able to access each one via normal https link...
 
in our experience caddy is "simple" up until you try and, like, troubleshoot it or fix a problem, at which point you're hosed.
That was my experience. It gave up trying to get it to give me https because I'm behind a NAT, which meant that none of the automatic features for that would kick in. I wanted it badly to work, but it wasn't able to do the one thing I would have needed and it didn't have any obvious way of working around that, even for just local use.

In the end it was easier just to setup haproxy with my own certs, which was still less than ideal as none of the browsers I've tried are willing to trust me that the keys that I tell it to use are legitimate resulting in a bunch of unnecessary warnings about signing keys that I've already told the browser are official for my servers.

EDIT: Personally, I didn't find haproxy that hard to use, although it did take a bit to get it to redirect to a different subnet so that my main subnet wasn't so cluttered up.
 
Interesting that we have such different experiences with the same product. I use caddy across the board with DNS validated certificates, so no port forwards, and it’s always just worked. I tried Haproxy but found it very complicated where caddy was simple……….

Oh well, I guess nginx proxy manager might be another option.
 
Interesting that we have such different experiences with the same product. I use caddy across the board with DNS validated certificates, so no port forwards, and it’s always just worked. I tried Haproxy but found it very complicated where caddy was simple……….

Oh well, I guess nginx proxy manager might be another option.
I don't want to put anybody off of caddy, it's just that the simplicity when it works comes at the cost of being a right pain in the rear if your environment is too different from what they intended. And, I was never able to work out what the specific issue was that was leading caddy to not even really try to give me the SSL I needed.

It wound up being easier to just follow one of the excellent tutorials on YouTube I've found and create my own local CA and generate my own certs. But, as always YMMV, and I do believe that caddy is a good place to start because when it works it works quite well. I just wouldn't personally waste a ton of time troubleshooting it as at that point, you're probably better off just switching to something more powerful anyways. It's not like HAProxy is that hard to set up. I only had challenges there because I was trying to do too many different things all at once rather than iteratively adding factors.
 
That was my experience. It gave up trying to get it to give me https because I'm behind a NAT, which meant that none of the automatic features for that would kick in. I wanted it badly to work, but it wasn't able to do the one thing I would have needed and it didn't have any obvious way of working around that, even for just local use.

In the end it was easier just to setup haproxy with my own certs, which was still less than ideal as none of the browsers I've tried are willing to trust me that the keys that I tell it to use are legitimate resulting in a bunch of unnecessary warnings about signing keys that I've already told the browser are official for my servers.

EDIT: Personally, I didn't find haproxy that hard to use, although it did take a bit to get it to redirect to a different subnet so that my main subnet wasn't so cluttered up.
Interesting. What I am looking for is for internal use only, behind a NAT. For instance, I would like to be able to access the webzfs webserver listening on localhost on port 26619 and exposing it to hosts on the local LAN via https. I want to replace having to set up individual ssh tunnels with the ability to hit an https page on individual servers.
 
Interesting. What I am looking for is for internal use only, behind a NAT. For instance, I would like to be able to access the webzfs webserver listening on localhost on port 26619 and exposing it to hosts on the local LAN via https. I want to replace having to set up individual ssh tunnels with the ability to hit an https page on individual servers.
Once you're too the machine on which the service is running, there's not much point in encrypting the bit after it hits the ethernet card as if they've managed to get that last bit, they've already compromised things enough that securing the bit inside is probably also compromised.

Something along the lines of the following should work in the haproxy.conf should work, I don't think the other sections needed modification, but YMMV. Or at least it does for me, I haven't done this in a while. It likely will need some tweaking for your specific situation. You just have to combine the fullchain and the private key into the pem_file.pem as such: cat fullchain.pem privkey.pem > haproxy.pem

Code:
frontend server_ssl
    bind :443 ssl crt /path/to/pem_file.pem
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    option forwardfor
    default_backend server
    
backend server
    server server <ENTER_IP:PORT_HERE> check

But, if caddy does work for you, it's probably a bit easier than this is.
 
I use caddy as well, both public as internally. Internally I combine it with my internal PKI (CA) setup using step-ca. Point caddy to it and caddy takes care of the SSL/TLS certificates, all automagically! No manual SSL/TLS certificate creation whatsoever.
 
oh man. we haven't run apache2 in a looooong time. i think we ended up concluding that it's a special-purpose tool for if you have something that requires an apache-specific module, which we haven't had in a long time.
 
I use apache2 for this and find it pretty lightweight.
apache2 has always seemed to fall into the "there's no kill like overkill" category. You can do anything with it, if you can figure out how to get through the "maze of twisty little passages, all alike." Maybe it is that my brain just doesn't grok web stuff.
 
apache2 has always seemed to fall into the "there's no kill like overkill" category. You can do anything with it, if you can figure out how to get through the "maze of twisty little passages, all alike." Maybe it is that my brain just doesn't grok web stuff.

Well, I've been running apache since its beginning.

But to the best of my memory I didn't have to do any wizardry to plug in letsencrypt for TLS and then configure the reverse proxy, with password on apache level, to access the internal non-tls webserver.
 
Well, I've been running apache since its beginning.

But to the best of my memory I didn't have to do any wizardry to plug in letsencrypt for TLS and then configure the reverse proxy, with password on apache level, to access the internal non-tls webserver.
TBH, I have been using easy-rsa and maintaining my own PKI infrastructure since it first came out. Never had a need for letsencrypt, since most things on my homelab are internal only.

You just have to combine the fullchain and the private key into the pem_file.pem as such: cat fullchain.pem privkey.pem > haproxy.pem
And as I recall, fullchain.pem is cat hostcert.crt ca.crt >> fullchain.pem, correct? Can't remember the order.
 
Back
Top