Hi,
I am just starting my life time goal to have a somewhat serious network at home and to host my own websites.
I have just installed opnsense firewall as the first node from the fiber. I then connect a newvly installed ubuntu server in to the firewall.
My plan, after some googleing and reading, is to create a separate VLAN and DMZ for that server.
What makes it a bit tricky is that I have a truenas scale server with NGINX and proxy thrue cloudflare. So before this I just pointed cloudflare to my public IP and then my asus router would portforward that to my truenas scale server with NGINX to point the traffic to my website server.
Taken this in to account my NGINX would be on separate VLAN not DMZ. To keep it "internal" and more safe. But not sure how it would be able to direct traffic to my new website server within the other VLAN with DMZ setup.
My question is perhaps to broad, since I dont really know where to start this. Do anyone have a guide on this specific thing? Or can point me in the right direction?
Or would you recommend any other (more secure) setup for my website server?
Best regards,
Flamur
Usually, you would just use a reverse proxy like Caddy or HAproxy (there are howtos for those in the tutorial section) to redirect requests to any web backend by name). Using it this way, you do not need to know any ports, just the DNS names for the servers. The reverse proxy does the TLS termination and also fetches the certificates via ACME.sh (preferably via wildcard domains). You would open up ports 80 and 443 on your OpnSense, while the web UI is put on another arbitrary port.
By setting up a separate DMZ VLAN for the backend web server(s), you would then make sure that if one is getting hacked, they cannot get through to your valuable ressources on LAN. Since OpnSense has access to all VLANs, you can put the backends anywhere.
For this to work, you must (these are quite some tasks):
1. Divert the OpnSense web UI to other ports.
2. Set up a working DMZ VLAN with separation from your LAN to put your web server into.
3. Configure the reverse proxy.
4. Set up certificate generation.
5. Configure DNS names to point to your OpnSense instance (potentially involving DDNS).
Cloudflare works differently, AFAIK. They use a reverse tunnel from your web service to Cloudflare, which works much like a VPN. This way, nobody using your web service ever gets to know your real IP or contacts it via ports 80/443. This has the advantage to work even if you are behind CG-NAT, where you cannot set up an open port to work from the outside in in the first place. Your web backend can exist in a separate DMZ VLAN as well in this scenario. Since the connection is done from you to Cloudflare and not the other way around, you also do not have to deal with (D)DNS or expose anything directly to the internet.
For this to work, you must set up:
1. A working separate DMZ VLAN which can access the internet. You place your web server in that DMZ, as well as the Cloudflare client.
2. Cloudflare reverse proxy with certificates.
Quote from: meyergru on October 26, 2025, 09:13:28 AMUsually, you would just use a reverse proxy like Caddy or HAproxy (there are howtos for those in the tutorial section) to redirect requests to any web backend by name). Using it this way, you do not need to know any ports, just the DNS names for the servers. The reverse proxy does the TLS termination and also fetches the certificates via ACME.sh (preferably via wildcard domains). You would open up ports 80 and 443 on your OpnSense, while the web UI is put on another arbitrary port.
By setting up a separate DMZ VLAN for the backend web server(s), you would then make sure that if one is getting hacked, they cannot get through to your valuable ressources on LAN. Since OpnSense has access to all VLANs, you can put the backends anywhere.
For this to work, you must (these are quite some tasks):
1. Divert the OpnSense web UI to other ports.
2. Set up a working DMZ VLAN with separation from your LAN to put your web server into.
3. Configure the reverse proxy.
4. Set up certificate generation.
5. Configure DNS names to point to your OpnSense instance (potentially involving DDNS).
Cloudflare works differently, AFAIK. They use a reverse tunnel from your web service to Cloudflare, which works much like a VPN. This way, nobody using your web service ever gets to know your real IP or contacts it via ports 80/443. This has the advantage to work even if you are behind CG-NAT, where you cannot set up an open port to work from the outside in in the first place. Your web backend can exist in a separate DMZ VLAN as well in this scenario. Since the connection is done from you to Cloudflare and not the other way around, you also do not have to deal with (D)DNS or expose anything directly to the internet.
For this to work, you must set up:
1. A working separate DMZ VLAN which can access the internet. You place your web server in that DMZ.
2. Cloudflare reverse proxy with certificates.
I have been working on the server settings and opnsense settings and taking time to read and looking at youtube videos on this/network topics to understand what I am doing more. I still feel lost but have some things pinned down. Have started mapping everything in a excel to keep track of my network.
I want to use the last solution you write. Its somewhat what I had before on my normal home asus router, which was very simple on that one.
What I have done is put my server on a dedicated port on the firewall. Have made a subnet(?) for that to be on - 192.168.20.1 IP within the interface settings (dhcp server adress might be the technical term? 🤷�♂️).
Not sure if I need dhcp on that interface since I will only have my server running there with a static ip - if possible.
I will also place my truenas scale server which handles nginx on a dedicated port on the firewall. With its own subnet(?), 192.168.10.1.
In my mind this would be as different "VLAN" but hardcoded with the ports instead to keep it simpler for me to handle in the beginning and also easier on the firewall ports for maximum speed.
Whats next?1) So in my mind I now have to figure out how to open ports for traffic to flow to my truenas server from WAN, to be able to get traffic from Cloudflare as before (what was called portforward on the asus router).
2) Then I need to open ports from my truenas server to my hosting server for traffic to flow between them - so that Nginx can handle the proxy.
Am I on to it/close or totally lost? 🤔😅
Questions1) if above is somewhat correct. Where in all this do I configure DMZ?
2) do I need dhcp on the two server ports/interfaces since it will only be on server on each dedicated port in the firewall?
With Cloudflare, there are no ports to be opened, since the whole Cloudflare connection is going inside out - Cloudflare provides a client to connect to their servers and then use this tunnel to direct traffic to your internal network and services. That is, the take up the part of terminating HTTP(S) traffic on their end (including certificates), doing the reverse proxy and directing the traffic through a "kind of VPN" tunnel to your network.
Quote from: meyergru on November 09, 2025, 05:07:11 PMWith Cloudflare, there are no ports to be opened, since the whole Cloudflare connection is going inside out - Cloudflare provides a client to connect to their servers and then use this tunnel to direct traffic to your internal network and services. That is, the take up the part of terminating HTTP(S) traffic on their end (including certificates), doing the reverse proxy and direting the traffic through a "kind of VPN" tunnel to your network.
Thanks for that explanation. I thought it was the other way around 🙈
Can I ask if I even need to think about DMZ with my planned setup? I wont use VLAN since I use two different dedicated ports on the firewall for my two servers.
I have rules that allow internet for them, but not connect locally (followed https://homenetworkguy.com guide). Is this a DMZ? 🤔
I use this rule on all my interfaces more or less as a standard:
(https://photos.app.goo.gl/HWNak1ELHYHaeqr59)
(https://photos.app.goo.gl/HWNak1ELHYHaeqr59 (https://photos.app.goo.gl/HWNak1ELHYHaeqr59))
Would this rule be good practice for my truenasscal that host the nginx proxy for example?
Well, I always use a DMZ for any openly accessible service. The main reason for this is that web applications (or complex applications in general, which excludes "more simple" SSH, file service and VPN endpoints) bear the risk of being exploited.
Imagine an SQL-injection that surpasses the login or any other WASP exploit. If this were the case, you could probably use the application as a starting point to gather intelligence or break into your network. By confining this application in a DMZ, it cannot be used to gain access to your LAN - correct firewalling implied.
A bad example for this would be Proxmox Backup Server: It has a limited API, yet its endpoint is the same as the web UI. Thus, if you just want to expose backup services, you have to expose the full web UI. Therefore, you must use a VPN on top, which would be dispensable if the API was separate.
The same reasoning applies for IoT-devices that use outbound connections to the cloud, because these connections can also be reversed. Heck, I even confine smartphones to a different VLAN for the same reasons. They need internet access, but no access to my LAN.
P.S.: You have to trust Cloudflare not to misuse their infrastructure, that should be clear by now. However, with the endpoint in a DMZ, this is also less of an issue, provided that their daemon runs there and not on the firewall itself.
W/r to your TrueNAS server: It was better if you separated the file server (LAN) from the application server (DMZ). That way, you could confine the application (which might get hacked) to a subset of your data (i.e. the part that you give access to). For this, you would need a firewall rule to allow file access and hope that the authorisation cannot be circumvented.
You can imagine this like an onion, where you have to surpass several levels in order to get through to the core.
Quote from: meyergru on November 10, 2025, 10:50:54 AMW/r to your TrueNAS server: It was better if you separated the file server (LAN) from the application server (DMZ). That way, you could confine the application (which might get hacked) to a subset of your data (i.e. the part that you give access to). For this, you would need a firewall rule to allow file access and hope that the authorisation cannot be circumvented.
Can I separate my server if I only have one ethernet port on the truenas server? I thought I read end points cant handle tagged vlans. Or how would I do that? 🤔
You can run this single port as a trunk port with multiple tagged VLANs.
All my TrueNAS systems have a 2-port LACP link to my switch and all VLANs on top of that. Works with a single port, too.
IDK exactly if you could run nginx as a separate VM on TrueNAS Scale, which then would be connected to a VLAN or separate network adapter.
I do that with Proxmox, where it works. Patrick presumably uses TrueNAS core on FreeBSD, which might differ.
Quote from: meyergru on November 10, 2025, 11:57:36 AMIDK exactly if you could run nginx as a separate VM on TrueNAS Scale, which then would be connected to a VLAN or separate network adapter.
Of course you can and I do. I run both TN CORE and TN CE (formerly SCALE) - as I wrote all connected exclusively via VLANs. The TrueNAS CE machine runs 3 VMs:
- Windows 11
- ElastiFlow on Ubuntu
- Home Assistant
Currently my workloads are distributed like this:
Storage and jails: TrueNAS CORE
Docker "apps" and VMs: TrueNAS CE
HTH,
Patrick
I wonder if my novice level might be forgotten here.
I dont know how to trunk my ports. I will google though. But is this needed for my purpouse? It feels like I am going a bit too far over my head atm.
Or can the firewall rules be setup so that they separate my apps from the local storage instead of VLANs? 🤔
I only have this on my TN server:
1) nginx to proxy traffic from cloudflare, so that my website server works. Also proxy for nextcloud (cloudstorage) and plex server.
2) I have plex server app for movies
3) Nextcloud app for cloud storage
4) Some locally shared storage to make a central storage for my data
I guess I need to expose 1-3 to the internet. And to do that as locked as possible. Thats why I use cloudflare to handle my domainname and point traffic to my router. And only open the ports they need out to WAN.
Nr4 I understand should run on LAN somehow not exposed to the internet as the rest.
So do I need to put in more reading on the Trunk solution to get VLANs up or is it as good to use firewall rules (if its even possible)?
Also please note my TN server only has one NIC.
I liked this solution, but I think I might not understand what I am reading.
QuoteFor this to work, you must set up:
1. A working separate DMZ VLAN which can access the internet. You place your web server in that DMZ.
2. Cloudflare reverse proxy with certificates.
1. This is done I think. I have my webserver on a separate interface and its own subnet with locked down firewall rules to only access internet and not locally within my network.
2. I have a cloudflare account for my domainname. on there I previously set up cloudflare to handle my domain, and point to my own IP in the DNS records. I also added ssl with strict setting. And used the certificate and put it into the Nginx app.
But perhaps I dont ned nginx app in the truenas scale anymore if opnsense can direct the traffic locally instead? 🤔
Quote from: flamur on November 10, 2025, 02:10:24 PMBut perhaps I dont ned nginx app in the truenas scale anymore if opnsense can direct the traffic locally instead? 🤔
There is two parts to this:
I said in my first answer that to set up a connection from outside, you can follow either an OpnSense-only setup or a Cloudflare based approach. Either one will take care of having a connection to your internal services.
Cloudflare is easier, because the neccessary steps to open up and encrypt an inbound connection an/or set up your own reverse proxy for that might be diffcult for a beginner.
The second part concerns where to actually host your own service. You need a separate physical LAN or a VLAN to create an isolated subnet (DMZ) which should be the one that your application endpoint (nginx) runs on. For this, you need to create a VM that is connected to your DMZ (either via a separate port/switch) or via a VLAN. The Cloudflare daemon would then run on this VM, as well as your Nginx.
Maybe Patrick can tell you how to do that, as I said, I use Proxmox for this purpose.
Quote from: meyergru on November 10, 2025, 02:34:19 PMQuote from: flamur on November 10, 2025, 02:10:24 PMBut perhaps I dont ned nginx app in the truenas scale anymore if opnsense can direct the traffic locally instead? 🤔
The Cloudflare daemon would then run on this VM, as well as your Nginx.
Many thanks for your patience and help. I read, but sometimes it flyes over my head WHAT I read 😅
I see now you mean cloudflare in another way than I had it before. I will google and see if I can get that up and running before going further.
I will also investigate how to get the VLAN solution to work on my truenas scale server.
I will re-plan my work and start with getting my truenas scal up and running on the new network. Thought I could leave it running on the asus router while setting up everything else 😇
I think its just a big overload of new concepts and stuff I have never heard or done, so it takes alot of time to process it 😊
I figured as much, hence why I wrote:
Quote from: meyergru on October 26, 2025, 09:13:28 AMFor this to work, you must (these are quite some tasks):
Quote from: meyergru on November 09, 2025, 05:07:11 PMWith Cloudflare, there are no ports to be opened, since the whole Cloudflare connection is going inside out - Cloudflare provides a client to connect to their servers and then use this tunnel to direct traffic to your internal network and services.
First time I hear of this. That is not how any of my customers use Cloudflare. And quite some of them do. Yet they always point the CDN to some public IP address where the service in question is finally hosted.
You can use a cloudflared tunnel and connect to that. It is nice when you only have CG-NAT, because then, you cannot point Cloudflare to anything, sometimes not even to an IPv6 address. Plus, you do not need a router/firewall that can open ports at all. It is also robust against any port-scanning (because none is open).
Cloudflare takes care of basic protection and TLS certificates - and also, you do not need any dynamic DNS in order to find your real IP (also because of the reverse direction of the connection initiation).
Looks like this in Cloudflare:
2025-11-10 14_50_22-Tunnel - Cloudflare One — Mozilla Firefox.png
They have a new variant (Warp), but I have not tried that.
Ok sorry to spam this forum. I AM HAPPY AS A CHILD ON CHRISTMAS!
I setup cloudflared on my truenas. Put it behind my firewall. And after some headaches I can now reach it with a domainname from a computer elsewhere. Perhaps not the most secure setup for the future, just want to get it started to reach it to keep configure nginx etc.
But cloudflare tunnel is really nice. And I dont need any ports. Not sure how it works that the firewall allow this traffic since it should block everything - but I hope this is supposed to work like this.
If I understand the guides correctly I can set up all my traffic through cloudflare for nextcloud, nginx and plex using this method. No ports needed and my IP is "hidden" for the outside world which seems really neat.
To think they give this for free is so nice, and your help guiding in this is soo soo appreciated you cant believe it! :) Sorry there is no like button or something.
The quest contious to make this work for my websiteserver... still have not got my head around that next step. Since its another interface and server, which does not have this neat cloudflared app installed 🤔🤷�♂️ Is it just for me to use nginx as I did before perhaps and add some firewall rule to allow traffic between the interfaces/subnets? 🤔
What exactly are you exposing to the world via a domain name? Don't do this with the TrueNAS UI or the file sharing services. These are not hardened and will get hacked sooner than you might think.
You can safely expose a hardened Internet safe application in a VM via cloudflare like this. Or an app on TrueNAS that is supposed to be run that way, like e.g. Nextcloud.
Don't ever open your TrueNAS itself to the world. Please.
I already warned to expose unhardened web UIs in post #5, I think.
As for the setup: It is almost surely not what I suggested. You talked about an application behind an nginx reverse proxy that runs on a VM under TrueNAS on a DMZ network and I meant to have the cloudflare tunnel running on that same DMZ VM. Now it seems you are running the cloudflared on TrueNAS itself, which has access to your LAN (or so I presume).
As Patrick says, anyone who can use the Cloudflare endpoint can try to hack the connected application(s) behind the tunnel.
This is just as insecure as opening a port on the firewall itself. The only benefit is that Cloudflare first takes attack attempts before they hit you. However, it does little more than any other reverse proxy would do. When you open up a web app, you open it up to essentially anything.
If these apps are running in your LAN and not in an isolated DMZ, it can be problematic. You will have to take special care to not expose unhardened apps. Nextcloud should be fine, however, if there ever was a vulnerability, I would still like to have it in my DMZ if possible.
That being said, you do not need anything like this in order to expose Plex - it has its own means (i.e. tunnel) to enable remote access.
Quote from: Patrick M. Hausen on November 10, 2025, 07:24:49 PMWhat exactly are you exposing to the world via a domain name? Don't do this with the TrueNAS UI or the file sharing services. These are not hardened and will get hacked sooner than you might think.
You can safely expose a hardened Internet safe application in a VM via cloudflare like this. Or an app on TrueNAS that is supposed to be run that way, like e.g. Nextcloud.
Don't ever open your TrueNAS itself to the world. Please.
Oh no. It was the GUI of the truenas.
Back to the drawing board 😞
I dont get how to make this work and be safe.
Can I use the tunnel for nginx proxy manager and nextcloud app in my truenas scale server? 🤔
I still cant understand how I will get the website server to get internet access and traffic directed to it behind my firewall with opnsense. What am I missing in this?
Quote from: flamur on November 10, 2025, 09:30:24 PMCan I use the tunnel for nginx proxy manager and nextcloud app in my truenas scale server?
Of course. That is the idea.
Quote from: meyergru on November 10, 2025, 07:34:57 PMI already warned to expose unhardened web UIs in post #5, I think.
As for the setup: It is almost surely not what I suggested. You talked about an application behind an nginx reverse proxy that runs on a VM under TrueNAS on a DMZ network and I meant to have the cloudflare tunnel running on that same DMZ VM. Now it seems you are running the cloudflared on TrueNAS itself, which has access to your LAN (or so I presume).
As Patrick says, anyone who can use the Cloudflare endpoint can try to hack the connected application(s) behind the tunnel.
This is just as insecure as opening a port on the firewall itself. The only benefit is that Cloudflare first takes attack attempts before they hit you. However, it does little more than any other reverse proxy would do. When you open up a web app, you open it up to essentially anything.
If these apps are running in your LAN and not in an isolated DMZ, it can be problematic. You will have to take special care to not expose unhardened apps. Nextcloud should be fine, however, if there ever was a vulnerability, I would still like to have it in my DMZ if possible.
That being said, you do not need anything like this in order to expose Plex - it has its own means (i.e. tunnel) to enable remote access.
I thought the cloudflared tunnel app would be the road in to my network. Misunderstood what you meant.
Ny truenas is within its own interface and subnet with firewall rules to only allow dns and internet out. All other internal networks are blocked. So I guess this is a DMZ 🤷�♂️
The same setup has been made for my website server.
But I cant figure out how to direct traffic from WAN to my two servers. Mainly a problem since I use different domains for my apps. nextcloud.mydomain.com, www.mydomain.com (would be my website server).
Thats where I thought I should use nginx proxy manager. This worked good on with my asus router and just portforward some ports. This is another level... however thus far fun to learn. Even if I make some stupid errors as with the exposure of truenas gui 😬 (thanks for correcting that! 🙏🏼)
No, think about how the traffic is passing. Draw a picture if you need to.
The correct steps are:
1. Create a VM in your TrueNAS server that is connected to a TN VLAN interface only (the DMZ interface).
2. Create that DMZ VLAN in your OpnSense as well and isolate it from your normal LAN. Give it internet access.
3. Install your nginx reverse proxy and your application on this VM.
4. Install the cloudflare client in the same VM and connect that to the Cloudflare console endpoint.
That way, someone who connects to your Cloudflare endpoint is tunneled through to your VM and your VM only. Should your application get hacked, he is still only within the DMZ, without any chance to break into your LAN.
That would be the case if the cloudflare client is installed on any machine (VM or physical) that is in your LAN, like if you install it on TN itself.
And just to be clear: OpnSense has (nearly) no saying in this - apart from that it allows the VM to access the internet (and Cloudflare's cloud alongside) and that it isolates your LAN from your DMZ. What it does not do is regulate the traffic that is passing to Cloudflare's endpoint or what goes through the Cloudflare tunnel. Since that traffic is encrypted, it just passes by virtue of you allowing internet traffic from the DMZ VM in step 2 and this tunnel being used in the other direction.
Quote from: Patrick M. Hausen on November 10, 2025, 09:32:33 PMQuote from: flamur on November 10, 2025, 09:30:24 PMCan I use the tunnel for nginx proxy manager and nextcloud app in my truenas scale server?
Of course. That is the idea.
aha! Thanks for clarifying 🙂
I will give this some sleep and try to find some guide on nginx behind opnsense before posting more here.
It has to be something on google 😇
Sorry for all the posts. I think this is fun but so many details and I dont want any obvious holes in the security. So slow and steady.
Quote from: meyergru on November 10, 2025, 09:41:36 PMNo, think about how the traffic is passing. Draw a picture if you need to.
The correct steps are:
1. Create a VM in your TrueNAS server that is connected to a TN VLAN interface only (the DMZ interface).
2. Create that DMZ VLAN in your OpnSense as well and isolate it from your normal LAN. Give it internet access.
3. Install your nginx reverse proxy and your application on this VM.
4. Install the cloudflare client in the same VM and connect that to the Cloudflare console endpoint.
That way, someone who connects to your Cloudflare endpoint is tunneled through to your VM and your VM only. Should your application get hacked, he is still only within the DMZ, without any chance to break into your LAN.
That would be the case if the cloudflare client is installed on any machine (VM or physical) that is in your LAN, like if you install it on TN itself.
And just to be clear: OpnSense has (nearly) no saing in this - apart from that it allows the VM to access the internet (and Cloudflare's cloud alongside) and that it isolates your LAN from your DMZ.
Oh my. I missed the VM detail, thought it was optional.
Thanks for the clear instructions.
How much computer capacity does that VM need?
Does your OPNsense have a public IP address? You might want to consider Caddy on OPNsense instead of NginX proxy manager to do SSL termination and reverse proxying to your Nextcloud app. That's how I run almost everything here.
Quote from: flamur on November 10, 2025, 09:47:09 PMHow much computer capacity does that VM need?
2 GB of memory, 1 CPU core.
In networking, every detail matters. That is why I try to be this exact. IDK, it depends on what your application needs. The nginx proxy and the cloudflare client do not need much. I would guess 4 GByte of RAM and 2 CPU cores would suffice for a standard Linux VM, you may get away with what Patrick suggests.
Please dont give up on me yet. I made another solution and want to check if its as safe.
I have made VLANs in opnsense for:
VLAN30: Truenas UI
VLAN40: Truenas Nginx
VLAN50: Truenas Cloudflared
I then make the same VLANs in Truenas scale.
On top of that I make bridges for the apps.
For example the only firewall rule for vlan30 (TN UI) I block everything except my LAN net to my specific TN IP and port 80 (http just for now) on that VLAN (as of now testing, I will lock it down more when I am done).
If I understand this correctly I have this way segmented my network down to each app. So if someone hack nginx they will be on their own subnet/vlan, even bridge in TN. And in TN they are in a container/docker(?).
No traffic between except what is needed. For example Cloudflared VLAN will allow port 80/443 to talk to Nginx VLAN.
Would this be a good practice or have I totally misunderstood the assignment. I have been googeling and talking to gemini about different options and this was propused as the most secure with most layers to segment (and hack if someone where to do that).
PS. I just tested the firewall rule. If I use my laptop on LAN and try to access the TN UI I can only get to it with the http IP. If I try to use HTTPS its blocked. If I also deactivate the rule I cant access the TN at all. So it seems the rule is working as it should. The only issue I read is that opnsense automatically allows traffic back for each rule = not sure if its bad practice or something to worry about?
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.
Quote from: meyergru on November 11, 2025, 09:19:41 PMThat 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)
Quote from: meyergru on November 11, 2025, 09:19:41 PMIDK 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.
Quote from: flamur on November 11, 2025, 09:27:42 PMHave 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.
Quote from: Patrick M. Hausen on November 11, 2025, 09:31:30 PMQuote from: meyergru on November 11, 2025, 09:19:41 PMIDK 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 🙏
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.
Quote from: flamur on November 11, 2025, 09:50:14 PMDamn. 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?
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 ;-)
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.
Quote from: Patrick M. Hausen on November 11, 2025, 10:02:35 PMYou 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 ;-)
I had to use chatgpt to understand this.
It even translated your joke.
So this is way above my knowledge. But it made sense.
But would this interfere with my setup? I am starting to think I will only isolate the "app" pool with its own VLAN and the UI on its own. It feels more secure than a asus home router with everything behind that - so its a big step up for my porpouse.
Then in the future I will by som old hardware and use proxmox and laborate with that instead and throw away my two old computers I got from work to laborate with 😇
You cannot separate apps and the UI. You can only separate VMs from both. That is the point.