Messages

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

[at all]

In fact, I would never use that subnet at all for the reasons explained here.

Gibt es da irgendwelche Test-Tools wie ping o.ä.? Ist das Gerät in einer DMZ? Kannst Du testen, ob überhaupt ausgehender Traffic zulässig ist?

Im Zweifel einen PC dort anschließen und erstmal Netzwerk-Basics testen. Oder eben, wie gesagt, Traffic mitschneiden. Eine Alternative ist, ausdrückliche FW-Regeln für den erwarteten Traffic anzulegen mit Protokollierung und dann ins Live-Log zu schauen.

Dann würde ich testweise mal A-Record anschalten und einen der SIP-Server, z.B. hno002-l01-mav-pc-rt-001.edns.t-ipnet.de. mit SIP per UDP Port 5060 hart eintragen.

Unabhängig davon würde ich schauen, ob der DNS-Service wirklich richtig liefert oder testweise einfach den Unbound von OpnSense nutzen.
Du kannst ja das Device auch statisch konfigurieren - es muss ja nicht den "normalen" Technitium-Service nutzen.