Messages

[inkl.]

Sooooo. Ich komme nochmal auf das Thema zurück, weil ich jetzt die ultimative Lösung für das Problem "Unifi mit OpnSense" gefunden habe:

Technisch ist es offenbar so, dass Unifi "intern" das VLAN 1 nutzt, wenn Ports einfach als Access Ports aufgeschaltet werden. Dabei ist eben VLAN 1 das "Native VLAN" und VLANs stehen auf "Block All". Das "Native VLAN" wird einfach egress vom Tag 1 befreit und ingress wird das Tag 1 hinzugefügt. Dadurch ist das Standard-VLAN 1 an Access Ports verfügbar und sonst nichts. Will man ein anderes VLAN an diesem Access Port nutzen, nimmt man eben das als "Native VLAN".

You cannot view this attachment.

Der Normalfall für Trunk Ports (also z.B. andere Unifi Switche oder APs) ist, dass "Allow All" für VLANs genutzt wird, und weiterhin das VLAN 1 das "Native VLAN" ist - obwohl man das im Netzwerk gar nicht manuell auswählen kann: man lässt das Feld dann leer:



und nur in der Übersicht der Netzwerke steht unter VLAN ID dann die 1:

You cannot view this attachment.

Das Port-Profil dazu sieht etwa so aus:

You cannot view this attachment.

Somit wird das Native VLAN an solchen Ports untagged angeboten, zusätzlich werden aber alle VLANs entsprechend verteilt - bis auf VLAN 1, denn das Tag dafür wird egress entfernt und ingress hinzugefügt.

Hierdurch ergibt sich das beschriebene "Problem": Unifi rechnet damit, dass das Management VLAN untagged an allen Ports zur Verfügung steht, was das einfache Anlernen neuer Unifi-Devices ermöglicht. Weitere VLANs werden dann getaggt.

OpnSense hingegen hat bekanntlich in bestimmten Bereichen Probleme mit dem Mischen von tagged und untagged VLANs auf dem selben physischen Port.

Zwar kann man auch bei Unifi das Management VLAN auf ein getaggtes VLAN legen, dazu müssen die Geräte aber erstmal worden angelernt sein - ein typischer Catch22.

Die Lösung ist eigentlich ganz einfach, ähnlich wie Patrick es beschrieb: Man kann nämlich auch ein Profil für Trunk Ports anlegen, bei dem das "Native VLAN" = "none" ist. Dann findet einfach kein egress/ingress-Tagging mehr statt - aber das Endgerät kann selbst jedes VLAN nutzen - inkl. VLAN 1. Wenn man dann das Management-Interface in OpnSense als VLAN 1 anlegt und das physische Parent-Interface nicht konfiguriert, funktioniert alles auf einmal: Unifi behandelt die Ports, wie es will und OpnSense taggt alle VLANs.

You cannot view this attachment.

Ich beschreibe jetzt absichtlich NICHT Schritt-für-Schritt, wie man den Übergang schafft, ohne sich dabei wegzuschießen, aber als Hinweis:

1. Man sollte sich zuerst das VLAN 1 in OpnSense anlegen und sicherstellen, dass man mindestens Zugriff auf die Konsole hat (oder Layer-2-Zugriff auf ein anderes Netzwerkinterface, als das untagged), um dort agieren zu können.

2. Man sollte ebenfalls dafür sorgen, dass man Layer-2-Zugriff auf die Unifi Console hat, der nicht von der OpnSense abhängig ist. Zuerst sollte man sich ein neues Trunk Profil mit "Default VLAN" = "none" und "Allow All" für den OpnSense-Port bauen, auf das man dann umschalten kann.

3. Vorsichtig, wenn man die Assigments der Interfaces ändert - der DHCP-Server bekommt die Änderung nicht mit, den muss man selbst neu starten (oder OpnSense rebooten), anderenfalls verlieren die Unifi-Devices nach Ablauf des Leases die IP-Adressen und sind nicht mehr erreichbar.

Das ist notwendig, weil man nacheinander beide Ports (am Switch und an der OpnSense) umschalten muss - wenn etwas schiefgeht, kann man sonst nicht mehr zurück (been there, done that).

That is basically the OPs question. I know that the DDNS feature has been added to Kea recently, but I think that Unbound has no RFC2136 support, so you really need anther DNS server that supports it, like BIND, which makes the setup quite complex.

We discussed this back and forth already and not an exact answer to your question, but:

IMHO, the easiest way is to just use Kea DHCP static reservations, where the names of the host entries can directly be used in Unbound directly when you check "Register DHCP Static Mappings". That way, there is no need for any additional DNS resolver and you can control which names are being registered, which cannot be done if the hosts themselves present their names.

The only disadvantage I can see is that you have to create static reservations for all hosts you need to be resolvable, because there is no equicalent of ISC dynamic DHCP bindings in OpnSense's implementation of Kea DHCP yet.

However, I need exactly those hosts to have static IPs as well, so I do not miss anything. Also, more often than not, I also want to have aliases for hosts, sometimes to have different services on the same one, so I need to configure those in Unbound anyway.

Ja, klar. Bei Reverse Proxying muss man schon etwas tun, damit das Backend a. die richtigen Infos sieht und b. sich selbst für den "externen" Server hält, z.B. für absolute Redirects oder Pfad-Umschreibungen. Da gibt es Details, die nicht mal im Tutorial von @TheHellSite stehen, z.T. sogar anwendungsspezifische Regeln für NextCloud.

Was ich nicht ganz kapiere: Was musst Du den Containern beibringen?

Wenn Du mit HAproxy als Reverse Proxy arbeitest, macht der doch die TLS-Terminierung inkl. der Beantragung der ACME-Zertifikate?

Wozu dann also Zertifikate auf den Backends? Wenn das wegen TLS-Verschlüsselung benötigt wird, mache ich das genauso wie Viragomann, nämlich mit eigener CA, wodurch das Gezauber mit Übertragung von Zertifikaten vermieden wird. Andererseits ist das oft gar nicht notwendig, z.B. weil die Backends in einer DMZ eingesperrt sind, auf die sonst nichts Zugriff hat. Deswegen arbeite ich auf den Backends meist unverschlüsselt.

Aufgrund der Level 7 Übersetzung im Proxy muss man ja die Client-Infos sowieso per Header übertragen, dann hat man auch die richtigen Infos über eingesetzte Mechanismen usw. für die Backend-Protokollierung.

It seems that this problem still exists. When I want to start the daemon, I get the same bug when I try to forward WoL packets.

I found that "/usr/local/etc/rc.d/os-udpbroadcastrelay start" starts this internally:

Code Select Expand

# /usr/local/sbin/udpbroadcastrelay --id 3 --dev ix1_vlan4 --dev ix1_vlan10 --port 9 --multicast 255.255.255.255 -f -d
udpbroadcastrelay v1.3.00 built on Jan 14 2026 03:29:25
Debugging Mode enabled
ID set to 3
Port set to 9
Forking Mode enabled
ID: 3 (DSCP: 3, ToS: 0x0c), Port 9
ix1_vlan4: 26 / 192.168.4.1 / 192.168.4.255
ix1_vlan10: 25 / 192.168.10.2 / 192.168.10.255
found 2 interfaces total
IP_ADD_MEMBERSHIP:              192.168.4.1 255.255.255.255
IP_ADD_MEMBERSHIP on rcv: Invalid argument

For me, this affects the daemon as well.

You do not say which Optiplex this is, but know that the X550, especially the 2-port variant is getting VERY hot. These and the previous X540 models are meant for rack server use and having no active cooling, so they may drop out after a while.

Also, it seems to have a hard time on handling auto-negotiation at Nbase-T speeds and with some ISP modems. There are firmware upgrade available and also, you need RSS enabled to use the full bandwidth.

Use the forum search with "X550" and you will see...

Now that is really strange:

Code Select Expand

# dmesg | grep -i microcode
[1] CPU microcode: updated from 0x1d to 0x24000026

# sysctl -a | grep hw.model
hw.model: Intel(R) Celeron(R) N5105 @ 2.00GHz


I can only imagine that your BIOS already has version 0x24000026 included. FWIW, the current package has the correct update for the N5105.

https://forum.opnsense.org/index.php?topic=42985.0, Punkt 15.

In that case, the patch is obviously not yet contained in the package. I know for a fact that the current version for that CPU is 0x43a under Linux:

Code Select Expand

# cat /proc/cpuinfo
...
processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 154
model name      : 12th Gen Intel(R) Core(TM) i3-1215U
stepping        : 4
microcode       : 0x43a


# dmesg | fgrep microcode
[    0.964793] microcode: Current revision: 0x0000043a
[    0.964796] microcode: Updated early from: 0x00000434

So, even if FreeBSD still has an older variant, it sure is not 0x432, which must be the initial one or one from the Protectli BIOS.

See: https://forum.opnsense.org/index.php?topic=42985.0, point 3. The reason you do not see any firewall drops is that you do not have logging enabled for the default "drop all" rule.

Disable ASPM, maybe?

So, wie es aussieht, ist mindestens einer der beiden NICs ein Realtek, dafür gibt es ein Plugin (os-realtek-re) mit einem verbesserten Treiber. Teilweise haben diese Geräte unabhängig vom eingesetzten NIC mit Sleep States Probleme, was das Knacken erklären könnte. Man kann ASPM per hw.pci.enable_aspm=0 abschalten.

Dazu die üblichen Verdächtigen: RSS einschalten..., siehe hier: https://forum.opnsense.org/index.php?topic=42985.0

1. It seems to be a somewhat hard task and I doubt that Deciso will re-enact the efforts that Netgate has put into it. Maybe Netgate will at some point make their work public, but for the time being, it is a discriminating feature (even from their own CE product).

2. IDK, maybe that would depend on the specific CPU and which algorithm you choose.

Using an aggressively short validity timespan sure helps, however, you should probably try setting "Deprecate Prefix" to on. That way, radvd will announce a zero lifetime upon restart for the old prefix.

Note however, that this has ill effects when a prefix is being reused - your clients will not accept it any more. IPv6 was never designed for dynamic prefixes, even less for failover situations with different prefixes. Thus, you will die on the road you choose.

Probably the only way to go would be to use NAT66 in order to keep local IPv6 ranges constant, but do not bother using ULAs. There are lots of threads about that, take a look around.