I have been trying to use NPM for a while now, following Wolfgang’s local SSL cert guide with limited success. I tried having it setup on a debian VM then following the guide, but was only able to proxy NPM itself. Despite the SSL cert loading just fine, the TrueNAS apps and web UI don’t seem to want to work.
I ended up scrapping the VM since that’s the only reason I was trying to use it, but I have now installed the NPM TrueNAS app. Unfortunately, I still can’t get anything to work.
The Duck DNS domain I am using is set to the IP of my NAS, and I have set a wildcard for the domain in the SSL cert to use for the apps.
I am using Pi-hole as my local DNS, and I set the NAS IP as the base domain (e.g. mydomain.duckdns.org = NAS IP).
I should note: I am not trying to expose any of my apps or NAS to the internet. This is purely just to have SSL for my apps locally. While technically not needed, it is something I’d like to have.
Unless you followed stux’s howto on setting up a bridge interface, a VM won’t be able to access services running on the TrueNAS host:
Also, the TrueNAS NPM app can’t run on ports below 9000, so you’ll need to specify the port you’re connecting to in your web browser, rather than it assuming it’ll be on 443
I should have mentioned I have a network bridge, and my two other VMs (both are running Debian for Pi-hole and Tailscale exit node, respectively) are able to connect to the Internet just fine.
Just my opinion, but running a whole VM for things like pihole and tailscale is a bit overkill. They’ll quite happily operate in docker and use a lot less host resources. Same goes for NPM.
I still don’t know what is going on with NPM, though.
I have the ports set to default (30020, 30021, 30022 for web UI, HTTP, and HTTPS). Attached are screenshots of my setup for just the proxy for nginx. Is there anything that’s glaringly wrong?
I realized I had the web UI port set when it should have been HTTP. That said, even switching it to the HTTP port did not fix the issue. I don’t know why this is such a headache.
Let me know if you figure this out. I am having the same issue. The same cert works for virtually all other apps, but Truenas login doesn’t seem to like nginx SSL certs for some reason.
My experience Nginx Proxy Manager successfully registered the certificate but the browser did not use the ssl certificate. I found out Nginx Proxy Manager requires both 80 and 443 these are not set up by default. Because, Truenas Scale UI runs on port 80 and you’re going to need to change it to something like 81 in /ui/system/general then reset up Nginx Proxy Manager required ports.
Using a VM to set up an app for proxy duty means you need to preallocate resources in a way that is inefficient. It also complicates the networking and maintenance.
Mind you, if your VM doesn’t start for any reason you have zero or marginal access to your apps.
What gives you that idea? KVM uses resources as needed, up to the maximum set for the VM in question; it doesn’t segregate those resources completely on VM start.
Not saying a VM is the way to go here–I don’t see any reason to use one, unless a different OS is desired–but this isn’t a reason not to use one.
Equally true of any other way you might run the proxy.
Right, and after it has claimed resources, it does not necessarily release them as efficiently as one might want. Memory ballooning is one example of that, it’s a dance between the guest and host that does not always work great. It’s inherently less flexible than running it directly on the host.
The scenario as I read it was to run the proxy in a VM to provide access to apps in the traditional TrueNAS Apps subsystem. It’s less risky to rely on just Apps instead of being dependant on both Apps and VMs being functional at the same time.
Likewise, running all apps in the same VM would be a better choice than building a convoluted split VM/Apps solution.