Messages

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

Or got the preferred route and handle both certificate prolongation and TLS termination on OpnSense itself via ACME.sh and a remote proxy like Caddy or HAproxy. There are guides for both of them in the tutorial section. This has the benefit of not needing different ports for different services, because the reverse proxy can differentiate them by name.

Du hast die Reihenfolge der NAT-Regeln schon richtig? Die kann man ja ändern im Hybrid-Modus. Deine speziellen Static-Port-Regeln müssen ja vor den normalen greifen.

Whaaat? Daran verstehe ich zwei Dinge nicht:

1. Wieso kommuniziert die IP Deines SIP-Gateways mit 10.x.x.x?
2. So wie es aussieht, kommen von den SIP-Servern von T-Online keine Antworten zurück.

Entweder verlassen die Pakete Deine Firewall nicht (korrekt), weil z.B: die Outbound NAT Regel fehlerhaft ist oder die Antworten werden irgendwo nicht durchgelassen, was aber seltsam wäre.

[Right]

Right ... and you should enable DHCP on OpnSense for every connected local (V)LAN.

Since we are covering basic networking aspects now: Are you quite certain that OpnSense is right for you? ;-)

Maybe you should start reading here, because that is literally point 1 in that article. By deciding to "keep 192.168.1.x", you deliberately chose to not use a configuration pattern I explained, which by itself guarantees that such things do not happen. You will find that more often than not, there are best practices for a reason.

I do not use L3 routing on my switches, even if they had it. I did not even know how Unifi does that. With their consumer-level switches, they do not offer it, also, with smaller networks, I prefer to have all routing controlled by OpnSense itself.

L3 switching is something that IMHO is relevant only for enterprise-grade installations. Everything I depicted here is strictly L2 on the switches.