Recent posts

#1
26.1, 26,4 Series / 26.1.7_2: issue with ACME clie...
Last post by Rene78 - Today at 07:31:11 PM
Hi,

I have a working ACME client setup with a wildcard Let's Encrypt certificate for my domain. Also have a working nginx based reverse proxy to three services. Those services are running on a TrueNAS SCALE 25.10.3 (latest patch) system.

While all https access to the services is working fine through nginx with A+ trusted HTTPS (reverse proxy handles upstream stuff on the LAN to TrueNAS) the services on the TrueNAS system still use selfsigned certs from the TrueNAS box.

Now, while not essential (I trust my home lan ;-)) I am trying to get the whole certificate chain proper. Just a hobby thing.

Therefore I made an API key (root) on my TrueNAS and created the automation in the ACME client. Used the websocket (not deprecated one). Filled in all the fields, which are self explanatory. Reran the automations from the commands in OPNsense but the upload errors out.

[Mon May 4 18:02:46 CEST 2026] TrueNAS API key not found, please set the DEPLOY_TRUENAS_APIKEY environment variable.

I tried all automation modes (none, ws and wss) but error remains. The API key is really in the appropriate field. The plugin however does not seem to set the value from the field in the environment variable.

I am a little at hand (no ssh) from my phone currently so no CLI attempt possible.

Anybody recognize this? Seems a bug...


#2
German - Deutsch / Re: Erfahrungen bei ersten Geh...
Last post by sternchen45 - Today at 07:02:34 PM
ich bin da auch irgendwann mal davor gestanden und kann noch die Anekdote anbringen, dass Routen, die von der Fritz!Box annonciert werden (z.B. weil die Netze hinter der OPNsense sind, die wiederum im LAN der Fritz!Box ist), per ICMP Redirect kommen, was von macOS per design dropped wird. Da kann man lange durch Logs gehen und den Live-Filter ansehen.

Von Tagen Troubleshooting war es 99%, bis man verstanden hat, wo der Unterschied zu anderen OS aus dem Test kommt.
#3
@DEC740airp414user use "ps awwwux | grep python3" to see what these python processes are doing.
#4
German - Deutsch / Re: Öffentlicher IPv6-Suffix ä...
Last post by Maurice - Today at 06:27:48 PM
Quote from: mooh on Today at 01:05:28 PMIch bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".
Die Konfiguration bezieht sich nur auf DHCPv6. Die RAs der Telekom enthalten aber zusätzlich ein /64 mit A-Flag, weshalb das WAN-Interface eine per SLAAC autokonfigurierte Adresse bekommt. Das ist völlig unabhängig von DHCPv6. Es gibt in OPNsense leider keine einfache Möglichkeit, SLAAC zu deaktivieren.

Quote from: psychofaktory on Today at 01:56:12 PMSollte das dann nicht an das zugrundeliegende Interface gekoppelt sein, oder zumindest statisch bleiben?
Das wäre aus User-Sicht sicherlich sinnvoll. Wie genau SLAAC auf PPP-Interfaces in FreeBSD / OPNsense implementiert ist habe ich gerade nicht im Kopf. Ggfs. ein Issue auf GitHub aufmachen.

Quote from: psychofaktory on Today at 01:56:12 PMNein, das manuelle setzen der Schnittstellen-ID hat leider nicht funktioniert. Es wird immer wieder die EUI-64 verwendet. Nach wie vor vom falschen Interface.
Dann bezieht sich das nur auf Track Interface bzw. Interface Association und nicht auf SLAAC. Eigentlich auch logisch. SLAAC passiert soweit ich mich erinnere im Kernel, da hat OPNsense wahrscheinlich wenig Einfluss drauf.
#5
Tutorials and FAQs / Re: [How-To] NPTv6 with dynami...
Last post by Maurice - Today at 06:08:40 PM
2601:xx:xxxx:3168::/64 is on-link on the loopback interface, which effectively blackholes this prefix when trying to connect to it from interfaces other than the WAN. It's a side effect of the loopback workaround.
#6
German - Deutsch / Re: Öffentlicher IPv6-Suffix ä...
Last post by mooh - Today at 06:06:10 PM
Ich glaube der spannende Teil ist die Sache mit der GUA während "nur Präfix" + DHCPv6 für das WAN aktiviert sind. Das passt nicht zusammen. Das WAN Interface sollte eine Adresse der Art "fe80::<EUI-64>%pppoe0/64" haben.

Ist bei den Routern mal von statischer IPv6 Konfig auf DHCPv6 umgestellt worden? Kann da was durcheinander gegangen sein?
#7
Hi everyone,

Please don't roast me in the replies as I'm quite new to networking & OPNsense. I wanted to tinker with VLANs on my home network, as well as segregate my IoT devices for privacy reasons, so in my opinion, my setup isn't really all that complex, nor would I consider myself a heavy user.

I was running OPNsense on an EliteDesk previously for several weeks and it was incredibly stable. However, I wanted to upgrade to 2.5 GbE speeds as my internet plan is 3 Gbps, so I purchased A Topton device from AliExpress (https://www.toptonpc.com/product/intel-n150-7505-6305-6x-i226-v-2-5g-solid-firewall-router-fanless-mini-pc-ddr4-nvme-1com-type-c-pfsense-opnsense-mini-computer/) -- I specifically got the 6305 model, and I loaded the same config to the new device (I obviously set the new interfaces, but otherwise the VLANs, firewall rules, etc. stayed the same). I do not have IDS or IPS enabled.

I have seen a lot of chatter on the forums that i226-V NICs have quite a bit of instability, but almost entirely related to dropped packets, random disconnects, etc. However, my issue is that my device freezes entirely and is unresponsive to SSH, ping, WebGUI (even when directly connected to one of the devices available ports). I have tried a number of different settings to try to get this sorted and I'm at my wit's end. The longest I've been able to keep this box online was 3.5 days, but it usually freezes up once per day, and there is nothing specific I am able to tie it to.

Here are my questions for the community:

  • Has anyone seen this exact pattern? (EEE fix helps, ASPM tunable presumably makes worse or does nothing)
  • Is BIOS-level ASPM/C-state disabling necessary in addition to OS tunables? Or should OS tunables be sufficient?
  • Any reports of Topton N150 + i226-V + bare metal OPNsense running stable? What settings were used?
  • Is NIC firmware V2.32 worth the flash, or should I focus on BIOS tweaks first?
  • Has anyone modified/updated the BIOS on a Topton N150? Board: HSX-TGLNP V126

Below is all the detail I can possibly think of that will hopefully help someone diagnose the root cause. Otherwise, I'm going back to the EliteDesk setup, because my network going down at least once a day is not something I want to be dealing with.

Hardware Setup
Topton X6E (marketed as N150):
CPU: Intel Celeron 6305 @ 1.80GHz (Tiger Lake UP3, 2 cores)
NICs: 6x Intel i226-V 2.5GbE
Current EEPROM: V2.14-0 eTrack 0x80000290
Community max available: V2.32 (via BillyCurtis GitHub)
RAM: DDR4 SO-DIMM (16GB, ex-EliteDesk hardware)
Storage: WDC PC SN720 256GB NVMe (ex-EliteDesk)
Form Factor: Fanless + external case fan running 24/7
BIOS: AMI `HSX-TGLNP-12-V126` dated 2024-01-29
Network:
3Gbps fiber ISP (Telus, Canadian) (10G port in bridged mode connected to the OPNsense WAN port. 1G ports of Telus modem not connected to anything)
OPNsense runs bare metal (NOT virtualized)
Router position: between fiber modem and Proxmox host
CPU utilization: ~5-10% under normal load

Symptoms
System freezes completely:
Cannot SSH or ping box
Watchdog does not trigger
WebGUI unresponsive
NIC LEDs still blinking (power + activity present)
Power cycle always fixes it (temporarily — 1-3 days uptime before next freeze)
No kernel panic messages in logs before freeze, in fact there is nothing useful in the logs as to why this is happening
Nothing major running when freezes occur (e.g., qBittorrent seeding only '1 torrent total])
Timeline:
2026-04-29: Daily crashes discovered → disabled EEE → uptime improved to 3.5-4 days
2026-05-02: Crash after ~3.5 days → disabled ASPM tunable → uptime dropped to ~15 hours
2026-05-03: Still crashing; applied additional interrupt delay tunables (no improvement)

Tunables Applied (System → Settings → Tunables)
All listed below are confirmed working via `sysctl` commands:
Tunable   Value   Purpose   Verified
`dev.igc.0.eee_control`   `0`   Disable Energy Efficient Ethernet on NIC 0   `sysctl dev.igc.0.eee_control`
`dev.igc.1.eee_control`   `0`   " NIC 1   ✓ all 6 NICs
`dev.igc.2.eee_control`   `0`   " NIC 2   ✓
`dev.igc.3.eee_control`   `0`   " NIC 3   ✓
`dev.igc.4.eee_control`   `0`   " NIC 4   ✓
`dev.igc.5.eee_control`   `0`   " NIC 5   ✓
`hw.pci.enable_aspm`   `0`   Disable ASPM (link power saving)   `pciconf -lvc | grep ASPM`
`hw.igc.rx_abs_int_delay`   `0`   Disable RX interrupt delay (prevent NIC hang on timer)   Added 2026-05-03
`hw.igc.tx_abs_int_delay`   `0`   Disable TX interrupt delay   Added 2026-05-03

Interface settings (System → Settings → Networking):
Hardware CRC offload: ✓ Disabled
Hardware TSO: ✓ Disabled
Hardware LRO: ✓ Disabled
Hardware state:
C-states: Currently set to C1
Speed Shift: Not configured

What's Been Ruled Out
NVMe: FreeBSD's nvme driver does not implement APST; drive stays in PS0. `sysctl dev.nvme.0` shows zero failures/retries/recovery events.
RAM: Worked without issue in prior EliteDesk hardware. Not investigated further.
Temperature: External case fan runs 24/7; system never exceeds 29.5°C even under load.

Hypothesis
The system is freezing at the OS/hardware level, not crashing. No kernel panic logs suggests either:
A power state incompatibility (C-states + i226-V on FreeBSD) that the tunable alone can't fix
Interrupt handling issue with the NICs during idle/light load
BIOS-level power management conflicting with OPNsense settings
Key observation: Disabling EEE improved uptime 24x (daily → 3.5 days), but ASPM tunable presumably made it worse--or did nothing (15 hours), suggesting hardware-level power management in BIOS may be overriding the OS-level tunable.

Next Steps Being Investigated

BIOS power management settings:
Disable C-states in BIOS (not just OS-level)
Disable ASPM in BIOS hardware config
Verify Power Limit 1 (PL1) and Power Limit 2 (PL2) settings
NIC firmware upgrade (if BIOS changes don't help):
Billy Curtis community firmware: V2.14 → V2.32
Verified MD5 hashes before flashing
Will update via Linux + nvmupdate64e tool
BIOS firmware update (last resort):
Current BIOS dated 2024-01-29; no public update found
Considering contacting AliExpress seller

Any help would be greatly appreciated. Thank you in advance.
#8
General Discussion / Re: smart TV causes memory usa...
Last post by nero355 - Today at 04:56:06 PM
When it comes to Samsung TVs I am not surprised : https://discourse.pi-hole.net/t/this-is-what-your-dashboard-looks-like-with-a-samsung-tv/3165 ;)

And in general anything Samsung has a lot of pre-installed crap on it so you should uninstall or disable as much as stuff as possible anyway ;)

Another thing you could look at is how much EULA stuff you REALLY NEED in order to have a functioning TV : Usually you don't need all of them and the ones you can avoid are also usually the ones that deliver you the most advertising crap !!
#9
was out of upload size space
#10
seems to be python and unbound.  unbound always takes up over a 1gb of ram for me