Messages

I severely doubt that those are the "suggested settings". Maybe you got them from an outdated Youtube video about OpnSense?

How do I know this? For starters, when you look at the official docs, you will find a prominent warning about how ISC DHCP is end-of-life. That means: Do not use it.

Apart from that: If you want your clients to be resolved in internal DNS, you will have to make sure that these things work as intended (and you did not say which work and which do not):

1. Your clients must be registered in your local DNS by "some" means. That could be static reservations and corresponding DNS entries or dynamic reservations. Also, they should register under a domain, such that xxx.aaa.zzz can resolve to an IP. You can also enter DNS names directly without a DHCP entry by just having a DNS override (e.g. in Unbound).

So, how did you register the DNS names and BTW: which DNS service did you use? DNSmasq or Unbound? You did not tell.

2. In order to be able to actually resolve the names, you must have a DNS service running and allow your networks clients to access it.
Which is it and can you reach it (a good test would be "nslookup xxx.aaa.zzz <ip-of-opnsense>".

3. The best way of telling your clients where to ask for DNS names and with what "search domains" (e.g. aaa.zzz) to use would be DHCP.
So: do your clients know the correct DNS server IP and do they look for the correct domain names if you only ask for "xxx"?

You see: "no luck" is one thing - as of now, we do not even know where to start.

"Does not work" is by no means a specification by which anyone can help you. Maybe you should look at this.

Use a different regional server. Yours are probably still being upgraded such that the files are not all there completely.

Yup. 11 lingering files for me, as well. Intermediately, new ones get created and then deleted again.

BTW: I could not even use the rm command, because with >36.000 files, the command line was too long.

The rule you showed above said otherwise, hence why I asked.

I saw this, too. The culprit may be the HomeAssistant OPNsense plugin. In its default settings, it scans every 30 seconds.

What about the S/SA flags? If the packets do not match those, they will be dropped. Compare the working and non-working rules in /rmp/rules.debug.

The I226 drivers work just fine. There are also device with 4x I226 and 2x Intel 10GBps SFP+, which also work fine. The N3x5 variants get a lot hotter than the N1x0, so you probably want active cooling or consider one of the latter.

You can also buy these boxes from Protectli with warranty, but with a premium.

Well, I am nearly lost for words...

conversational firewall management

I mean, really? I can imagine my future self referring you back to this when things will have gone awry and saying "Entirely avoidable.".

Not to insult you, but you must be one of the guys who turn on the AI auto-pilot in your car and then read a book during the ride.

P.S.: I never saw that purported upgrade problem happening since starting to use OpnSense back in 2023 (and counting).

https://forum.opnsense.org/index.php?topic=42985, Punkt 29.

Warum nutzt Du nicht die OpnSense als zentralen Zeitserver? Ich definiere den Zeitserver per DHCP und mache zusätzlich noch einen Redirect to Port 123. Ich möchte doch, dass alle Devices im Netz wenigstens die selbe Zeitbasis nutzen.

It should work for all devices on 40_IOT, because it redirects all DNS requests from your 40_IOT interface that are not directed to the interface IP of your OpnSense to the localhost DNS service.

This specific rule does not need an exclusion for 127.0.0.1, because no requests for a target IP 127.0.0.1 can ever reach your 40_IOT interface. Requests for "40_IOT address" are most probably meant for the local OpnSense DNS service, anyway. In this specific case, you could even set the destination address to "any", in which case requests for "40_IOT address" would get redirected at 127.0.0.1, which usually is the same service (unless your bindings are strange).

Say you configure OpnSense to use 127.0.0.1 as the DNS server (which in some configurations, happens automatically).

Then, you try to resolve www.google.com. Thus, a DNS request gets send to 127.0.0.1:53. If your redirect rule lacks !127.0.0.1 as the target, ALL DNS requests will in fact get redirected at 127.0.0.1. This happens to be the very same request as before, so it again gets redirected at 127.0.0.1, ad infinitum.

The moral of the story is: You only want to redirect all requests to 127.0.0.1 that are NOT YET directed at 127.0.0.1 in the first place.

P.S.: I do not even know if the internal logic of the filtering somehow avoids such problems - I would still do it just for good measure.

...and there we go again. Yes, there may be circumventions. We can discuss that on a theoretical level just endlessly. Once you are in the actual situation your Unifi main switch dies and you need to replace it: Just try. Been there - done that.

Out of experience: You did not consider some things, say:

1. Maybe your Unifi Network Controller is on a VM on a Proxmox VE host which has a trunk port to your switch.
2. Maybe your OpnSense is also on a trunk port and has firewall rules to allow your management PC's MAC from the LAN to access the management VLAN.

Shall I continue? After the fact I can tell you the actual restoration workflow contains way more than the steps you imagine now.

It is a matter of a downtime of minutes vs. (at the very least) hours, trust me.

Therefore, I keep the management LAN untagged - the switch will then automatically connect to the Unifi Network Controller. Your only concern will be to reach the management LAN to make the UNC adopt the new switch and configure it.

1. The !127.0.0.1 is only to make sure no endless loop gets created if a request is initially directed at 127.0.0.1.
2. With the old rules, you had to do it like this. Since not everyone already can or does use the new rules (e.g. me), I will keep the instructions like this for a while.

Matter-of-fact, for me, the maturity of the new firewall rules, including the migration mechanism and the undocumented effects on resulting priorities ist still too low to switch, but YMMV. Personally, I will wait until the old rules will get eliminated.

Weil es irgendwie unlogisch ist, sich eine Kaufberatung mit Rahmenvorgaben zu holen, sich dann alles anzuhören um dann alles in den Wind zu schlagen und eine Entscheidung zu treffen, die nicht die größtmögliche Flexibilität ermöglicht.

Der Minix Z100 Aero hat aus meiner Sicht diverse Nachteile beim Einsatz als Firewall-Box (und darum geht es doch wohl immer noch laut OP):

1. Aktiv gekühlt - diese Lüfter gehen über kurz oder lang kaputt und man bekommt kaum passende als Ersatz.
2. Nur zwei Realtek-NICs (und dann sogar noch einer mit 1 Gbps) mit geringer Kompatibilität zu pfSense und OpnSense.
3. Die aktuell angebotenen Versionen haben nur 8 GByte RAM - für die Ausweichlösung mit Proxmox ist das arg wenig, 256 GByte SSD ist auch mau dafür, ganz abgesehen davon, dass ich für Proxmox immer eine SSD mit hohem TBW-Wert nehmen würde, die hier garantiert nicht drin ist.

Mit Flexibilität meine ich: Für beide Varianten - Bare-Metal oder virtualisiert - sind die üblichen China-Modelle mit 4x I226V eine super Basis. Und die gibt es auch in Deutschland mit Garantie zu kaufen.