"Recent posts
#1
General Discussion / VPN users loose their group me...
Last post by Andrey Kukhtinov - Today at 09:01:52 AMGood morning!
Some day we start having such a problem. At least some users loose their group membership.
We don't get them linked to LDAP or any other kind of external database. What could it be?
Some day we start having such a problem. At least some users loose their group membership.
We don't get them linked to LDAP or any other kind of external database. What could it be?
#2
25.7, 25.10 Series / Remote Elasticsearch Database ...
Last post by mlenje - Today at 08:21:59 AMA couple of days ago, I successfully installed the free version of Zenarmor on OPNsense v25.7.8. During the install, Remote Elasticsearch Database was an option that appeared during the wizard. I used it and setup Elasticsearch on a separate computer. Everything was working great.
Today, I upgraded the hard drives in my OPNsense box and did a clean re-install of OPNsense. Installing Zenarmor was the last step. During the install, Remote Elasticsearch Databas is not listed as an option, only local Elasticsearch or local SQLite.
Any thoughts on why it's not showing up as an option in the wizard?
Today, I upgraded the hard drives in my OPNsense box and did a clean re-install of OPNsense. Installing Zenarmor was the last step. During the install, Remote Elasticsearch Databas is not listed as an option, only local Elasticsearch or local SQLite.
Any thoughts on why it's not showing up as an option in the wizard?
#3
German - Deutsch / Re: IPSec und NAT
Last post by Lucas P - Today at 07:35:00 AMQuote from: JeGr on November 27, 2025, 10:06:22 PMDie Antwort hängt davon ab:Genau es ist kein VTI und die Remote hat nur das /28 Netz erlaubt. Zudem müssen nur Geräte aus dem 184.0 Netz in das 200.0 Netz, aber kein Zugriff in die andere Richtung.
* was die Remote Seite für eine IPsec Konfiguration hat: VTI oder normale Phase 2 Logik?
* was die Remote Seite für Remote Netz konfiguriert hat. Das bestimmt, was du selbst eintragen kannst.
Dann wird aber auf jeden Fall zusätzliche Security Policies für IPsec gebraucht, sonst würde der IPsec nur traffic von der /32 aufsammeln, du willst ja aber, dass der 184er/24 eingesammelt und via VPN verschickt wird. Daher muss das Ursprungsnetz als zusätzliche Policy rein und in die eigentliche Phase das "vorgegaukelte" /32 als lokal. Und dann natürlich noch nen NAT was ausgehend den Kram via IPsec auf die /32 umsetzt.
Dazu habe ich bereits eine zusätzliche Policy angelegt, dass auch mein 184.X Netz über die VPN geht. Diese greift auch, da ein Pacettrace auf dem IPSec Interface, die Pakete anzeigt, welche von dem 184.0 Netz in das 200.0 Netz gehen.
Weiter scheint das Outbound NAT für die Pakete nicht zu greifen.
Ich habe die NAT Regel bereits auf dem LAN, IPSEC oder WAN Interface angelegt:
Quelle: 192.168.184.0/24
Ziel: 192.168.200.0/24
MappingIP: 192.168.100.97/32
Klappt aber nicht. Muss die /32 IP zusätzlich als virtuelle IP auf das jeweilige Interface, falls ja welches?
Danke euch!
#4
25.7, 25.10 Series / OPNcentral: Provisioning Remot...
Last post by ews - Today at 07:28:12 AMHi,
we're using OPNsense Business with OPNcentral and would like to centrally push Remote Logging / Syslog settings to multiple firewalls.
I can't find any provisioning option for this.
Is this currently possible or planned?
Thanks!
we're using OPNsense Business with OPNcentral and would like to centrally push Remote Logging / Syslog settings to multiple firewalls.
I can't find any provisioning option for this.
Is this currently possible or planned?
Thanks!
#5
25.7, 25.10 Series / Re: Suricata IPS Mode
Last post by nicholaswkc - Today at 06:16:44 AMSuricata IPS mode on PPPOE is not permitted.
#6
Hardware and Performance / Traffic Shaper (Bufferbloat)
Last post by Boxer - Today at 05:44:05 AMJust wanted to show my appreciation, and my results, from following the docs that even a layman like me could understand. :)
The orange and purple arrows are the latency under load (bufferbloat)
First, my test results without any traffic shaping present
You cannot view this attachment.
My result after following the docs and using the advised -15% BW . I also have Control Plane shaping for ipv6-icmp which has 1mb up and down
You cannot view this attachment.
And lastly, my result after further tweaking (-5% BW) to take some of that bandwidth back
You cannot view this attachment.
It's a great result so thank you to all involved for making this so easy for me to understand and implement!
Cheers
The orange and purple arrows are the latency under load (bufferbloat)
First, my test results without any traffic shaping present
You cannot view this attachment.
My result after following the docs and using the advised -15% BW . I also have Control Plane shaping for ipv6-icmp which has 1mb up and down
You cannot view this attachment.
And lastly, my result after further tweaking (-5% BW) to take some of that bandwidth back
You cannot view this attachment.
It's a great result so thank you to all involved for making this so easy for me to understand and implement!
Cheers
#7
Virtual private networks / Re: VPN Site-to-Site + LDAP
Last post by Jhon Luke - Today at 04:10:01 AMOla ludarkstar99
Desculpe a demora pra responder
Sim é OPNsense nas duas pontas
Sim IP FIXO nas duas pontas
Sim Conexões de internet redundantes
vou te enviar meu e-mail no pv.
Desculpe a demora pra responder
Sim é OPNsense nas duas pontas
Sim IP FIXO nas duas pontas
Sim Conexões de internet redundantes
vou te enviar meu e-mail no pv.
#8
Hardware and Performance / Re: Suggestion for Bufferbloat...
Last post by OPNenthu - Today at 02:59:36 AMMy router CPU is Intel N5105 and I have OPNsense 25.7.8. I noticed that with Flow size 65535 the CPU usage as per 'top' was hitting 50% during the download portion of the Bufferbloat test. Reducing the flow size to 16384 per pipe, I got the usage down to 20-25%.
I also noticed that increasing this value from its default caused higher latency initially until I decreased the pipe BW (even lower than the recommended 85%). Not sure if that's just a side effect of the weaker CPU.
Result is very good, though. Consistent A+ when tested on a client running Windows. Drops to A when tested on same client with Linux, but still consistent.
@cookiemonster, the hard part is finding the sweet spot for the BW value. For me it's kind of a tipping point. There's a narrow range that if I deviate from, in either direction, then the latency starts to go up again. It's not enough to matter in practice (we're talking tolerances within A to B range) but enough to drive a perfectionist crazy. ;) I think my ISP makes it more difficult because cable modem speeds here fluctuate throughout the day, and the service is over-provisioned for short bursts so that I get 120% of the advertised speed initially before it levels out.
I also noticed that increasing this value from its default caused higher latency initially until I decreased the pipe BW (even lower than the recommended 85%). Not sure if that's just a side effect of the weaker CPU.
Result is very good, though. Consistent A+ when tested on a client running Windows. Drops to A when tested on same client with Linux, but still consistent.
@cookiemonster, the hard part is finding the sweet spot for the BW value. For me it's kind of a tipping point. There's a narrow range that if I deviate from, in either direction, then the latency starts to go up again. It's not enough to matter in practice (we're talking tolerances within A to B range) but enough to drive a perfectionist crazy. ;) I think my ISP makes it more difficult because cable modem speeds here fluctuate throughout the day, and the service is over-provisioned for short bursts so that I get 120% of the advertised speed initially before it levels out.
#9
German - Deutsch / Re: Frage bzgl. Unmanaged Swit...
Last post by drosophila - Today at 02:46:36 AMVielleicht wäre ein externer PEO Injektor die bessere Wahl für Dich? Klar ist es ein Gerät zusätzlich, aber damit bist Du bei der Wahl des Switches, inklusiver zukünftiger Änderungen, wesentlich freier.
Was das schwache Powerlan angeht, könntest Du die Adapter nochmal resetten und am tatsächlichen Anbringungsort neu verpaaren. Oft werden die nebeneinander gesteckt, gepaart, und dann verteilt. So oder so kann sich an der Verbindung untereinander was ändern (und sei es nur ein unschuldig aussehendes neue Steckernetzteil), was die ganze Signalaushandlung zunichte macht. Da kann dann eine Neuaushandlung Wunder wirken (so gesehen: von 14MBits/s zu über 200MBit/s). Die Verbindungsqualität kann man mit den Powerlan-Managerprogrammen angucken, leider aber keine Neuashandlung anstoßen oder sonstiges Management betreiben.
Generell gilt: das Einzige, was ein festverlegtes LAN-Kabel übertrifft, sind zwei festverlegte LAN-Kabel. Wenn Du also diese Chance hast: nutze sie, und verlege so viele wie möglich, wenn Du einmal dabei bist.
Denn egal was man tut: die schlechte Bandbreite kommt nicht von dem einen Port an der OPNsense Box, sondern vom Powerlan und / oder dem WLAN (hast Du ja auch so beobachtet). Eine auf 1Gigabit ausgehandelte WLAN-Verbindung bricht bei ernsthafter Nutzung aber auch schnell ein, und je mehr Parteien mitfunken (eigene Geräte oder die der Nachbarn), umso schneller wird es schlechter. Das ist bei Powerline nicht anders, nur, dass da jede Lampe, jedes Steckernetzteil, Fernseher, Computer, etc. ggfs. für Störungen sorgen. Daher ist es auf jeden Fall sinnvoll, möglichst viele Geräte möglichst direkt und per Kabel anzubinden. Da würde aber kein Unterschied zwischen dem einzelnen Port an der OPNSense Box und der Bündelung herauskommen, weil entweder der Verkehr gar nicht über die OPNSense Box läuft (z.B. für ein NAS), oder durch die Internetanbindung begrenzt ist, und bei Beidem zusammen ja eigentlich auch nicht (da begrenzt dann eher die Verbindung am Rechner). Die Portbündelung würde IMO nur dann etwas bringen, wenn 1) Deine Internetverbindung deutlich schneller ist als der Port an der OPNSense Box und 2) Deine Geräte entweder gleichzeitig oder einzeln diese Bandbreite auch absorbieren können. Deiner Beschreibung nach ist ein Gerät (der Desktop-PC) Hauptnutzer der Bandbreite und die anderen sind Nebenschauplätze. Es wäre wahrscheilich am besten, das Hauptgerät direkt anzubinden und so dem Rest das ganze W/PLAN zu überlassen, die VLANs sind dafür eigentlich egal.
Der Hauptgrund, trotzdem einen Managed Switch zu nehmen wäre die Tatsache, dass an jedem (derzeit noch freien) Port eher früher als später ein Gerät hängen wird. Und wenn der dann keine VLANs kann, ist das natürlich schlecht.
Was das schwache Powerlan angeht, könntest Du die Adapter nochmal resetten und am tatsächlichen Anbringungsort neu verpaaren. Oft werden die nebeneinander gesteckt, gepaart, und dann verteilt. So oder so kann sich an der Verbindung untereinander was ändern (und sei es nur ein unschuldig aussehendes neue Steckernetzteil), was die ganze Signalaushandlung zunichte macht. Da kann dann eine Neuaushandlung Wunder wirken (so gesehen: von 14MBits/s zu über 200MBit/s). Die Verbindungsqualität kann man mit den Powerlan-Managerprogrammen angucken, leider aber keine Neuashandlung anstoßen oder sonstiges Management betreiben.
Generell gilt: das Einzige, was ein festverlegtes LAN-Kabel übertrifft, sind zwei festverlegte LAN-Kabel. Wenn Du also diese Chance hast: nutze sie, und verlege so viele wie möglich, wenn Du einmal dabei bist.
Denn egal was man tut: die schlechte Bandbreite kommt nicht von dem einen Port an der OPNsense Box, sondern vom Powerlan und / oder dem WLAN (hast Du ja auch so beobachtet). Eine auf 1Gigabit ausgehandelte WLAN-Verbindung bricht bei ernsthafter Nutzung aber auch schnell ein, und je mehr Parteien mitfunken (eigene Geräte oder die der Nachbarn), umso schneller wird es schlechter. Das ist bei Powerline nicht anders, nur, dass da jede Lampe, jedes Steckernetzteil, Fernseher, Computer, etc. ggfs. für Störungen sorgen. Daher ist es auf jeden Fall sinnvoll, möglichst viele Geräte möglichst direkt und per Kabel anzubinden. Da würde aber kein Unterschied zwischen dem einzelnen Port an der OPNSense Box und der Bündelung herauskommen, weil entweder der Verkehr gar nicht über die OPNSense Box läuft (z.B. für ein NAS), oder durch die Internetanbindung begrenzt ist, und bei Beidem zusammen ja eigentlich auch nicht (da begrenzt dann eher die Verbindung am Rechner). Die Portbündelung würde IMO nur dann etwas bringen, wenn 1) Deine Internetverbindung deutlich schneller ist als der Port an der OPNSense Box und 2) Deine Geräte entweder gleichzeitig oder einzeln diese Bandbreite auch absorbieren können. Deiner Beschreibung nach ist ein Gerät (der Desktop-PC) Hauptnutzer der Bandbreite und die anderen sind Nebenschauplätze. Es wäre wahrscheilich am besten, das Hauptgerät direkt anzubinden und so dem Rest das ganze W/PLAN zu überlassen, die VLANs sind dafür eigentlich egal.
Der Hauptgrund, trotzdem einen Managed Switch zu nehmen wäre die Tatsache, dass an jedem (derzeit noch freien) Port eher früher als später ein Gerät hängen wird. Und wenn der dann keine VLANs kann, ist das natürlich schlecht.
#10
Hardware and Performance / Re: Suggestion for Bufferbloat...
Last post by Seimus - Today at 02:42:26 AMCookie,
Looking at your original configuration on the very 1st post, it looks to be misaligned with the docs.
Please align the configuration exactly as is in the official documentation. It was tested on several different configurations (HW + WANs) and its designed to provide a proper baseline with minimal configuration needed. Which usually results B or higher scores, if you at least set the BW properly.
The main point of having properly configured FQ_C is to set properly the BW and to have Pipes and Queues for both Download and UPload. The rest of the parameters should be used for fine tuning.
I did as well update the docs, PR was merged, when Ad will recompile the docs it will be updated
https://github.com/opnsense/docs/pull/811/files
-----------
Alright lets dissect this;
Your QoS/Shaping should be implemented on the interface that you want to control the bottleneck for. So closer to the source of bufferbloat. A FQ as such doesn't handle in anyway bufferbloat. FQ only shares the BW equally amongst all the flows. To control bufferbloat you need an AQM (FQ_Codel, FQ_Pie) or a SQM (CAKE).
Another point is, you should not set your Pipe to more than you have, this introduces issues. You can not give out what you don't have, in our case BW. By settings BW higher than you have you will end in bufferbloat land, and latency will go high-wire, and you are giving up the control to the ISP.
limit parameter (max 20480) with flow parameter (max 65535).
Settings the flow parameter higher is not a bad idea, the desired outcome is to have as less possible overlapping flows into the same queue as possible. But this parameter the higher its set takes more memory (in reality its not so much).
Rule of thumb;
Limit > bellow 10Gbit/s should be around (good starting point) 1000 (usable since 25.7.8)
Flow > If possible set to max 65535
Regards,
S.
Looking at your original configuration on the very 1st post, it looks to be misaligned with the docs.
Please align the configuration exactly as is in the official documentation. It was tested on several different configurations (HW + WANs) and its designed to provide a proper baseline with minimal configuration needed. Which usually results B or higher scores, if you at least set the BW properly.
The main point of having properly configured FQ_C is to set properly the BW and to have Pipes and Queues for both Download and UPload. The rest of the parameters should be used for fine tuning.
Quote from: cookiemonster on December 01, 2025, 07:09:25 PMI admit I can't understand the current way to use the "limit" note of the docs, the reference to the bug.Prior OPN 25.7.8 there was a BUG that caused a CPU hogging due to excessive logging caused when the limit queue is exceeded. So the advice was to let Limit blank. Franco did FIX this (well at least on OPN side). So now is safe and beneficial to use the Limit queue and set it to 1000 for Speeds under 10Gbit/s.
I did as well update the docs, PR was merged, when Ad will recompile the docs it will be updated
https://github.com/opnsense/docs/pull/811/files
-----------
Alright lets dissect this;
Quote from: pfry on December 01, 2025, 08:18:47 PMI'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed).
Your QoS/Shaping should be implemented on the interface that you want to control the bottleneck for. So closer to the source of bufferbloat. A FQ as such doesn't handle in anyway bufferbloat. FQ only shares the BW equally amongst all the flows. To control bufferbloat you need an AQM (FQ_Codel, FQ_Pie) or a SQM (CAKE).
Another point is, you should not set your Pipe to more than you have, this introduces issues. You can not give out what you don't have, in our case BW. By settings BW higher than you have you will end in bufferbloat land, and latency will go high-wire, and you are giving up the control to the ISP.
Quote from: pfry on December 01, 2025, 08:18:47 PMI haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe).FQ_C creates internal flow queues per 5-tuple using a HASH. There are examples where stochastic nature of hashing, multiple flows may end up being hashed into the same slot. This can be controlled by the flow parameter in FQ_C.
Quote from: pfry on December 01, 2025, 08:18:47 PMIt looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell.This is a very bad idea if we speak about the "limit parameter". Limit is effectively the Queue size for the internal flows created by FQ_C. If you have a long Queue, but you are not able to process the packets in the Queue in time you create latency. FQ_C because its an AQM, measure sojourn time of each packet in the queue, and if it exceeds it either marks it or drops. But having to big of a queue is still overall bad. We want to TAIL drop packets when we can not handle them and not store them.
limit parameter (max 20480) with flow parameter (max 65535).
Settings the flow parameter higher is not a bad idea, the desired outcome is to have as less possible overlapping flows into the same queue as possible. But this parameter the higher its set takes more memory (in reality its not so much).
Rule of thumb;
Limit > bellow 10Gbit/s should be around (good starting point) 1000 (usable since 25.7.8)
Flow > If possible set to max 65535
Quote from: pfry on December 01, 2025, 08:18:47 PMPIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.I really don't want to go into PIE to much e.g FQ_PIE, it work similar to FQ_C, but it has different use case, so I will say this:
Code Select
Pie
- Probabilistic, gradual
- Usage in ISP networks, broadband, general traffic
Codel
- Adaptive, based on packet age
- Low-latency applications, real-time traffic
Regards,
S.
