Messages

[You]

So you are saying that when I measure iPerf3 speeds between OPNsense and a Client that the speed will always be lower than between two any other type of Clients on the same subnet ?!

Yes, of course, just because when OpnSense is itself involved, iperf3 runs on top of the actual routing. Well, "on the same subnet" is incorrect, of course, because OpnSense would not be involved at all if the traffic were between two clients on layer 2.

Ofcourse you will always have to measure with as much threads as possible and sometimes even raise the window size and stuff like that... :)

You may know, but the OP did not state how exactly the measurements were taken, which is why I pointed it out again. RSS will not do any good with just one connection.

OK, but this clearly shows there is something wrong with the OPNsense Mini PC itself :

iperf3:
1.60 Gbits/sec from Win11 to OPNsense iperf3 server.
2.37 Gbits/sec from Win11 to Unraid (N95) iperf3 server.

These two should always be equal IMO :)

No:

1. There is a big difference between OpnSense routing sessions between different partners and OpnSense being the endpoint (the latter one is slower).

2. Since this is iperf, I also like to point out this article, point 10. I totally depends on how many TCP sessions you use.

Pulling these together, I see ~1.87 Gbps with iperf -P1 vs. 3.56 Gbps with iperf -P4 vs. 6 Gbps when OpnSense routes only.

Peaks 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.

I forgot to mention this :

I did update my i226 firmwares to v2.32 tho i dont think that mattered.

So have a look at this topic : https://forum.opnsense.org/index.php?topic=48695.0

Maybe that's the issue here...

I have tested the pure routing speed of N100-based OpnSense systems between VLANs to ~6 Gbps, so that should work.

NICE! :)

So far I only knew that a N100 can satisfy the 2,5 Gbps NICs out there as long as you don't use any IDS/IPS stuff.

W/R to the Windows 11 system, I have seen network drivers that needed tuning to exceed 1.5 Gbps on some network adapters, like disabling interrupt moderation, enlarge buffer sizes or changing flow of control settings.

He got good speeds to his DIY NAS :

2.37 Gbits/sec from Win11 to Unraid (N95) iperf3 server.

So I am guessing that's not the issue...

There are big timing differences between internet and local connections and also, the endpoints can behave differently, thus there can be any number of problems w/r to timing and/or buffering. The latter depends on which TCP algorithms are in use, such that flow control and buffering or interrupt coalescing can very well play a role.

If your connection was still on PPPoE, it would blame that, but it is not.

I have tested the pure routing speed of N100-based OpnSense systems between VLANs to ~6 Gbps, so that should work.

W/R to the Windows 11 system, I have seen network drivers that needed tuning to exceed 1.5 Gbps on some network adapters, like disabling interrupt moderation, enlarge buffer sizes or changing flow of control settings.

a. If your concern is to tighten security, you can use the client MAC to enforce rules.

b. If you aim to cause clients to use only the DHCPv6-assigned address for outbound access, you want to disable the "autonomous address-configuration flag" from RFC4862.

With Kea and RADVD, you must use "Managed" mode for the interface if you want DHCPv6, see this table. "Assisted" mode would allow for DHCPv6, but still allows the client to use privacy extensions. As I do not use DNSmasq, I cannot tell how to do it when it sends RAs by itself, but I guess it is documented.

c. You can also configure individual clients to disable privacy extensions completely.

That being said, I never tried nor verified it, because I actually want clients to use privacy extensions. If I want to control or limit a client, I do that regardless of the used IPv6 via its MAC (method a.). The only thing I can imagine is if you want to look into logs and identify the actual client involved.

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