Messages

1. The current CE version is 25.7.7_4, where this has long been patched.
2. As I wrote, the vulnerability never applied to OpnSense anyway - and I also explained why.

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.

[I]

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.

I use that integration and it shows the temps:

You cannot view this attachment.

Not the original question, but the heat transfer of the china boxes are often abysmal and because of bad quality control, differs much from one specimen to the next.

See this for an example (in german, but with telling pictures). When the temps are really bad, I always change the thermal paste. Sometimes, there is not enough pressure between the board and the case.

Did you create a firewall alias and use it in an actual rule?

Siehe https://forum.opnsense.org/index.php?topic=42985.0, Punkt 23.

Wenn Du nur IPv4 hast, brauchst Du offensichtlich für IPv6 auch keine Einstellungen.

Theoretisch könntest Du zum Testen lokal eine Strecke aufbauen, um die Wirksamkeit des Shapers zu überprüfen und zu checken, dass Deine Hardware oder Dein Setup nicht das Problem sind. Dazu müsstest Du ein zweites System an einen weiteren Netzwerkanschluss anschließen und dort ein separates LAN aufbauen. Dann könnte man die Performance zwischen Deinem LAN und diesem zweiten System messen. Leider hat Deine Hardware aber nur zwei Ports, die schon belegt sind.

Ich denke tatsächlich, dass sich das Verhalten des Shapers - insbesondere mit den Einstellungen gegen Bufferbloat - nicht mit einer Mobilfunk-Anbindung verträgt. Eventuell könnte es aber etwas bringen, wenn man z.B. Download-Traffic niedriger priorisiert oder Bandbreite für andere, wichtige Anwendungen (oder Clients) höher priorisiert bzw. Bandbreite dafür reserviert. Auch dazu gibt es in der Dokumentation Anleitungen.

Ich frage nur zur Sicherheit: Du hast nach Setzen der Tuneables einen Reboot ausgeführt?

Ich würde aber nicht ausschließen, dass eine 5G-Anbindung anders reagiert als die typischen DSL- und Glasfaser-Anschlüsse. Wenn dort Pakete in Zellen zusammengeschnürt werden, kann das problematisch sein, wenn das mit dem Timing des Shapers kollidiert.

ISC DHCP is deprecated and if you disable it on every interface, it should never start.

The official OpnSense replacement ist DNSmasq, see: https://docs.opnsense.org/manual/dnsmasq.html

Other than than, you can also use Kea DHCP instead.

Ja, sorry, habe es korrigiert, es ist aber auch im Punkt 26 in "READ ME FIRST" verlinkt. Da stehen noch ein paar Tips...

Könnte aber auch sein, dass Du ASPM noch an hast was insbesondere I226V sehr verlangsamt, auch dazu findest Du etwas im Artikel.

P.S.: Es ist übrigens nicht damit getan, die Queues wieder anzulegen - die Regeln müssen diese auch referenzieren (und nicht die Pipes).

The overhead is minimal (I wrote the job) - I call it every 5 minutes. Note that you only need it on the VPN side that initiates the connection to find the target if it changes IPs.

Offenbar hast Du vollkommen übersehen, die offizielle Dokumentation zu Rate zu ziehen, wenn ich dies hier richtig interpretiere:

Der Queues-Reiter ist bei mir komplett leer.

Siehe dazu auch dies: https://forum.opnsense.org/index.php?topic=42985.0, Punkt 26.

Das Traffic-Shaping sollte eigentlich auch auf Deiner Hardware ziemlich gut funktionieren (siehe meine Signatur).

Now I got it. Yes, that message pops up after a restore. However, the input field is being restored. When you hit apply, it works if an alias and a rule exist.

Still, it is a bug.

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.