I double this for vanilla Nginx.
I frankly see zero reason to use vanilla Nginx as a reverse proxy when there are so many, so much better, alternatives. Or for any other purpose, really, though there aren’t quite as many alternatives for the webserver function as for the RP function.
I can tell you at least one reason – if you already have experience with nginx and don’t wanna learn new fancy stuff. That was my case with swag (built on top of nginx). As I could understand how provided configs work.
And I’m not 100% sure about the “so many” and “so much better” part. At least what I saw within Traefik didn’t look much better at first glance (perhaps it would if I spent more than 20 minutes on it).
I’m no expert with Traefik, but two big advantages come to mind:
- It can get your Let’s Encrypt certs itself without any separate ACME client, and
- Dynamic configuration using Docker labels means you prepare one static config once, and set up any of the routes for your apps with those labels. IOW, Traefik configuration is pretty much fire-and-forget unless you need to add routes to destinations other than Docker containers.
Caddy? Big advantage there is that configuration is vastly simpler.[1] Here’s a complete Caddyfile to proxy one service:
{
acme_dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
sonarr.yourdomain.com {
reverse_proxy * sonarr:9696
}
That will get certs automatically via DNS validation with Cloudflare, redirect HTTP to HTTPS, implement a sensible modern TLS configuration, and handle the reverse proxy. Repeat the last block as needed for any other services. And I emphasize that this is the entire server configuration file.
It can support dynamic configuration using Docker labels as well via a third-party plugin, but as I don’t have experience with that I won’t discuss it further. ↩︎
1 Like
These two could be solved by swag. But I don’t think they are really big advantages in the first place. It’s like saying that proxmox is better than truenas just because it has more built-in dns providers for auto-issuing cert than truenas has.
And I, personally, don’t use dynamic configurations.
The biggest shame is that TrueNAS itself doesn’t support it! Besides route53, cloudflare and OVH. Ok, it has a “shell” profile… which is undocumented.
I, for one, ended up having a separate docker container with acme. And then deploy the issued cert to truenas manually…
Why?
Don’t want it in Python and prefer Go?
I went to look up the info on it and possible I had it backwards. There is a nginx certbot plugin that allows Certbot to configure the server on nginx for your domain. But I don’t remember setting up the cron job for renewal…
(possible there is more than one way to do this and I didn’t bookmark the procedure I used)
Are those scripts just for deploy of the issued cert?
If you installed certbot, it sets up either a cron job or a systemd timer to run renewal daily (or twice daily; I forget which).
Yes. Well, mine is a script and the other is a binary, but still, yes–their function is to deploy the cert to your NAS. Call them using whatever ACME client you’re using to get the cert (e.g., with acme.sh, you’d use the --reloadcmd flag to call it).
Edit: see also:
Just checked and it’s there. A new feature of a later version I guess. I had to set up the cron job myself the first time and had some issues with it not working properly so I was having to manually rerun the renewal every few months until I figured it out.
Then there are no pros of these scripts, as the acme.sh itself can deploy the cert to truenas. When I said “manually”, I meant that I have to run acme deploy by hand.
With acme, you can issue a cert and then deploy it. With those scripts you can only deploy. And I believe acme.sh has better maintainability. Don’t wanna devalue your hard work, but that’s how I see it.
And frankly speaking, truenas should have more than 3 providers. Or at least have documentation for the “shell” profile.
Sure. If it’s running on the NAS itself.
Again, why? acme.sh --deploy -d whatever --deployhook truenas should result in that deploy-hook being run automatically whenever the cert is renewed. If it doesn’t, well, acme.sh is broken, and my script can be called as reloadcmd which will run automatically.
Again, one script and one binary. But correct, that’s what they do. They’re independent of any particular ACME client, and can run on any system with access to the TrueNAS host–which the truenas_ws deploy hook can’t. The truenas deploy hook can, but it requires the REST API, which is deprecated with 25.04.
I think its list of open issues and open PRs suggests otherwise. As does the fact that the truenas_ws deploy hook is completely undocumented.
Obviously, do whatever you think works better for you. But if you’re having to take manual action to deploy your cert, I seriously believe you’re doing something wrong.
Agreed.
Nope, my is running fine on a separate machine.
acme.sh --insecure --deploy --debug 2 -d "${DEPLOY_TRUENAS_HOSTNAME}" --deploy-hook truenas does the trick.
Yoinked it here.
Will take a look on the next renewal.
My gosh!
Another approach to exposing a service which has not been contemplated is to use a reverse proxy on the router.
This may make sense when the router is OPNsense or pfSense. In this case I use HAproxy.
You can even use a double reverse proxy… ie one on the router and one on the nas.
If forwarding web ports to your nas from the wan, id forward them to 81/444 or some other ports and use an RP config which ONLY maps those external services. Internal+external services can then be accessed via the regular ports
1 Like
Caddy is also available on OPNsense and IMO is much easier to set up than HAProxy.
…which is what I’m doing for Fester’s Guide and a few other things.
pff… sense. I have once made it with a 10-year-old Asus router 
. With the provided free certificate for the asuscomm ddns domain. But IMO this solution (and RP on the router in general) is not very versatile. I think RP should be as close as possible to the service.
And I don’t understand what the profit of double RP…
It means that local traffic can bypass the router.
In addition to Stux’ answer, it lets me forward some stuff from outside, and leave other services LAN-only, but still TLS-encrypted and on standard ports.
1 Like
Well, of course. But why do you need RP on router then?