Messages

Maybe an exotic browser or an adblocker interfering?

Did you try RSS as explained here, point #10?

Also, is any type of IDS active? The Watchguard M470 only has an Intel G4400, which is fairly slow by today's standards. A simple N100 beats it by more than a factor of two.

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.

[only]

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.

You have to create an alias and an actual firewall rule to make the URL load.

[on that same DMZ VM]

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.

Me too - I already registered for a free account on TIP.

No good idea, apart from a prefix disambiguation glitch.

Na klar. Die IP ist bei ipinfo.io als abusive gelistet. Die scannen systematisch Web-Anwendungen auf Schwachstellen.

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:

You cannot view this attachment.

They have a new variant (Warp), but I have not tried that.

[these are quite some tasks]

I figured as much, hence why I wrote:

For this to work, you must (these are quite some tasks):

The inability to use DHCPv6 for some clients is independent of static reservations and DUIDs are even a different story. I fixed the link.

But 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.

DHCPv6 works only for some clients - and sometimes, it is only being used to fetch DNS info, not IPs nor routes. What it is used for depends also on the RA mode.

Take a look at this for a more in-depth explanation and a remedy.

And before you ask: I do not use DNSmasqs RA mode (I do not use DNSmasq at all, but Kea), but the normal RA daemon.

Of course it does. Opening any port from outside to your internal network can compromise your security. We discussed just that here, didn't we?

When you open a port to any application, you will give the whole internet the opportunity to scan for the application and probe it for security flaws, like WASP vulnerabilities. For that, attackers do not even need to individually probe that application. If they can probe for fingerprints (i.e. application type and version) and find them in one of the widely available hacking databases, they're in.

And if there is no vulnerability yet, they can store the found fingerprints obtained into Shodan et.al., where attackers can look them up later to direct their future attacks directly at targets, once a new vulnerability becomes known. Of course, this is worse with IPv4 than with IPv6 and also worse with fixed IPs.

That is why you want to place your applications into an isolated network zone (DMZ).