Questions on Letsencrypt Reverse Proxy

Hi!

I noticed that in the Turorials to Letsencrypt Reverse Proxy + Nextcloud* the ports for Nextcloud are additionally opened. I wonder if this isn't counterproductive. Isn't the point of the reverse proxy that the services behind it should only be accessible via the proxy? Nextcloud and Letsencrypt are packed into a common user defined bridge network to be able to talk to each other in isolation. Of course Letsencrypt needs an additional connection to the outside. But why does Nextcloud also get the second network? With this I create possibilities to communicate without the proxy (even if it is only local for the time being).
It is exactly the same with Plex. I can put Plex behind the proxy according to the same instructions. But it seems to me that this is a simple redirection. The communication on port 32400 completely misses the proxy.
Did I misunderstand something? What do your solutions look like?

Thank you!

*
https://forum.openmediavault.o…?postID=180613#post180613
https://forum.openmediavault.o…g-OMV-and-docker-compose/

Zitat von Morlan

The tutorials dont mention an additional opening of ports expect 80/443 for letsencrypt.

Yes they do.

In Techno Dads video he is setting up Nextcloud container with defining network type bridge and opening ports 444:443 and 81:80 (at min 9:42). Two seconds later he adds a custom bridge with the command --network=my-net. That custom net is needed in order to let Letsencrypt and Nextcloud talk to each other. You see, there are two networks! However, setting the first one with 444:443 and 81:80 is not needed and furthermore it gives the possibility to bypass the reverse proxy within the LAN.

In Macoms Docker Compose tutorial you will find in the .yml:

• nextcloud:
• ...
• ports:
• - 450:443
• - 82:80
• ...

what means he opens Nextcloud directly to the network through the Ports 450 and 82. And again it is simply not needed. Docker Compose will automatically create a custom bridge network to let the containers talk in isolation. Opening of the Ports 450 and 82 is not needed at all unless you want to bypass the reverse proxy in the LAN. Its actually a security issue if the reverse proxy is not only meant to work in the internet but also in the LAN.

Zitat von Morlan

Well these settings just redirect the port. If you leave them out the default ports will be exposed anyway. That is how the docker containers work. Without these exposed ports, to my knowledge, the container would be able to interact with each other even inside a docker network.
And if this is a security issue. I dont know.
Also the containers themselves are almost always also password protected...

Well, not exactly. These settings allow communication on these ports on any net. You can check this in the overview where it says e.g. 0.0.0.0:80->80. 0.0.0.0 means it is open in the whole LAN. Leaving the option out leads to a 80->80 without 0.0.0.0 cause it is only available in the isolated bridge network from now on. I have already tried it out. My assumption was totally correct.
I agree that it is not necessarily a security issue, but if your lan is already compromised or simply not trustworthy, it is. There is anyway no advantage opening these ports to 0.0.0.0 so I am really wondering why one would do these extra commands just to loose that plus of security on a isolated communication behind the proxy...

Zitat von macom

Yes, these ports are not needed. However I found it useful to be able to bypass the proxy when letsencrypt was not working properly. This way I could check that at lease nextcloud and mariadb were working properly.
I will adjust the docker-compose.yml

Thanks for the confirmation!

Zitat von Morlan

I didn't know that. Thanks for the clarification!

Thanks for the productive discussion! I'm just getting to the bottom of all the subtleties of the omv configuration and just wasn't sure if I understood it right.