"Recent posts
#1
Hardware and Performance / Re: Sanity check for N100 / i2...
Last post by dirtyfreebooter - Today at 03:28:26 AMwhen RSS is enabled,
the kernel will override dispatch and always make it hybrid (so you can leave that tunable out if you are enabling RSS), you can verify my claim with netstat -Q
---
i tested a protectli VP2440 with N150 with i226 with Zenarmor and i was able to get 2.5 gbps
using the x710 10g interface without Zenarmor, i was able to get 9.46 gbps
so i would think that N100 could easily do 2 Gbps without IDS/IPS.
the tunables i used were (including installing the Intel Microcode Plugin):
note that i think the intel microcode plugin + vm.pmap.pcid_enabled = 0 is pretty much the gold standard with the N100/N150/N305 cpus, as they have a bug in the freebsd kernel otherwise...
i did update my i226 firmwares to v2.32 tho i dont think that mattered.
Code Select
net.inet.rss.enabled = 1the kernel will override dispatch and always make it hybrid (so you can leave that tunable out if you are enabling RSS), you can verify my claim with netstat -Q
Code Select
net.isr.dispatch = hybrid---
i tested a protectli VP2440 with N150 with i226 with Zenarmor and i was able to get 2.5 gbps
using the x710 10g interface without Zenarmor, i was able to get 9.46 gbps
so i would think that N100 could easily do 2 Gbps without IDS/IPS.
the tunables i used were (including installing the Intel Microcode Plugin):
Code Select
dev.hwpstate_intel.0.epp = 10
dev.hwpstate_intel.1.epp = 10
dev.hwpstate_intel.2.epp = 10
dev.hwpstate_intel.3.epp = 10
dev.igc.0.fc = 0
dev.igc.1.fc = 0
hw.acpi.cpu.cx_lowest = C2
hw.ibrs_disable = 1
net.inet.tcp.soreceive_stream = 1
net.isr.bindthreads = 1
net.isr.maxthreads = -1
vm.pmap.pcid_enabled = 0
vm.pmap.pti = 0
note that i think the intel microcode plugin + vm.pmap.pcid_enabled = 0 is pretty much the gold standard with the N100/N150/N305 cpus, as they have a bug in the freebsd kernel otherwise...
i did update my i226 firmwares to v2.32 tho i dont think that mattered.
#2
26.1, 26,4 Series / Attempting to use IPv6 with ma...
Last post by pasha-19 - Today at 03:21:35 AMI have successfully setup IPv6 DHCP server using both DNSmasq and Kea DHCPv6 (different interfaces/vlans not at the same time). Both assign the desired managed address and two more preferred addresses. However my windows PC in addition to my managed address shows addresses with my ULA prefix and I guess a MAC or DUID generated last 4 hextets for the address. The Router addresses given are IPv6 Link Local addresses (fe80::/10). I am attempting to write firewall rules and acl rules on a switch. These non-managed addresses using my prefix and the link local addresses used after DHCP has assigned a managed address are preventing me from knowing about my device based on my established subnets based on managed DHCP and static address assignments. I know a link-local address is part of the IPv6 DHCP process and that is not my problem. I was hoping that after the DHCP assigned a managed IP address or manual static assigned IP addresses by me; the subsequent traffic can hopefully be forced to use the managed address and not link-local or the mac/duid generated value preceded by my chosen ULA address based prefix a /64. Does anyone know how to encourage the use of my managed addresses over the other UNMANAGED addresses? Is this possible, does anyone have any suggestions?
#3
Hardware and Performance / Re: Sanity check for N100 / i2...
Last post by Ozymandias - June 06, 2026, 11:39:10 PMPeaks at about 40%.
iperf3:
1.48 Gbits/sec from the router to a public server.
1.28 Gbits/sec from Win11 to the same public server.
1.60 Gbits/sec from Win11 to OPNsense iperf3 server.
2.37 Gbits/sec from Win11 to Unraid (N95) iperf3 server.
iperf3:
1.48 Gbits/sec from the router to a public server.
1.28 Gbits/sec from Win11 to the same public server.
1.60 Gbits/sec from Win11 to OPNsense iperf3 server.
2.37 Gbits/sec from Win11 to Unraid (N95) iperf3 server.
#4
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by yourfriendarmando - June 06, 2026, 11:05:53 PMHi
I didn't realize the text was that mangled, it is difficult to express many FW rules at once.
I replaced it with a screenshot attached to that post.
I added the missing local_link alias referenced in this guide
I also added the comprehensive list of Dangerous ports that I prevent accessing out on the internet.
I didn't realize the text was that mangled, it is difficult to express many FW rules at once.
I replaced it with a screenshot attached to that post.
I added the missing local_link alias referenced in this guide
I also added the comprehensive list of Dangerous ports that I prevent accessing out on the internet.
#5
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by allan - June 06, 2026, 10:38:39 PMGood point. If I am considering a workaround, I should at least look at other options as well. Thanks for that suggestion.
#6
German - Deutsch / Re: Trunk zwischen OPNSense un...
Last post by meyergru - June 06, 2026, 10:36:21 PMSooooo. 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).
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).
#7
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by Monviech (Cedrik) - June 06, 2026, 10:33:26 PMWhen using KEA I would rather go with Bind like the OP of this thread plans to do. They're like brothers in arms, ISCs own tooling (Stork) combines them both as well.
#8
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by allan - June 06, 2026, 10:24:27 PMQuote from: Monviech (Cedrik) on June 06, 2026, 10:17:38 PMBut the Unbound DNS registration for dynamic hosts will most likely not come, only DHCP reservations are synced with Unbound -> which should actually be sufficient for most setups.
I saw a discussion where someone got a script to do that. It is likely the direction I will go, but I figure I'll ride this ISC horse until the sun sets. :)
#9
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by Monviech (Cedrik) - June 06, 2026, 10:17:38 PMWe just recently added dynamic prefix delegation to KEA in 26.1.9, was one of the roadmap items I worked extensively on.
But the Unbound DNS registration for dynamic hosts will most likely not come, only DHCP reservations are synced with Unbound -> which should actually be sufficient for most setups.
So overall ISC DHCP should be able to be cleanly replaced now.
But the Unbound DNS registration for dynamic hosts will most likely not come, only DHCP reservations are synced with Unbound -> which should actually be sufficient for most setups.
So overall ISC DHCP should be able to be cleanly replaced now.
#10
26.1, 26,4 Series / Re: Kea + Unbound + Bind for l...
Last post by allan - June 06, 2026, 10:12:42 PMPrefix delegation and dhcp registration into Unbound is why I am still running the ISC dhcpd. Aside from my home lab, Apple's HomeKit uses prefix delegated IPv6 addresses. I guess it assigns IPs to downstream nodes.
