Messages

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.

Aha. Laut dieser Dokumentation musst Du den richtigen DNS Mode wählen:

https://documentation.grandstream.com/knowledge-base/dp750-administration-guide/?asp_highlight=DP750&p_asid=2#post-22767-_Profiles_Page_Definitions

Die SIP-Server-Einstellungen werden demgemäß verwendet. Möglicherweise steht das aktuell auf "A Record" statt auf "NAPTR/SRV".

Es gibt da noch viele weitere Einstellungen, z.B. "NAT Traversal" und "SIP Transport".

Das sieht stark danach aus, als ob er den DNS nicht auflösen kann:

Code Select Expand

DP750 [EC:74:D7:02:F3:ED] [1.0.21.31]lookup:DNS.cc(507)->Failed to resolve DNS A query for host: tel.t-online.de
Stimmt die Konfiguration des Grandstream in Bezug auf den DNS-Server vielleicht nicht? Bekommt er den Technitium-Server per DHCP?

Oder ist der DNS-Server nicht erreichbar? Firewall dazwischen?

Wenn Du schon NAPTR und SRV kennst, weißt Du, dass die Abfolge wie folgt ist:

1. Der NAPTR-Eintrag liefert Dir die verfügbaren Services:

Code Select Expand

# nslookup -query=naptr tel.t-online.de
Non-authoritative answer:
tel.t-online.de naptr = 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de naptr = 20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de naptr = 30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.

2. Die Abfrage der entsprechenden Records bringt Dir die Namen und Ports der möglichen SIP(S)-Server, die ggf. regional zuständig sind, z.B.:

Code Select Expand

# nslookup -query=SRV _sips._tcp.tel.t-online.de.
Non-authoritative answer:
_sips._tcp.tel.t-online.de      service = 20 0 5061 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de      service = 10 0 5061 ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de      service = 30 0 5061 lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.

# nslookup -query=SRV _sip._udp.tel.t-online.de.
Non-authoritative answer:
_sip._udp.tel.t-online.de       service = 20 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 30 0 5060 lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 10 0 5060 ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de.

# nslookup -query=SRV _sip._tcp.tel.t-online.de.
Non-authoritative answer:
_sip._tcp.tel.t-online.de       service = 20 0 5060 lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de       service = 30 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de       service = 10 0 5060 mue000-l01-mav-pc-rt-001.edns.t-ipnet.de.

Manche ältere SIP-Devices können NAPTR und SRV noch nicht - das Grandstream laut Dokumentation schon. Bei solchen älteren Geräten würde ich versuchen, direkt den SIP-Server für UDP als SIP-Server einzutragen.

Um Probleme in diesem Bereich vorab auszuschließen, würde ich eine Portweiterleitung für die RTP-UDP-Ports 5004, 6004, 7004 und 8004 auf das SIP-Gateway eintragen - das wird aber wahrscheinlich nicht gebraucht. Meistens läuft RTP per UDP, nicht per TCP.

Statische Ports für die Outbound NAT des Gateways sind auch hilfreich.

Dann könnte noch SIPS ein Problem sein, wenn das Grandstream das versucht, aber aus irgendwelchen Gründen nicht kann.

Wenn Du das Ganze debuggen willst, solltest Du die DNS-Anfragen und den dann folgenden Traffic mitschneiden, dann kannst Du sehen, ob das Gateway die Namensanfragen korrekt macht und wie/ob es daraufhin die Verbindungen aufzubauen versucht.

Teilweise brauchen diese Geräte auch noch STUN, um herauszubekommen, welche externe Adresse sie haben - diese wird in den SIP-Nachrichten ja mitgegeben, damit die Gegenseite weiß, wohin die RTP-Pakete gesendet werden müssen. T-Online scheint zwar alles mit IPv4 abzuwickeln, hat aber andererseits auch kein CG-NAT. Solange Du nicht selbst einen vorgeschalteten Router einsetzt, sollten also auch keine Probleme per Doppel-NAT auftreten.

Wenn Du eine Fritzbox hast, kannst Du ja auch die probieren - die kann auf jeden Fall NAPTR usw.

IPS mode is a lot more taxing than just routing and firewalling. And RSS mode is not applicable, because IPS is inherently single threaded, see the note here: https://docs.opnsense.org/troubleshooting/performance.html

The hardware settings will do next to nothing, if they work at all. Some seem to work first, with some subtle problems coming up later.

So, essentially, the answer is: Use a CPU with more single-thread punch.

@mooh is correct abount VLAN 1 (untagged) as being the Unifi management network by default. It can be done differently, but it is hard to do.

From your first post, I assumed that your DEBUG network is VLAN 1 (untagged) connected to another port on the switch. That is what I meant by "you did well to separate all VLANs on one physical interface and untagged DEBUG on another". Actually, you have the management network completely separated, which will most probably not work.

Of course, that assumes you actually connect that OpnSense port to an untagged port on your switch. By doing that, you have all tagged ports in OpnSense on one physical port and the untagged port on another, thereby following the rule "do not mix tagged and untagged VLANs on the same port".

Did you actually create firewall rules (see #1 from my previous post)? Or do you expect that it works without them (hint: it doesn't)?

1. You need to create firewall rules for each but the first (V)LAN (this already has an "allow any -> any" rule).
2. You should not mix tagged and untagged VLANs on the same interface (it causes all kinds of subtle problems). Unifi does this and even prefers it, you did well to separate all VLANs on one pyhsical interface and untagged DEBUG on another.
3. Be careful / do not use VLAN 1: Many manufacturers, including Ubiquiti, use that to denote "untagged". For some, it it only how they handle the untagged (V)LAN internally, others handle VLAN 1 and untagged the same. If you do not want to think about this, simply do not use it.

You can still use ISC, even with the current OpnSense release. It it just not well supported, since officially, it is EOL and therefore moved into a plugin.

Also, Kea is not the preferred path that Deciso supports. That would be DNSmasq and it seems to support much of what you are aksing for.

I still like Kea better and hope that the situation will get better when more native Kea features would be integrated into OpnSense, like DNS registration for clients or generic DHCP options. If you lack specific features, open a feature request on Github or see if there already is one open.

Did you try disabling "Use graphics acceleration when available."?