"Recent posts
#1
German - Deutsch / Re: "Lahmes" Internet seit Upd...
Last post by cottec - September 02, 2026, 11:58:08 PMQuote from: cottec on May 08, 2026, 09:54:09 PMIch endlich mal wieder, sorry, bin derzeit im Umzugsstress und hatte die Probleme hinten angestellt...
Jetzt ist mir allerdings etwas aufgefallen, das seit dem Update gar nicht mehr geht:
Meine Kaffeemaschine kann Bezüge auf die Plattform visualizer.coffee hochladen bzw konnte.
Das geht seit dem Update wohl nicht mehr.
Die Software der Maschine hat ein kleines Plugin zum hochladen.
Wenn ich die Bezugsdaten per Browser direkt auf die Webseite von visualizer hochlade, dann geht das auch. Es scheint also ein Problem in der Art und Weise zu liegen, wie das Plugin kommuniziert.
Wenn ich statt opnsense Wifi einen Hotspot per Handy auf dem Android Tablet der Kaffeemaschine benutze funktioniert alles wunderbar, die Konfig auf dem Tablet scheint also okay.
Ich hab mal testweise Adguard abgeschaltet, ansonsten benutze ich ja nichts...
Hab mal den Traffic mitgeschnitten (siehe Anhang)
Da geht ja irgendwas schief... ist das ein MTU/MSS Problem?
kleines Update:
das eingesetze Tablet kann zwar IPv6 aber irgendwas läuft bei dem Upload Skript der App falsch.
IPv6 auf dem Interface deaktiviert und das Tablet läuft wunderbar...
Ich hab mal den Entwickler angeschrieben, ob er das fixen mag.
Falls nicht kann ich immer noch ein weiteres VLAN nur für die Kaffeemaschine ohne V6 erzeugen.
Klingt irgendwie total Verrückt, dass man sich bei Kaffeemaschinen um IPv6 Gedanken machen muss :D
#2
German - Deutsch / o2 VoIP über Fritzbox Client f...
Last post by cottec - September 02, 2026, 11:54:21 PMHatte meine OPNsense jetzt 2 Monate offline während des Umzugs...
Habe da natürlich auch mein DSL und VoIP mit umgezogen.
Bin das Thema Firwall dann am Wochenende endlich mal angegangen und eigentlich lief alles sofort.
Dann einmal alles fröhlich auf die neueste Version geupdatet, endlich Firewall Regeln und NAT migriert und eigentlich läuft alles, bis auf das verfluchte VoIP.
Nach drölf Milliarden Stunden Troubleshooting mit der KI immer noch nicht weiter gekommen.
Bis ich mal auf die Idee gekommen bin das SIP Passwort in der Fritz Oberfläche neu einzutippen (ich hab das nie angefasst seit es lief!)
Ja und siehe da, die vielen Stunden hätte ich mir sparen können... o2 hat im Rahmen des Umzugs das SIP Passwort geupdated, nicht aber das des pppoe.
So kommt man natürlich gar nicht auf die Idee, dass auf einmal das Passwort anders ist, weil ja eben alles andere auch lief...
Also, nur als grundsätzlicher Hinweis, falls jemandem mal das gleiche passiert:
o2 ändert beim Umzug das SIP Passwort
Habe da natürlich auch mein DSL und VoIP mit umgezogen.
Bin das Thema Firwall dann am Wochenende endlich mal angegangen und eigentlich lief alles sofort.
Dann einmal alles fröhlich auf die neueste Version geupdatet, endlich Firewall Regeln und NAT migriert und eigentlich läuft alles, bis auf das verfluchte VoIP.
Nach drölf Milliarden Stunden Troubleshooting mit der KI immer noch nicht weiter gekommen.
Bis ich mal auf die Idee gekommen bin das SIP Passwort in der Fritz Oberfläche neu einzutippen (ich hab das nie angefasst seit es lief!)
Ja und siehe da, die vielen Stunden hätte ich mir sparen können... o2 hat im Rahmen des Umzugs das SIP Passwort geupdated, nicht aber das des pppoe.
So kommt man natürlich gar nicht auf die Idee, dass auf einmal das Passwort anders ist, weil ja eben alles andere auch lief...
Also, nur als grundsätzlicher Hinweis, falls jemandem mal das gleiche passiert:
o2 ändert beim Umzug das SIP Passwort
#3
Zenarmor (Sensei) / Re: Cancelling my subscription...
Last post by Cljackhammer - September 02, 2026, 11:50:56 PMQuote from: Glitch01 on September 02, 2026, 03:14:32 PMI disabled ZA free edition and didn't subscribe to the home tier because of lack of multi-threaded support. I found it was indeed bottle-necking my 10G network. While I did enjoy the extra layer of controls, it wasn't worth limiting my network traffic.same here. Zenarmor introduces latency due to its architecture. In this day and age of 2.5 gbps + internet, Zenarmor has lost it's utility. There are other ways to secure a network without having to "pay" for multi-core support.
#4
26.7 Series / Re: Some SSL certificate help ...
Last post by fornax - September 02, 2026, 11:34:25 PMAre you just trying to replace the web UI certificate with one signed by a publicly available CA? How exactly are you trying to do it? I've been meaning to do this myself (but with my own CA), so I just did it and it seems to have worked fine. Here's what I did:
- Added root CA certificate (not key) in System -> Trust -> Authorities. (I didn't have any intermediates, but I think if you do you need to add them as well.)
- Created an entry in System -> Trust -> Certificates with method "Create a Certificate Signing Request".
- Downloaded the CSR.
- Uploaded the CSR to the CA to create the certificate.
- Edit the entry in System -> Trust -> Certificates to add the certificate signed by the CA (just paste the cert block into the field on the form).
- Set the new certificate in System -> Settings -> Administration and save.
#5
26.7 Series / Some SSL certificate help plea...
Last post by Ed V. - September 02, 2026, 10:10:58 PMI'm feeling a bit lost here.
I know that CACert is a niche CA provider, but I've been using them for a couple of decades without any issues, once I import their Class 1 and Class 3 Roots.
For some reason, the 26.7 series of OpnSense has so far been unable to use my CACert certificates in any way.
I've tried newly issued certs, renewed certs, old certs, and nothing works.
I also have tried certs from SSL.com, DigiCert and LetsEncrypt.
Also, no dice.
Even after importing the appropriate CA Root certificates from SSL.com and friends in "System -> Trust -> Authorities", on adding a host certificate in "System -> Trust -> Certificates", I get the same error:
"missing CA key"
What can I check on or provide to assist in further debugging?
Is there a config file somewhere that should have a pointer to a bundled PEM file or files and it's corrupt or missing?
Did I maybe miss something in the upgrade to 26.7 that was needed to update the SSL configuration /settings?
Just looking for some help in getting WebUI SSL up and running again.
I know that CACert is a niche CA provider, but I've been using them for a couple of decades without any issues, once I import their Class 1 and Class 3 Roots.
For some reason, the 26.7 series of OpnSense has so far been unable to use my CACert certificates in any way.
I've tried newly issued certs, renewed certs, old certs, and nothing works.
I also have tried certs from SSL.com, DigiCert and LetsEncrypt.
Also, no dice.
Even after importing the appropriate CA Root certificates from SSL.com and friends in "System -> Trust -> Authorities", on adding a host certificate in "System -> Trust -> Certificates", I get the same error:
"missing CA key"
What can I check on or provide to assist in further debugging?
Is there a config file somewhere that should have a pointer to a bundled PEM file or files and it's corrupt or missing?
Did I maybe miss something in the upgrade to 26.7 that was needed to update the SSL configuration /settings?
Just looking for some help in getting WebUI SSL up and running again.
#6
German - Deutsch / Re: SSD Killer gesucht
Last post by maze-m - September 02, 2026, 10:07:35 PMQuote from: Patrick M. Hausen on August 31, 2026, 05:07:38 PMReporting > Netflow > Capture local
Macht jede SSD kaputt außer bei den allerkleinsten Heimnetzen mit wenig Traffic.
@Patrick: Ich habe das auf meiner Sense auch so, allerdings damit noch nie Probleme gehabt.
Aber vermutlich ist mein Heimnetz auch sehr klein :)...
Was kann ich denn dagegen machen, dass mir mit dem Setting eventl. die Sense abschmiert, wenn ich mein Netz vergrößere?
#7
General Discussion / Re: Intel i226 2.5 GbE NIC on ...
Last post by Abdellah - September 02, 2026, 09:38:17 PMSOLVED — UPDATE
The issue has been resolved.
The problem was caused by how I bypassed my ISP modem using the ODI DFP-34X-2C3.
I replaced it with a Leox LXT-010H-D, and this fixed the international upload speed issue. Upload speed is now back to the expected ~450 Mbps.
OPNsense itself and the Intel I226 NIC were not the problem.
The issue has been resolved.
The problem was caused by how I bypassed my ISP modem using the ODI DFP-34X-2C3.
I replaced it with a Leox LXT-010H-D, and this fixed the international upload speed issue. Upload speed is now back to the expected ~450 Mbps.
OPNsense itself and the Intel I226 NIC were not the problem.
#8
26.7 Series / Intel E810 fails to link on WA...
Last post by homelabber - September 02, 2026, 07:50:12 PMLong time lurker, first time caller.
After upgrading from 26.1.x to 26.7, my WAN interface (ice0, Intel E810-XXV for SFP, 25GBase-LR to my ISP) stopped establishing a link entirely. It appears that link-negotiation fails when the ice driver loads its DDP package. On 26.7 there is no fallback when that negotiation fails, unlike on 26.1. Forcing "Safe Mode" (DDP package not loaded, 1 queue; ice_ddp_load="YES" forced via /boot/loader.conf.local) gives a reliable link on both branches. Updating to 26.7.3_8 gave me multiple retry/re-attach cycles instead of giving up after one but did not fully fix it. Without DDP, no 25Gbit fun :(
Components involved:
I am wondering if...
Happy to pull more diagnostics.
After upgrading from 26.1.x to 26.7, my WAN interface (ice0, Intel E810-XXV for SFP, 25GBase-LR to my ISP) stopped establishing a link entirely. It appears that link-negotiation fails when the ice driver loads its DDP package. On 26.7 there is no fallback when that negotiation fails, unlike on 26.1. Forcing "Safe Mode" (DDP package not loaded, 1 queue; ice_ddp_load="YES" forced via /boot/loader.conf.local) gives a reliable link on both branches. Updating to 26.7.3_8 gave me multiple retry/re-attach cycles instead of giving up after one but did not fully fix it. Without DDP, no 25Gbit fun :(
Components involved:
- NIC: Intel Ethernet Controller E810-XXV for SFP, genuine Intel reference card (not an OEM-customized part)
- Driver: iflib ice, driver_version 1.43.3-k (identical across all OPNsense versions tested)
- Firmware: fw 7.8.2, api 1.7, nvm 4.80 (identical across all tests)
- DDP: ICE OS Default Package version 1.3.41.0, track id 0xc0000001
I am wondering if...
- anyone else has seen E810 fail to negotiate link in full-DDP mode specifically after upgrading to 26.7, where Safe Mode links fine?
- the queue-reconfiguration-triggered link flap on the DDP-loaded attach is a known iflib/ice interaction, or worth its own upstream report?
- anyone has any recommendation on forcing requested_fec at boot to test the theory above?
Happy to pull more diagnostics.
#9
Development and Code Review / Re: netflector available as pl...
Last post by RamSense - September 02, 2026, 05:44:20 PMThanks for looking into this in more detail. This sounds very promising.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
#10
26.7 Series / Re: APU1: No network with 26.7...
Last post by iam - September 02, 2026, 04:04:30 PMI don't know if it's the same issue as I haven't observed any upgrade failure. But the 26.7.3 works indeed after removing the driver plugin.
Thank you.
Thank you.
