VLAN DMZ for website server (ubuntu server) or any other way of doing it?

[meyergru]

That looks fine. You do not need to separate cloudflared from nginx, but it does not hurt, either.

IDK if TN directly supports docker containers, if so, keep in mind that true VMs provide a better isolation than lightweight containers, like Docker, LXC or their likings.

[flamur]

That looks fine. You do not need to separate cloudflared from nginx, but it does not hurt, either.

IDK if TN directly supports docker containers, if so, keep in mind that true VMs provide a better isolation than lightweight containers, like Docker, LXC or their likings.

this was the message I wanted to read! The Jedi is happy = than I am more than happy! 🙏

I think its starting to make a little sense now. I hope.

What I am doing (in theory) is creating separated roads to all my apps in TN. And to get on to those roads from WAN I have opnsense as a block/pass for specific type of traffic I allow. But I will use cloudflared to not open any roads, instead some magic to jump the blockade and then pass that traffic to nginx with a small port rule so that nginx can direct traffic to other apps or networkadresses. These Nginx "sideroads" to other servers or apps etc will be opened with rules in opnsense.

Have I summarized it correctly? 🤔 (I write like this to see if I understand it or if I have broken logic)

[Patrick M. Hausen]

IDK if TN directly supports docker containers

It does but these are *NOT* separable from the control plane. Only VMs are (via bridge interfaces without a host IP address).

Docker was the motivation to switch TrueNAS from FreeBSD to Linux.

[meyergru]

Have I summarized it correctly? 🤔 (I write like this to see if I understand it or if I have broken logic)

Yes. With the "other" approach I described in my first answer (i.e. the usual OpnSense one, not the one involving Cloudflare), you would install the reverse proxy on OpnSense itself and then direct the backends to different webservers on isolated VLANs. You would not use a separate Nginx reverse proxy, but one on OpnSense itself, like Caddy or HAproxy (both have HOWTOs in the tutorial section of the forum).

Logically, both do the same thing: You terminate the TLS traffic in a reverse proxy (your own or using cloudflare), then the traffic is passed to an isolated webserver that can do no harm if hacked. Cloudflare just happens to provide these topics:

1. Certificate issuance.
2. "Finding" your backend (which would otherwise be done via dynamic DNS)
3. Reverse proxying and tunneling the traffic to your end.

[flamur]

IDK if TN directly supports docker containers

It does but these are *NOT* separable from the control plane. Only VMs are (via bridge interfaces without a host IP address).

Docker was the motivation to switch TrueNAS from FreeBSD to Linux.

I was messing around in the apps trying to find where to put them on their own VLAN/Bridge, but this explains it.


Damn. Than I need to create a VM. (I wanted to skip this part since its one more thing to learn from zero, when the only goal is to get my website server up and running again 😅)

Thanks for the info 🙏

[Patrick M. Hausen]

I run publicly reachable "apps" on TrueNAS CE but I use TrueNAS CE only for that. So I placed the whole darn thing in its own VLAN, reverse proxy via Caddy on OPNsense, done.

All precious data is on my second NAS running TN CORE.

But if you have only one system, yes, probably best to use a VM.

[meyergru]

Damn. Than I need to create a VM. (I wanted to skip this part since its one more thing to learn from zero, when the only goal is to get my website server up and running again 😅)

What I do not quite understand then is how you separated your docker containers in VLANs, like you said you did? Patrick says that is not possible when running containers under Truenas?

[Patrick M. Hausen]

You can assign a dedicated IP address to your Docker based "apps" in TrueNAS. Even one on a VLAN interface.

For ingress.

For egress all those "apps" will still use your management interface with the default route, because they run on the same IP stack as the control plane.

That's the current state of affairs.

Come to think of it I should try placing the control plane into a separate network *without* a default route ;-)

[meyergru]

Yup! I use LXCs or VMs on Proxmox, which can both be placed on VLANs that are separate from Proxmox's control plane. By strictly using reverse proxies, the default route is mostly irrelevant, because the caller is always the internal IP of the reverse proxy. You have to take steps to pass the remote caller IP via HTTP headers, in order to be able to know who the original caller was in the backends.

And my Docker installation is in a separate VM. To be exact, I have two Docker VMs, one for containers reachable from outside and one internal only.