Messages

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.

If that is true, RSS mode should fix it.

You noticed the smiley?

There have been discussions back and forth between switching the Unifi management VLAN from untagged (VLAN 1). I once did that and dialled everything back because you then have problems adopting new devices as they only respond on the untagged network. You would need a specifc "initial provisoning" port on your switch for that.

Altogether, I found that the best way (for me) is to stay with Unifi's default (i.e. having untagged/VLAN 1) as the main management network and have all user traffic on different VLANs. The only problem is that the untagged network is being used at all and this can be solved by using two physical interfaces on OpnSense. I like to have multiple interfaces connected to the switch anyway, to have more bandwitdh for inter-VLAN traffic.

Unifi works just fine with IP ranges different from 192.168.1.0/24 and I like to keep that free for ONT/modem access.

[both]

That is what I meant: Sure, it causes no immediate conflicts, iff the MACs are different. However, you must set the aliases on both sides in advance, not just one. Otherwise, a fail-over would null the existing settings.

While this is a nice trick, would it not cause problems when the configuration gets synchronized?

I use it with M-Net. I know that Telekom and their resellers does not work with 1500 bytes MTU.

RTP wäre ja erst der zweite Schritt - das würdest Du dann ggf. merken, wenn Du nichts hörst oder nicht gehört wirst.

Der erste Schritt wäre SIP-Registrierung. Und ja, die Logs vorher sahen ja auch so aus, als ob die Pakete rausgehen aber nichts zurückkommt. Daher meine Frage mit der Priorität der Outbound NAT Rules. Du kannst ja mal auf dem WAN Interface lauschen, ob da etwas von den SIP-Servern zurückkommt. Man kann auch das Logging für die Default Block Regel aktivieren, um zu sehen, ob da was ist, was geblockt wird.

Keine Idee...