"Recent posts
#1
German - Deutsch / Re: Subnetzaufbau und Internet...
Last post by Patrick M. Hausen - Today at 09:40:56 AMHast du denn die Doku befolgt beim Einrichten der Bridge?
https://docs.opnsense.org/manual/how-tos/lan_bridge.html
https://docs.opnsense.org/manual/how-tos/lan_bridge.html
#2
German - Deutsch / Subnetzaufbau und Internetverb...
Last post by LittleLate - Today at 09:22:45 AMHallo Liebe Community,
Von Zeit zu Zeit suche ich mir immer mal wieder Projekte und diesesmal bin ich für meine neue Wohnung auf die glorreiche Idee gekommen ein eigenen WLAN Router zusammenzubasteln. Jetzt stecke ich seit gut einer Woche fest und weiss leider nicht mehr weiter. Auch die KI ist mir keine Hilfe und ich bin wohl zu unfähig am richtigen Ort zu suchen. Leider bin ich auch nicht vom Fach und begebe mich mit dem Projekt in unbekannte Gewässer :D.
Die Situation ist wie folgt:
Ausgangssituation:
Ich habe mir einen WLAN Router zusammengebaut welcher direkt an der Wohnungsglasfaser hängt und welcher folgende Netzwerkkomponenten enthält:
1x Mellanox ConnectX-4 Lx EN
1x Intel X550 T2
- Ein Port der Mellanox führt in das WAN und der andere Port ist für meine Workstation vorgesehen (Diese hat auch eine Mellanox verbaut)
- Ein Port der Intel ist als "LAN" deklariert und über diesen Port komme ich nach der Standardeinrichtungauch wunderbar ins Internet und der andere ist für meinen kleinen Server vorgesehen, den ich für meine Freunde und Familie zu Verfügung stellen möchte.
Hilfepunkt:
Wie bereits erwähnt komme ich vom LAN-Port wunderbar ins WAN und kann von dem LAN-Port der Intel NIC auf das OPN Sense zugreifen. Ich hätte aber eigentlich gerne noch meine Workstation in das LAN(192.168.1.XX) eingebunden. Einfach über den Mellanox Port. Dann dachte ich mir, ja gut, bridgen wir das doch. Jedoch ging dieser Versuch nach hinten los. Es hat leider nicht funktioniert. Dann habe ich an die Alternative gedacht, dass ich die Workstation einfach in ein eigenes Subnetz setzte (192.168.2.XXX). Nachdem ich das so einrichten wollte hatte ich aber leider absolut keine Verbindung ins Internet. Dementsprechend gehe ich davon aus, dass ich das Subnetz falsch aufgebaut habe. bzw. Etwas mit dem Gateway,DHCP oder DNS falsch eingestellt habe. Das selbe geht auch für den Serverport. Dieser soll aus sicherheitsgründen definitiv separiert werden und hätte ihn dementsprechend bevorzugt in ein eigenes Subnetz eingebunden (192.168.3.XXX).
Wie würdet ihr bei diesem Projekt vorgehen? Was sind wichtige Schritte die ich vielleicht nicht gemacht habe? Am liebsten Wäre mir schon fast eine Schritt für Schritt Anleitung. :D
Ich bin dankbar für jede Hilfe und Ratschlag.
Liebe Grüsse L.
Von Zeit zu Zeit suche ich mir immer mal wieder Projekte und diesesmal bin ich für meine neue Wohnung auf die glorreiche Idee gekommen ein eigenen WLAN Router zusammenzubasteln. Jetzt stecke ich seit gut einer Woche fest und weiss leider nicht mehr weiter. Auch die KI ist mir keine Hilfe und ich bin wohl zu unfähig am richtigen Ort zu suchen. Leider bin ich auch nicht vom Fach und begebe mich mit dem Projekt in unbekannte Gewässer :D.
Die Situation ist wie folgt:
Ausgangssituation:
Ich habe mir einen WLAN Router zusammengebaut welcher direkt an der Wohnungsglasfaser hängt und welcher folgende Netzwerkkomponenten enthält:
1x Mellanox ConnectX-4 Lx EN
1x Intel X550 T2
- Ein Port der Mellanox führt in das WAN und der andere Port ist für meine Workstation vorgesehen (Diese hat auch eine Mellanox verbaut)
- Ein Port der Intel ist als "LAN" deklariert und über diesen Port komme ich nach der Standardeinrichtungauch wunderbar ins Internet und der andere ist für meinen kleinen Server vorgesehen, den ich für meine Freunde und Familie zu Verfügung stellen möchte.
Hilfepunkt:
Wie bereits erwähnt komme ich vom LAN-Port wunderbar ins WAN und kann von dem LAN-Port der Intel NIC auf das OPN Sense zugreifen. Ich hätte aber eigentlich gerne noch meine Workstation in das LAN(192.168.1.XX) eingebunden. Einfach über den Mellanox Port. Dann dachte ich mir, ja gut, bridgen wir das doch. Jedoch ging dieser Versuch nach hinten los. Es hat leider nicht funktioniert. Dann habe ich an die Alternative gedacht, dass ich die Workstation einfach in ein eigenes Subnetz setzte (192.168.2.XXX). Nachdem ich das so einrichten wollte hatte ich aber leider absolut keine Verbindung ins Internet. Dementsprechend gehe ich davon aus, dass ich das Subnetz falsch aufgebaut habe. bzw. Etwas mit dem Gateway,DHCP oder DNS falsch eingestellt habe. Das selbe geht auch für den Serverport. Dieser soll aus sicherheitsgründen definitiv separiert werden und hätte ihn dementsprechend bevorzugt in ein eigenes Subnetz eingebunden (192.168.3.XXX).
Wie würdet ihr bei diesem Projekt vorgehen? Was sind wichtige Schritte die ich vielleicht nicht gemacht habe? Am liebsten Wäre mir schon fast eine Schritt für Schritt Anleitung. :D
Ich bin dankbar für jede Hilfe und Ratschlag.
Liebe Grüsse L.
#3
German - Deutsch / Re: Nach Update von 26.1.11 au...
Last post by tangofan - Today at 09:05:48 AMQuote from: iRobot on October 22, 2026, 09:19:16 AMHallo,
gefunden, es passiert bei jedem Update, auch bei dem aktuellen Update 26.7.1
In den iPv6-Einstellungen im LAN-Interface steht IPv6 Configuration Type auf "Identity association" und bei "Assign prefix ID" eine 10. Nach einem Update steht dort aber eine "0".
10 eintragen, speichern, schon läuft die FritzBox wieder als Telefonanlage.
Das wäre sicherlich einen Bugreport auf GitHub wert.
#4
Hardware and Performance / Re: OPNsense on Sophos XGS: dr...
Last post by BoNetTech - Today at 08:46:53 AMHi Abdelmonem,
Thank you for the detailed and honest answers. Knowing that the IPS and the offload are, for now, either one or the other is exactly what people need to know before they choose, so it may be worth stating it clearly on the project page. The same goes for telemetry being on by default: an opt-in would make it easier to adopt this in places where reports must not leave the network.
Good luck with the project.
Sergio
Thank you for the detailed and honest answers. Knowing that the IPS and the offload are, for now, either one or the other is exactly what people need to know before they choose, so it may be worth stating it clearly on the project page. The same goes for telemetry being on by default: an opt-in would make it easier to adopt this in places where reports must not leave the network.
Good luck with the project.
Sergio
#5
26.7 Series / Re: Invalid argument errors wh...
Last post by Shad - Today at 07:37:02 AMUPDATE : I found the smart package in the community repo.
I ran a short test : smartctl -t short /dev/ada0
Result :
I ran a short test : smartctl -t short /dev/ada0
Result :
Code Select
smartctl 7.5 2025-04-30 r5714 [FreeBSD 14.3-RELEASE-p16 amd64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: GIM128
Serial Number: 2022120800350
Firmware Version: U0707A0
User Capacity: 128,035,676,160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: mSATA
TRIM Command: Available
Device is: Not in smartctl database 7.5/5706
ATA Version is: ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Oct 23 07:34:24 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x02) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 120) seconds.
Offline data collection
capabilities: (0x11) SMART execute Offline immediate.
No Auto Offline data collection support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
No Selective Self-test supported.
SMART capabilities: (0x0002) Does not save SMART data before
entering power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 10) minutes.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x0032 100 100 050 Old_age Always - 0
5 Reallocated_Sector_Ct 0x0032 100 100 050 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 050 Old_age Always - 18487
12 Power_Cycle_Count 0x0032 100 100 050 Old_age Always - 204
160 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 0
161 Unknown_Attribute 0x0033 100 100 050 Pre-fail Always - 100
163 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 10
164 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 303794
165 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 3728
166 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 336
167 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 617
168 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 7000
169 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 92
175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0
176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0
177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 0
178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 165
194 Temperature_Celsius 0x0022 100 100 050 Old_age Always - 40
195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 492
196 Reallocated_Event_Count 0x0032 100 100 050 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 050 Old_age Always - 0
198 Offline_Uncorrectable 0x0032 100 100 050 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x0032 100 100 050 Old_age Always - 0
232 Available_Reservd_Space 0x0032 100 100 050 Old_age Always - 100
241 Total_LBAs_Written 0x0030 100 100 050 Old_age Offline - 564087
242 Total_LBAs_Read 0x0030 100 100 050 Old_age Offline - 9288
245 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 471940
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 18487 -
Selective Self-tests/Logging not supported
The above only provides legacy SMART information - try 'smartctl -x' for more #6
26.7 Series / Re: Invalid argument errors wh...
Last post by Shad - Today at 07:12:11 AMHello (MARLOO),
Thanks for yout input.
For some reason, smartctl is not found (and I don't find it in the packages tab in the GUI).
df -h
dmesg | grep -iE 'ada0|error|fail|cam'
We are talking about ~1175 lines here... smells really bad I guess ?
smartctl -a /dev/ada0
pkg install --force --reinstall boost-libs py313-botocore
I then tried without the --reinstall argument :
opnsense-version
Am I good for a reinstall ?
Thanks for yout input.
For some reason, smartctl is not found (and I don't find it in the packages tab in the GUI).
df -h
Code Select
Filesystem Size Used Avail Capacity Mounted on
/dev/ada0p2 111G 54G 48G 53% /
devfs 1.0K 0B 1.0K 0% /dev
/dev/ada0p1 260M 1.3M 259M 1% /boot/efi
devfs 1.0K 0B 1.0K 0% /var/dhcpd/dev
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.13 111G 54G 48G 53% /var/unbound/usr/local/lib/python3.13
/lib 111G 54G 48G 53% /var/unbound/lib
dmesg | grep -iE 'ada0|error|fail|cam'
Code Select
[47284] /mnt: inode 8334247: check-hash failed
[47284] /mnt: inode 8334247: check-hash failed
[47284] /mnt: inode 8334246: check-hash failed
[47284] /mnt: inode 8334246: check-hash failed
[47284] /mnt: inode 8334245: check-hash failed
[47284] /mnt: inode 8334245: check-hash failed
[47284] /mnt: inode 8334244: check-hash failed
[47284] /mnt: inode 8334244: check-hash failed
[...]
[1861689] /mnt: inode 8334244: check-hash failed
[1861689] /mnt: inode 8334244: check-hash failed
[1861689] /mnt: inode 8334245: check-hash failed
[1861689] /mnt: inode 8334245: check-hash failed
[1861689] /mnt: inode 8334246: check-hash failed
[1861689] /mnt: inode 8334246: check-hash failed
[1861689] /mnt: inode 8334247: check-hash failed
[1861689] /mnt: inode 8334247: check-hash failedWe are talking about ~1175 lines here... smells really bad I guess ?
smartctl -a /dev/ada0
Code Select
smartctl: Command not found.pkg install --force --reinstall boost-libs py313-botocore
Code Select
pkg: unrecognized option `--reinstall'I then tried without the --reinstall argument :
Code Select
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):
Installed packages to be REINSTALLED:
boost-libs-1.89.0_2 [OPNsense]
py313-botocore-1.43.14 [OPNsense]
Number of packages to be reinstalled: 2
8 MiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching py313-botocore-1.43.14.pkg: 100% 8 MiB 8.5MB/s 00:01
Checking integrity... done (0 conflicting)
[1/2] Reinstalling boost-libs-1.89.0_2...
[1/2] Extracting boost-libs-1.89.0_2: 100%
pkg: Fail to rename /usr/local/include/boost/thread/executors/.pkgtemp.serial_executor_cont.hpp.au7FxGhtawrY -> /usr/local/include/boosutors/serial_executor_cont.hpp:Invalid argumentopnsense-version
Code Select
OPNsense 26.1.11_10 (amd64)Am I good for a reinstall ?
#7
General Discussion / Re: Unbound DNS over TLS
Last post by curiousgeorge - Today at 06:44:04 AMDNSSEC is completely different form DNS over TLS. To enable it, you need to go to services > UnboundDNS > DNS over TLS. You can use cloud flare DNS (1.1.1.1) with port 853 to enable it. I would recommend forcing all traffic on port 53 to go to unbound through the firewall. After you set it up, verify by using the cloudflare site for testing DNS over TLS. It can only test cloudflare DNS over TLS so if you use another DNS you need to find a way to verify that. Good Luck!
#8
General Discussion / weird issues with network
Last post by curiousgeorge - Today at 06:30:39 AMI need some help with figuring out what is going on.
I'll start with my setup:
I am running opnsense on proxmox. I have a 8 core, 16 thread AMD ryzen 5 with 32GB RAM. Of this, 14 threads are assigned to the opnsense along with 28GB of RAM. The system has a 500GB drive for Proxmox and a 256GB drive for opnsense. I have a 2.5GB port for internet and a 2.5GB port for LAN along with a 1GB port for proxmox admin controller. The traffic from NICs for opnsense is blocked by proxmox firewall for security. I have VLANs for internet connected IOT devices, work computers, adult devices, kids devices, and non-internet connected IOT devices. I am using Omada OC300 controller with 3 wireless APs and 3 wired smart switches for WiFi and ethernet connections. I have a total of over 50 devices connected. i also have a server for local AI with Home assistant and NextCloud exposed through a cloudflare tunnel with Geo restrictions blocking access from anywhere outside the US and a bunch of other restrictions. Everything that supports 2-factor has 2-factor and the server can only be logged in with public key and 2-factor.
On Opnsense, I have zenarmor with policies set to block unknown devices so each device must be manually approved. I also have multiple policies with a Home level subscription. I am running surricata with snort rules, Maltrail, monit, and CrowdSec for security. I also use KEA dhcp and unbound DNS, and have a Wazuh agent running for general security. I have disabled root access to the GUI, which was set up with 2-factor TOTP and created a separate user which also has 2-factor enabled. Omada also has 2-factor. I use let encrypt certs for my domain on both. I also have static ip addresses set for all devices. I know, its a lot.
For the past year, I have been having weird issues with Opnsense.
Issue 1:
I have a car that is connected to my network and it seems to be connected fine. I can get updates for the car through wifi. However, when it is connected to my network, the API for the car does not work and the car mobile app shows that it is disconnected. I have tried to disable surricata, zenarmor, Maltrail, monit, corwsec, and Wazuh and it still shows as not connected on the app. It also wont connect through the API I use with Home Assistant when connected to my network. I dont see any firewall states that are have an issue for the device. I see nothing blocked in zenarmor. It all looks fine. Now for the odd part. I reinstalled the entire system including the proxmox, which was updated to 9.2 (latest), and reinstalled Opnsense 26.7. I used my backup configs for Opnsense and Zenarmor to restore everything. Everything in the car worked fine for a day or so and then it was showing up as not connected in the app and API. I disabled everything after it showed up as not connected and it changed nothing. The logs for Opnsense show no updates or changes to configs. Wazuh shows no changes either. I have no idea where to look for more details on why this is happening.
Issue 2:
I upgraded my daughters computer and updated the motherboard and cpu, so the wireless card changed. I trusted the device in zenarmor, updated the mac address, and it all looked like it was fine except the wifi would not connect to the internet. I could not find anything being blocked in any of the security software.
Issue 3:
When I used to connect my phone to the network, the browser would randomly have issues like pages not loading css (plain html only) and my VPN would randomly drop. It would also stop working at times and clearing app cache force restarting it would return it normal. This would never happen on the 5g data.
I work extensively with Linux, software dev, AWS, and a secured system at work, so I have some decent knowledge, but BSD is not something I have done much work with. I have considered wifi interference and lowered the power on the APs and one of the APs is located right in my bedroom which is near my work desk.
I will also give a little bit of background in to why I am so paranoid about security. Years ago, I informed the FBI of a person who was involved in hacking ISP like Comcast and many financial institutions and that person went to prison for years with over a $1M confiscated along with expensive cars and homes. He found out that I informed the FBI before he went to prison possibly through the court case, and he was someone I knew. He was involved with foreign hackers from Russia and many hackers from around the world including another one in the US who was of Russian origin. I'm not saying I'm getting hacked, but it certainly is in the back of my mind since he has all the information needed to track me.
I would like determine why this odd stuff is happening to my network despite no logs indicating any issues. I need someone who is an expert in Opnsense to help me diagnose the issue since I admittedly have limited knowledge of BSD and mostly interact with Opnsense through the GUI. There are other details I may be leaving out about the setup and can share information after I de-ID the output. Can someone with extensive knowledge help me diagnose this and find root cause, please?
I am not a bot. I am not making any of this up. I am a slightly paranoid human looking for some help. I have already tried to use Gemini and my local qwen 3.8 and it was mostly things I had already looked at like logs and firewall rules and states. I dont understand how something can change without me making a change to it and no logs or alerts indicating any issues.
I'll start with my setup:
I am running opnsense on proxmox. I have a 8 core, 16 thread AMD ryzen 5 with 32GB RAM. Of this, 14 threads are assigned to the opnsense along with 28GB of RAM. The system has a 500GB drive for Proxmox and a 256GB drive for opnsense. I have a 2.5GB port for internet and a 2.5GB port for LAN along with a 1GB port for proxmox admin controller. The traffic from NICs for opnsense is blocked by proxmox firewall for security. I have VLANs for internet connected IOT devices, work computers, adult devices, kids devices, and non-internet connected IOT devices. I am using Omada OC300 controller with 3 wireless APs and 3 wired smart switches for WiFi and ethernet connections. I have a total of over 50 devices connected. i also have a server for local AI with Home assistant and NextCloud exposed through a cloudflare tunnel with Geo restrictions blocking access from anywhere outside the US and a bunch of other restrictions. Everything that supports 2-factor has 2-factor and the server can only be logged in with public key and 2-factor.
On Opnsense, I have zenarmor with policies set to block unknown devices so each device must be manually approved. I also have multiple policies with a Home level subscription. I am running surricata with snort rules, Maltrail, monit, and CrowdSec for security. I also use KEA dhcp and unbound DNS, and have a Wazuh agent running for general security. I have disabled root access to the GUI, which was set up with 2-factor TOTP and created a separate user which also has 2-factor enabled. Omada also has 2-factor. I use let encrypt certs for my domain on both. I also have static ip addresses set for all devices. I know, its a lot.
For the past year, I have been having weird issues with Opnsense.
Issue 1:
I have a car that is connected to my network and it seems to be connected fine. I can get updates for the car through wifi. However, when it is connected to my network, the API for the car does not work and the car mobile app shows that it is disconnected. I have tried to disable surricata, zenarmor, Maltrail, monit, corwsec, and Wazuh and it still shows as not connected on the app. It also wont connect through the API I use with Home Assistant when connected to my network. I dont see any firewall states that are have an issue for the device. I see nothing blocked in zenarmor. It all looks fine. Now for the odd part. I reinstalled the entire system including the proxmox, which was updated to 9.2 (latest), and reinstalled Opnsense 26.7. I used my backup configs for Opnsense and Zenarmor to restore everything. Everything in the car worked fine for a day or so and then it was showing up as not connected in the app and API. I disabled everything after it showed up as not connected and it changed nothing. The logs for Opnsense show no updates or changes to configs. Wazuh shows no changes either. I have no idea where to look for more details on why this is happening.
Issue 2:
I upgraded my daughters computer and updated the motherboard and cpu, so the wireless card changed. I trusted the device in zenarmor, updated the mac address, and it all looked like it was fine except the wifi would not connect to the internet. I could not find anything being blocked in any of the security software.
Issue 3:
When I used to connect my phone to the network, the browser would randomly have issues like pages not loading css (plain html only) and my VPN would randomly drop. It would also stop working at times and clearing app cache force restarting it would return it normal. This would never happen on the 5g data.
I work extensively with Linux, software dev, AWS, and a secured system at work, so I have some decent knowledge, but BSD is not something I have done much work with. I have considered wifi interference and lowered the power on the APs and one of the APs is located right in my bedroom which is near my work desk.
I will also give a little bit of background in to why I am so paranoid about security. Years ago, I informed the FBI of a person who was involved in hacking ISP like Comcast and many financial institutions and that person went to prison for years with over a $1M confiscated along with expensive cars and homes. He found out that I informed the FBI before he went to prison possibly through the court case, and he was someone I knew. He was involved with foreign hackers from Russia and many hackers from around the world including another one in the US who was of Russian origin. I'm not saying I'm getting hacked, but it certainly is in the back of my mind since he has all the information needed to track me.
I would like determine why this odd stuff is happening to my network despite no logs indicating any issues. I need someone who is an expert in Opnsense to help me diagnose the issue since I admittedly have limited knowledge of BSD and mostly interact with Opnsense through the GUI. There are other details I may be leaving out about the setup and can share information after I de-ID the output. Can someone with extensive knowledge help me diagnose this and find root cause, please?
I am not a bot. I am not making any of this up. I am a slightly paranoid human looking for some help. I have already tried to use Gemini and my local qwen 3.8 and it was mostly things I had already looked at like logs and firewall rules and states. I dont understand how something can change without me making a change to it and no logs or alerts indicating any issues.
#9
Hardware and Performance / Re: OPNsense on Sophos XGS: dr...
Last post by abdelmonem - Today at 03:54:55 AMHi Sergio,
Thank you, these are exactly the questions I'd ask too.
1) Intrusion detection. You're right. The flow maker hands a connection to the coprocessor after its first data, so Suricata sees how each connection starts (the TLS ClientHello, enough for a JA4 fingerprint) and nothing after that. Inline IPS mode hasn't been tested with the offload yet, so for now I'd treat the two as either/or.
To keep traffic out of the offload:
- XGS: Settings has "Never offloaded": addresses, networks and ports, up to 64 entries, and either end of a connection can match. Those connections always stay with pf, and Suricata sees all of them.
- Any single connection can be sent back with "Return to host" on the Offloaded Flows page.
- Or turn acceleration off, and every packet goes through the host like on any OPNsense box.
Connections the Traffic Shaper or the Captive Portal names stay on the host by themselves.
When the rules change: every ruleset reload empties the coprocessor's whole flow table before the new ruleset loads. Every connection comes back through pf, and the flow maker only offloads again what pf still passes. pf keeps existing states across a reload, as usual, so a connection that has to stop needs its state killed. That's what the block-list and JA4 cuts do, and both are measured: https://npuforge.org/docs/measurements/lists-cut-2026-10-19/
2) Telemetry. The full list is here: https://npuforge.org/docs/problem-reports/ In short:
- A problem report carries the problem's own log lines (or a panic's backtrace) and a description of the machine: model, board revision, BIOS, CPU and memory, the coprocessor and NICs by PCI id, the OPNsense and kernel versions, and the installed commit of each plugin. IP and MAC addresses, e-mail addresses, serials, the UUID, the host name and domain, keys and long hex strings are removed before the report is even stored. The appliance is named by 12 hex digits of a hash of its serial and UUID. "View" on the page shows the exact text that would be sent.
- It goes to a small relay, reports.npuforge.org, a Cloudflare Worker whose code is in the repo (https://github.com/AbdelmonemAwad/os-xgs-npu/blob/main/relay/worker.js), and it files the report as a public GitHub issue. The relay keeps the sending address for two days for its rate limit, and nothing else.
- The daily count sends three things: a random ID the box made for itself (nothing read from the hardware), the model as SMBIOS names it, and the installed release. No address is kept, and count.py --show prints it without sending anything.
On the default: it's on because there are eight models I've never had in my hands, and a report is the only way I see what breaks on them. But you're not the first to say opt-in would be easier to accept, so I'm weighing it seriously.
3) Trust in the image. It isn't signed or bit-for-bit reproducible yet, but here's what you can check today:
- The OPNsense image underneath is the official one, checked against the SHA-256 its release publishes. The builder refuses to build from anything it can't verify.
- The driver isn't in the image as a binary. Its source is, at a recorded commit, and the appliance compiles it at first boot against its own kernel sources, so what ends up in your kernel is source you can diff against the tag. Every other component is fetched at a commit listed in the build's summary.
- The build runs in your own fork, from a workflow you can read, and its log stays in your account.
- Releases are published immutable, with GitHub's release attestation: gh release verify v0.1.0-alpha.5.4 -R AbdelmonemAwad/os-xgs-npu. Updates from the GUI fetch that tag's commit and confirm it with GitHub directly.
A signed build attestation for the image itself is a fair ask, and I'll look at adding it.
Thanks again for reading it this carefully.
Abdelmonem
Thank you, these are exactly the questions I'd ask too.
1) Intrusion detection. You're right. The flow maker hands a connection to the coprocessor after its first data, so Suricata sees how each connection starts (the TLS ClientHello, enough for a JA4 fingerprint) and nothing after that. Inline IPS mode hasn't been tested with the offload yet, so for now I'd treat the two as either/or.
To keep traffic out of the offload:
- XGS: Settings has "Never offloaded": addresses, networks and ports, up to 64 entries, and either end of a connection can match. Those connections always stay with pf, and Suricata sees all of them.
- Any single connection can be sent back with "Return to host" on the Offloaded Flows page.
- Or turn acceleration off, and every packet goes through the host like on any OPNsense box.
Connections the Traffic Shaper or the Captive Portal names stay on the host by themselves.
When the rules change: every ruleset reload empties the coprocessor's whole flow table before the new ruleset loads. Every connection comes back through pf, and the flow maker only offloads again what pf still passes. pf keeps existing states across a reload, as usual, so a connection that has to stop needs its state killed. That's what the block-list and JA4 cuts do, and both are measured: https://npuforge.org/docs/measurements/lists-cut-2026-10-19/
2) Telemetry. The full list is here: https://npuforge.org/docs/problem-reports/ In short:
- A problem report carries the problem's own log lines (or a panic's backtrace) and a description of the machine: model, board revision, BIOS, CPU and memory, the coprocessor and NICs by PCI id, the OPNsense and kernel versions, and the installed commit of each plugin. IP and MAC addresses, e-mail addresses, serials, the UUID, the host name and domain, keys and long hex strings are removed before the report is even stored. The appliance is named by 12 hex digits of a hash of its serial and UUID. "View" on the page shows the exact text that would be sent.
- It goes to a small relay, reports.npuforge.org, a Cloudflare Worker whose code is in the repo (https://github.com/AbdelmonemAwad/os-xgs-npu/blob/main/relay/worker.js), and it files the report as a public GitHub issue. The relay keeps the sending address for two days for its rate limit, and nothing else.
- The daily count sends three things: a random ID the box made for itself (nothing read from the hardware), the model as SMBIOS names it, and the installed release. No address is kept, and count.py --show prints it without sending anything.
On the default: it's on because there are eight models I've never had in my hands, and a report is the only way I see what breaks on them. But you're not the first to say opt-in would be easier to accept, so I'm weighing it seriously.
3) Trust in the image. It isn't signed or bit-for-bit reproducible yet, but here's what you can check today:
- The OPNsense image underneath is the official one, checked against the SHA-256 its release publishes. The builder refuses to build from anything it can't verify.
- The driver isn't in the image as a binary. Its source is, at a recorded commit, and the appliance compiles it at first boot against its own kernel sources, so what ends up in your kernel is source you can diff against the tag. Every other component is fetched at a commit listed in the build's summary.
- The build runs in your own fork, from a workflow you can read, and its log stays in your account.
- Releases are published immutable, with GitHub's release attestation: gh release verify v0.1.0-alpha.5.4 -R AbdelmonemAwad/os-xgs-npu. Updates from the GUI fetch that tag's commit and confirm it with GitHub directly.
A signed build attestation for the image itself is a fair ask, and I'll look at adding it.
Thanks again for reading it this carefully.
Abdelmonem
#10
26.7 Series / Re: ACME cron renewal fails bu...
Last post by caoyadong888 - Today at 02:36:09 AMCron and manual run the same acme.sh line in your paste, so the plugin path is fine; the difference is almost always environment or timing at midnight, not a different challenge type.
Useful checks, in order:
1. Capture one failed cron and one successful manual run with debug still on, and compare the first Cloudflare / dns_cf / TXT error above the exit code 2. That line usually says whether the API token failed, the TXT record was missing, or propagation timed out.
2. Confirm the Cloudflare token in the ACME account still has Zone:DNS:Edit on that zone, and that /var/etc/acme-client/accounts/.../account.conf is readable by the process that cron starts (manual GUI renew sometimes inherits a richer environment).
3. Around 00:00, look in System → Log Files (and any leftover _acme-challenge TXT records in Cloudflare). Leftover TXT from a half-failed run, or CF rate limiting at the top of the hour, both show up as "validation failed" even though a later manual renew works.
4. Shift the ACME auto-renewal window away from 00:00:00 if you can, and verify NTP is synced. Also check you do not have a second cron or external acme.sh --cron fighting the GUI job.
5. For day-to-day debugging: after a failed cron, do not change settings—renew once from the GUI and keep both log blocks. If the only difference is DNS propagation / API errors at night, the workaround of a later schedule is more reliable than chasing permissions that only fail once a day.
If you can paste just the dns_cf / Cloudflare error lines from a failed 00:00 run (redact tokens), it is usually enough to tell API vs propagation apart.
Useful checks, in order:
1. Capture one failed cron and one successful manual run with debug still on, and compare the first Cloudflare / dns_cf / TXT error above the exit code 2. That line usually says whether the API token failed, the TXT record was missing, or propagation timed out.
2. Confirm the Cloudflare token in the ACME account still has Zone:DNS:Edit on that zone, and that /var/etc/acme-client/accounts/.../account.conf is readable by the process that cron starts (manual GUI renew sometimes inherits a richer environment).
3. Around 00:00, look in System → Log Files (and any leftover _acme-challenge TXT records in Cloudflare). Leftover TXT from a half-failed run, or CF rate limiting at the top of the hour, both show up as "validation failed" even though a later manual renew works.
4. Shift the ACME auto-renewal window away from 00:00:00 if you can, and verify NTP is synced. Also check you do not have a second cron or external acme.sh --cron fighting the GUI job.
5. For day-to-day debugging: after a failed cron, do not change settings—renew once from the GUI and keep both log blocks. If the only difference is DNS propagation / API errors at night, the workaround of a later schedule is more reliable than chasing permissions that only fail once a day.
If you can paste just the dns_cf / Cloudflare error lines from a failed 00:00 run (redact tokens), it is usually enough to tell API vs propagation apart.
