I currently have my reverse proxy on my NAS. That means I forward all of my 443 HTTPS traffic to my NAS. I am using OpnSense for my router, and there are several options for reverse proxies on that. Everything works the way it is now, but I do wonder if it would be “better” if I moved all of the reverse proxy stuff to my router. I don’t know that anything would be simpler to manage one way or the other, so I think it comes down to best practices and security. If I move the reverse proxy to my router, I would be able to remove that forwarded port, but is that really any more or less secure?
I try to keep my router and NAS clutter-free as far as software goes. Each additional service you run, especially that listens to requests from clients you can’t control, could open you to a vulnerability that might give system access.
I run a reverse proxy on a dedicated Pi and have firewall rules on the Pi to only allow outgoing connections to the hosts I’m proxying to.
Maybe I’m paranoid but I’m sure there are lots of good and bad eyes looking at Nginx’s code.
I took have a nginx reverse proxy, ddclient, PiHole on a dedicated Pi behind the router and in front of literally everything else.
The reverse-proxy is usually the place where you terminate the TLS connections and also where you generate your let’s encrypt certificates. Depending on your network stack and software used, it can be a bit inconvenient to have that on the router.
One way that is interesting though is to have a load-balancer + reverse-proxy combination on the router that can also do SNI based forwarding and then have a second application reverse-proxy that also acts as the TLS termination point on the actual server. However setting that up is a bit more involved and the documentation for it on OPNsense isn’t great (I tried this before and failed, even though the docs say it should be possible).
If it ain’t broke, don’t fix it.
Is this for internal clients?
If no, do you need unauthenticated public access to that?
Would you consider VPN instead?
