Most apps on Truenas SCALE have a dropdown to select a self-signed or other certificate in the configuration settings, but NPM does not.
I created one in Credentials for my custom domain, and put it in the “certs” subfolder to my nginx dataset.
When I go to the LAN address:port for NGINX, it is http.
How do I get the NGinx Proxy Manager, installed as an “app” on TrueNAS SCALE, to use this certificate so I can access the LAN address with SSL?
There is no Nginx app; there’s an Nginx Proxy Manager app. And you have it generate its own cert, as described here:
Why do you need to change TrueNAS port to 444? It seems to work without doing that? I was having issues when I transferred domain registrars that resolved after about a week, but now I spent a bunch of time changing things that I did not need to change, including, apparently this truenas port change. Is there a reason this is necessary?
The reason to do that, as stated in that guide, is to allow NPM to listen on the standard web ports of 80/443. It isn’t required, but it makes using NPM more convenient. And the end of the guide discusses proxying the UI, so once you finish, you’re back to using the standard ports for the UI as well.
Another option (that wasn’t available when I wrote that guide) would be to bind the GUI to one IP, and NPM to another one. Then there wouldn’t be any need to change the GUI ports.
I read your guide. Love it. I don’t understand what is more convenient about NPM listening to all traffic on HTTP and HTTPS ports. It’s less convenient in the sense I had to set up local DNS for NAS.
I do like that TrueNAS now allows separate IPs for separate apps, because pfsense’s host override does not allpw you to specify port.
The convenience is mainly in not having to remember and enter the various custom ports used by the apps. You can browse to radarr.yourdomain, not radarr.yourdomain:8686 or 10.0.0.10:8686. It’s also in having only one place to manage TLS certificates, and taking care of TLS/HTTPS for everything. Since browsers are getting more vocal in preferring HTTPS, that’s a benefit even on your secure (even assuming it is) LAN.
I’m afraid I don’t understand the concern here.
No, of course not–DNS doesn’t handle port numbers (well, it does in SRV records, but we aren’t dealing with those here–A, AAAA, and CNAME records don’t). My solution is to set all of those as aliases (i.e., CNAMEs) to the NAS itself; an equally-viable solution would be to put NPM on its own IP, create a host override for that one, and set all the other apps as aliases of that. Either way, all the apps resolve to the IP of the proxy.
this is super helpful, thanks. that’s exactly the convenience i want. e.g. not worrying about ports.
I’m still working through guides on how to fix my NAT reflection/hairpin NAT issue where I can’t access services from LAN, but can externally (or through client VPN on computer–not ideal). I tried two different methods in pfsense, but seem to have some kind of cert mismatch when I access locally beyond the hairpin thing.
i am going to redo all certs to a wildcard cert and follow your guide again. i may try putting different apps on different IPs. that would be slick, but I finally got my head around this way.
