Messages

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.

I had a typo, of course I meant 192.168.3.1/24. That would be the management network on VLAN 1 (untagged).

The UDM Pro would also be on VLAN 1 with 192.168.3.2/24, gateway = 192.168.3.1 (OpnSense). The other VLANs can be defined, but the UDM Pro does not enable DHCP for any of those. Thus, the port it connects to on the switch must be a trunk with untagged VLAN 1 and all VLANs. That is just because the UDM Pro still ist the network controller for the APs and switches.

I like to have the third octet of the network be set the same as the VLAN, so VLAN 10 would be 192.168.10.0/24 a.s.o. The management network is an exemption, because it has VLAN 1 (= untagged).

The OpnSense has two legs, one untagged on one port and one as trunk with all the other VLANs. You can connect that second leg as trunk to the switch as well (it is only that the "parent" NIC for all the VLANs will not be configured on OpnSense.

You will have to define a PASS ALL rule for all VLANs (including MANAGEMENT) to "any" first, to see all of those get internet access.
Of course, this will enable to access any other VLAN, first. Then, you can put block rules before the "PASS ALL" rule to inhibit access from any VLAN as you wish. Usually, that would mean than you LAN (VLAN 10) will either not have any block rule at all or only to the management VLAN.
You can also define specific MAC or IP aliases on your LAN to pass to the MANAGEMENT VLAN.

For most other VLANs, you will most probably want a blocking rule including the "VLAN net"s (there are pre-defined network range aliases for any OpnSense network interface) of all other local VLANs or even a self-created alias including all RFC1918 networks. This is safe, because local traffic in any local VLAN does not pass OpnSense, so it does not block traffic for itself.

Of course, that RFC1918 block rule would also block access to OpnSense services, like DNS, NTP and others. Thus, you will have to specify rules to allow those types of traffic even before your "block RFC1918" rule.

Typically, what you will end up with is a set of rules like these on each interface:

1. Allow specific traffic to OpnSense services (like NTP or DNS).
2. Allow specific clients to do "anything they want" (i.e. your management clients).
3. Block access to specific local networks (like the management network or all other VLANs or even RFC1918).
4. Allow to "any" (i.e. internet access).

How you do that is up to you, however, when you first start out with the "ALLOW ANY" rules as depicted, everything should work and you can set limits from there. Note, that you will find many discussions here where people fight over the pros and cons of one way or the other to do it (e.g. "block RFC1918 rule before allow any" or "allow only to !RFC1918.", combining #3 and #4 above). Even "RFC1918" as an alias is debatable, see: https://forum.opnsense.org/index.php?topic=46094.0

No, I meant DEBUG is what most people call "management network", not to connect WAN to your switch.

To be exakt: Unifi wants its management network to be "VLAN 1" (= untagged), and you can define any user networks as VLANs, yet OpnSense does not like mixing tagged and untagged networks on the same NIC. So, you could use your DEBUG network of 192.168.3.1/24 as management network on VLAN 1 (untagged) with one separate physical of OpnSense connected to that via the switch and another NIC with all of the "real" (= tagged) VLANs. WAN is still on a separate NIC connected to your OpnSense only.

By doing this you avoid using 192.168.1.0/24 altogether, BTW. This might come in handy once you find that your DSL modem or ONT uses 192.168.1.1/24. If you did use that for your management network (or any other (V)LAN, you would have a hard time to access the ONT web interface on another OpnSense NIC.

And sure, you turn DHCP off on your dream machine and use DHCP only from your OpnSense. This will also assign all Unifi devices their IPs, except maybe for your dream machine, which presumably has a static IP that you must assign yourself (like 192.168.3.2/24 in this example).