Security is always a concern but do you think because there were unsanitized input in the control plane for logged in users on port 81 that have been fixed it should not be used?
My suggestion is not to expose the management port (81 by default) to the internet and don’t allow untrusted users access just in case there are any other unsanitized inputs.
I took it out, it’s not needed and was in there because I was not using my actual config but I had ChatGPT create a basic one real quick and it chose to add that. All the LLM’s get things wrong a lot and I usually audit before posting so that was an oversight on my part.
Me and you know to never expose any kind of management interface to the internet. My point being this product has some higher risks than other proxies running it and knowing the majority will inevitably have bad configurations, including exposing the management port.
Hi Tom, I watched and followed the video you posted on this (big thanks for creating the content) and for some reason I can NOT get my domain name to resolve. I receive a browser warning that the site can not be reached “ERR_CONNECTION_REFUSED”.
Here are my steps:
Create docker container for NGINX Proxy Manager
Set up two DNS Records for my domain at Cloudflare. An A record that points to my NGINX ip address that I would visit normally in my browser on local network, and a CNAME * pointing to my full domain name.
Create an SSL cert in NPM using Let’s Encrypt with the DNS challenge for Cloudflare which gets issued with no problem.
Set up proxy host for whatever.mydomain.com to point to the NPM dashboard as a test.
I checked to make sure DNS has propagated
Visit the url and receive an error.
One thing to note is I did choose different ports for NGINX proxy manager in my docker compose, 1880 and 18443. Is that the issue?
Really looking for some direction on how to troubleshoot this.
If I am understanding your issues then the host that the Nginx Proxy Manager is talking to is refusing the connection. Also, would fist test it on the default ports to eliminate issues and move once you know it’s working.
Ok, I updated the compose file to use ports 80, 443, and 81. This allows it to work, so is it a port forwarding issue with the router, or something different? I can definitely leave it as is, but I’m trying to increase my understanding of networking.
If you are trying to make this publicly accessible and changing the port breaks it externally but not internally, then yes, it sounds like a router port forward issue.
Ah, yea, I see what you’re saying. However, I only want the services to be accessible internally with an SSL. I don’t want the services exposed to the public at all. So I guess I still am unsure why changing the ports would be an issue.
I refuse to open ports on my firewall. I have Cloudflare tunnels to expose my websites and such. I just point the cloudflare tunnel public host name config to the internal domain name of my service. In pfSense I have host overrides pointing those domains to my Nginx instance. Works great. I have Collabora, Nextcloud, and Discourse exposed this way. At the same time, I have vault warden set up with a host override and presented internally only using the same Nginx instance. If I need to connect to vaultwarden externally I connect through tailscale.
I am not sure that’s true. I was able to go into my instance of TrueNAS Scale, go to system/general settings/gui and change the ports. I switched 80 to 8080 and 443 to 8443. Then I just had to update my bookmark for the web UI. I didn’t even have to update my Letsencrypt certs associated with TrueNAS.
BUT…then again, I am NOT using TrueNAS to manage my docker apps running on that same VM. I use Portainer instead, and I created my own docker compose files to use as Portainer stacks. I was tired of updates to TrueNAS breaking docker apps, so I stopped using their built in applications function/app catalog. But I can still do bind mounts directly to a desired dataset for my docker volumes, so its kind of the best of both worlds.
I also only run the portainer agent in TrueNAS scale. I have a pre-existing instance of Portainer on another VM that I use to manage docker in TrueNAS. And I use Watchtower to update my containers, so it really is disconnected from the way TrueNAS manages apps.