Messages

searching my OPNsense filesystem I cannot find Kea's hook file "libddns_gss_tsig.so.What I want to know is there a way to install the necessary Kea GSS-TSIG file on OPNsense? "

it is not installable as a package .

OPNsense package isn't built that way..there is no file to copy in

Let Windows clients self-register via option 81 (Client FQDN), or move only D2 (kea-dhcp-ddns) to a Linux VM built with Kerberos enabled.

Don't use a shared-key TSIG on an AD-integrated zone set to Secure only

On the power cut: the DC is the real dependency, not the DHCP host --> the clients can register themselves once it's up

It's documented here : https://www.zenarmor.com/docs/guides/best-practices-for-zenarmor-deployment#reporting-database

Thanks Nero355 this is exacltly the link

Also Remote Elasticsearch must be between 8.9.x and 8.17.1, so not "any 8.x".

The leftover mongodb.so is normal. Older ZenArmor versions installed MongoDB automatically on firewalls with 2–4 GB of RAM max.

@dunxd

Is the report new or old?

does anything actually use it

--------------------------------
    pkg info | grep -i mongo
    ps auxww | grep -i [m]ongo
    sockstat -4 -6 | grep -i mongo
    php -m | grep -i mongo
-----------------------------------

if not

Safe removal

----------------------------------------------------------------------
    cp /usr/local/etc/php/extensions.ini /root/extensions.ini.bak
    pkg delete php85-pecl-mongodb
    pkg autoremove
    grep -n mongodb /usr/local/etc/php/extensions.ini
    configctl webgui restart
-----------------------------------------------------------------------

Building still fails...

Ouch. Not the week for builds, apparently. Hope you get it sorted

from your log the fault isn't in Zenarmor, pf or the driver: it's in netmap's mbuf destructor, hit after the emulated adapter for igc1 was already destroyed.

003.908331 generic_netmap_dtor Emulated netmap adapter for igc1 destroyed → 003.986713 generic_mbuf_dtor Error: no netmap adapter on device 0xfffff800019f1800

Check
 
 https://github.com/opnsense/src/issues/314

 this looks like the same defect and the issue is still open..

Attach panic_during_update.txt: that file is the textdump 

In my case mongodb.so was a leftover from an older ZenArmor install. ZenArmor itself is still installed but no longer uses MongoDB: as of v2.5 (September 2025) MongoDB and Elasticsearch 5 were dropped as reporting backends, so the current reporting runs on SQLite or Elasticsearch 8.

Removing the package had no effect on filtering.

I removed it anyway rather than keep an unused extension around: it carries its own update and CVE surface, and an extension nobody needs is just extra code loaded into every PHP process.

best

the upgrade took more than an hour, the longest one I've done so far, but everything came up fine afterwards.

No gateway issues and no wrong address family here.

Also

every Wi-Fi client must support WPA2/WPA3-Enterprise with EAP-TLS and carry its own certificate — otherwise it simply will not connect

Devices without that support (printers, TVs) need a separate WPA2-PSK SSID instead.

I feel like it has become a sort of "Lost art" to read the information correctly and the right way by now.
A lot of people just check for "Red/Orange/Green Lights" so to speak and move on instead of diving really into it... :(

That's the whole point.

The log speaks before the drive dies.

Read the log as a habit, not as a verdict.

A drive doesn't usually go from healthy to dead between two reboots.

One look a month is all it takes.

But this does worry me :

Code Select Expand

Code Select Expand

SMART Attributes Data Structure revision number: 32
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   050    Pre-fail  Always       -       12
181 Program_Fail_Cnt_Total  0x0022   100   100   000    Old_age   Always       -       11643680983326
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       2794
195 Hardware_ECC_Recovered  0x003a   100   100   000    Old_age   Always       -       3772716375
199 UDMA_CRC_Error_Count    0x0022   100   100   000    Old_age   Always       -       2

None of those five is close to failing, and to watch


The attributes nearest their thresholds are 173 (41 against 10, average block erase count) and 170 (99 against 10, reserved blocks), which is normal for a drive with 1780 erase cycles and plenty of spare area.



  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       9997
 11 Unknown_SSD_Attribute   0x0022   100   100   000    Old_age   Always       -       140
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       2920
170 Unknown_Attribute       0x0033   099   099   010    Pre-fail  Always       -       16
171 Unknown_Attribute       0x0022   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
173 Unknown_Attribute       0x0033   041   041   010    Pre-fail  Always       -       1780
174 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       140
181 Program_Fail_Cnt_Total  0x0022   100   100   000    Old_age   Always       -       11643680983326
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       2794
190 Airflow_Temperature_Cel 0x0022   031   021   000    Old_age   Always       -       69 (Min/Max 14/79)



this was a good   troubleshooting.

IMHO, if someone wants to check a disk for errors, this thread is a reasonable starting point.

Are you sure the SATA Controller of your device is 100% OK ?!

Keep an eye on those numbers please!

And this one :

Code Select Expand

Code Select Expand

196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       16

Can be ignored, because it looks like it's the same default value before any firmware update that the Crucial M500 Series had at the time.
After the first firmware update the value was reset to 0 again so I am guessing the same goes for this Micron SSD.

On the controller: I see no sign of trouble. dmesg shows no resets, timeouts or retries, the self-test passes and the error log is empty. The counters that could grow (188 = 2794, 199 = 2) are both still at 100.

On 196: agreed, ignore it. On his drive 170 (Reserved_Block_Count) is also 16, and on other M500s 170 = 17 goes with 196 = 17, so it just mirrors the spare blocks.

-----------------------------@nero355----You always spot the details  :) --------- Good on you man------------------------------------------


What counts is stable: self-test clean, error log empty, 5% wear, and only the 69/79 °C worth fixing



If you want to go deeper


Run smartctl -t long /dev/ada0

After 5 min run  smartctl -a /dev/ada0 and compare   5, 188 and 199 with today's values.

Hi Shad,

Yes, smartctl is reading the SMART data even though some attribute names remain unknown. Your output already includes power-on hours, temperature, self-test results and the error log. The separate endurance check also reports 5% used.

SMART is supported and enabled, and your output confirms that the data is being read. Only some attribute names remain unidentified.

The results are good.  At the end is a new disk

Also, your report shows 69°C currently and a recorded maximum of 79°C. I would check airflow around the SSD and, if space allows, consider a suitable low-profile heatsink or a small fan to improve cooling.

Thanks for reporting back!

New smart scan also shows unknow_attribute although it comes from a reputable brand (Micron).

Hi Shad,

Unknown_Attribute alone does not indicate a faulty  obsolete drive. Several Micron models are already supported, so could you post:

smartctl -i /dev/ada0
smartctl -P show /dev/ada0

You can remove the serial number before posting.

You can also try a newer drive database without replacing the installed one:

fetch -o /root/smart_drivedb.h https://raw.githubusercontent.com/smartmontools/smartmontools/main/drivedb/drivedb.h
smartctl -B +/root/smart_drivedb.h -a /dev/ada0

Let us know whether any of the Unknown_Attribute names change.

I'm leaning towards the Huawei B535-232 LTE Cat 7, mainly for the price. For less money, I don't think I'd find anything comparable with external SMA connectors, Gigabit Ethernet, and good backup-WAN suitability.

For more control I'd consider an industrial router like the Teltonika RUT950 100+ euros (but less powerfull) or the TELTONIKA RUTX11 which is  400+ euros.

Also  I'm unsure about LTE band support and whether it's carrier-locked. The Huawei may offer fewer option controls, but I know it works reliably with my band provider.

Once everything is working behind OPNsense, I may open a new post with my WAN failover configuration

I am curious : Which one did you buy exactly ?

I am currently evaluating either a Huawei B535-232 (LTE Cat 7) or a ZTE MF296R (LTE Cat 6). Do you have any experience with either of them, or would you recommend a different external LTE router for this use case? Ideally I am looking for something reliable, 300Mbps with an Ethernet port for OPNsense, external SMA antenna connectors MIMO and good LTE performance as a backup WAN

Just a quick update on this thread

Unfortunately, I was unable to install the Quectel EC25-EUX Mini PCIe module in my  N100/N5105 firewall mini-PC

The mini-PC has a Mini PCIe slot intended for WiFi/3G/4G modems and an onboard SIM slot, the module physically does not fit in the slot due to its thickness

I have decided to use a different approach for WAN2 (4G/LTE failover): an external LTE router with its own SIM slot, external SMA antenna connectors and an Ethernet WAN/LAN port. This also avoids the USB power limitations of the mini-PC.

Since the LTE router is external, OPNsense will no longer manage the modem directly.

WAN2 failover remains unchanged: OPNsense will use the 4g modem port as a DHCP WAN interface, monitor its gateway, and route traffic through a gateway group with WAN1 as Tier 1 and WAN2/LTE as Tier 2.

I will also add a firewall rule allowing a specific VLAN to reach the 4g modem  IP over HTTP/HTTPS via the WAN2 gateway.

The only difference is that APN, SIM, signal and firmware management will be done in the 4g modem UI instead of OPNsense which is a pity..

For anyone else considering an internal Mini PCIe LTE modem in a compact N100/N5105 firewall: check the physical clearance and module thickness first. Even if the modem is software-compatible with OPNsense/FreeBSD, it may simply not fit mechanically.

If a VPN is configured, an SSH tunnel is not needed. Just access the GUI directly over the VPN.

You're right. If the WebGUI is reachable over the VPN, no SSH tunnel is needed.

But A user can use both VPN and SSH: the VPN gives secure network access, while SSH provides a remote shell for diagnostics, logs, configuration changes and recovery. The VPN alone lets them reach the WebGUI, but SSH is what gives them terminal access.

I saw your repository and it looks interesting. I'll test it soon to receive notifications on Telegram

Regards,
MARLOO