Recent posts

#1
26.7 Series / Re: Issue upgrading from 26.7....
Last post by tm - Today at 10:13:17 PM
Thank you for confirming the fix. I encountered the same problem today when upgrading my primary Opnsense firewall from 26.7.1 to 26.7.2_2 via the GUI. Reinstalling with the release 26.7 image, using importer to restore my configuration, upgrading via the GUI to release 26.7.2_2 and reinstalling my Plugins resolved the problem.

I did not encounter any problems when upgrading from 26.7.1 to 26.7.2_2 via the GUI on my backup Opnsense firewall.  It has the same configuration except different interface names and no Zenarmor (os-sensei) Plugin.

Primary Firewall
CPU: Intel i5-14500T
MB: ASRock IMB-X1314
NICs: Intel I225-LM/I225-V

Backup Firewall
CPU: AMD GX-412TC
MB:  PCEngines apu2b4
NICs: i210AT

Primary Opnsense Firewall 26.7.1 to 26.7.2_2 upgrade error

exec/sbin/init: error 8
init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:rescue/init
panic: no init
cpuid = 1
time = 1787501561
KDB: stack backtrace:
db_trace_self_wapper() at db_trace_self_wapper+0x2b/frame 0xfffffe014c60bcd0
vpanic() at vpanic+0x136/frame 0xfffffe014c60be00
panic() at panic+0x43/frame 0xfffffe014c60bef0
start_init() at start_init+0x265/frame 0xfffffe014c60bef0
fork_exit() at fork_exit+0x7b/frame 0xfffffe014c60bf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01d4c60bf30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at   kdb_enter+0x33: movq $0,0x15a8af2(%rip)
db>
#2
26.7 Series / Installed 26.7 - Trying to mov...
Last post by Pat.Ryan - Today at 10:03:25 PM
I have 26.7 installed and just still setting things up. Looking at moving from pfSense to OPNsense. Tried to add ACME and got an error that said I needed a more recent version. Standard update check says no updates available even though there are two other versions showing (26.7.1 and 26.7.2).

The error I get when trying to add ACME is:
***GOT REQUEST TO INSTALL***
Currently running OPNsense 26.7 (amd64) at Sun Aug 23 12:59:55 PDT 2026
Installation out of date. The update to opnsense-26.7.2_2 is required.
***DONE***

If I move to the development track and check for updates I get:
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.7 (amd64) at Sun Aug 23 13:00:28 PDT 2026
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 930 packages processed.
All repositories are up to date.
Upgrading package manager from version '' to '2.3.1_1'
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
OPNsense is up to date.
pkg: pkg is not installed, therefore upgrade is impossible
Checking integrity... done (0 conflicting)
Your packages are up to date.
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ......... done
Processing entries: .......... done
OPNsense repository update completed. 930 packages processed.
All repositories are up to date.
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
The following 169 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   beep: 1.0_2 [OPNsense]
   boost-libs: 1.89.0_2 [OPNsense]
   brotli: 1.2.0,1 [OPNsense]
   ca_root_nss: 3.125 [OPNsense]
   choparp: 20150613_1 [OPNsense]
   colordiff: 1.0.22 [OPNsense]
   cpdup: 1.22_1 [OPNsense]
   cpustats: 0.1 [OPNsense]
   curl: 8.21.0 [OPNsense]
   cyrus-sasl: 2.1.28_5 [OPNsense]
   cyrus-sasl-gssapi: 2.1.28 [OPNsense]
   dhcp6c: 20260122 [OPNsense]
   dhcrelay: 1.0 [OPNsense]
   dnsmasq: 2.93,1 [OPNsense]
   dpinger: 3.6 [OPNsense]
   easy-rsa: 3.2.6,1 [OPNsense]
   expat: 2.8.2 [OPNsense]
   filterlog: 0.8 [OPNsense]
   flock: 2.37.2_1 [OPNsense]
   flowd: 0.9.1_5 [OPNsense]
   gettext-runtime: 1.0_1 [OPNsense]
   glib: 2.86.4,2 [OPNsense]
   gmp: 6.3.0 [OPNsense]
   hostapd: 2.12_2 [OPNsense]
   hostwatch: 1.0.13 [OPNsense]
   hyperscan: 5.4.2 [OPNsense]
   icu: 76.1,1 [OPNsense]
   ifinfo: 13.0_1 [OPNsense]
   iftop: 1.0.p4_1 [OPNsense]
   indexinfo: 0.3.1_1 [OPNsense]
   ivykis: 0.43.2_1 [OPNsense]
   jansson: 2.15.1 [OPNsense]
   jq: 1.8.2 [OPNsense]
   json-c: 0.19 [OPNsense]
   kea: 3.0.3 [OPNsense]
   krb5: 1.22.2_2 [OPNsense]
   ldns: 1.9.2 [OPNsense]
   libcbor: 0.14.0 [OPNsense]
   libedit: 3.1.20260512,1 [OPNsense]
   libevent: 2.1.13 [OPNsense]
   libffi: 3.6.0 [OPNsense]
   libfido2: 1.17.0 [OPNsense]
   libiconv: 1.18_1 [OPNsense]
   libidn2: 2.3.8 [OPNsense]
   libltdl: 2.5.4 [OPNsense]
   liblz4: 1.10.0_2,1 [OPNsense]
   libmcrypt: 2.5.8_4 [OPNsense]
   libnet: 1.3,1 [OPNsense]
   libnghttp2: 1.69.0 [OPNsense]
   libpfctl: 0.17 [OPNsense]
   libpsl: 0.21.5_2 [OPNsense]
   libsodium: 1.0.22 [OPNsense]
   libucl: 0.9.4 [OPNsense]
   libunistring: 1.4.2 [OPNsense]
   libuuid: 2.42.2 [OPNsense]
   libxml2: 2.15.3 [OPNsense]
   libyaml: 0.2.5 [OPNsense]
   lighttpd: 1.4.85 [OPNsense]
   log4cplus: 2.1.2 [OPNsense]
   lua54: 5.4.8 [OPNsense]
   lzo2: 2.10_2 [OPNsense]
   monit: 5.35.2 [OPNsense]
   mpd5: 5.9_19 [OPNsense]
   mpdecimal: 4.0.1 [OPNsense]
   nettle: 3.10.2 [OPNsense]
   nspr: 4.39 [OPNsense]
   nss: 3.126 [OPNsense]
   ntp: 4.2.8p18_5 [OPNsense]
   oniguruma: 6.9.10 [OPNsense]
   openldap26-client: 2.6.14 [OPNsense]
   openssh-portable: 10.4.p1,1 [OPNsense]
   openssl35: 3.5.7 [OPNsense]
   openvpn: 2.7.6 [OPNsense]
   opnsense-devel: 27.1.a_119 [OPNsense]
   opnsense-installer: 26.7 [OPNsense]
   opnsense-lang: 26.1.7 [OPNsense]
   opnsense-update: 26.7.2 [OPNsense]
   pam_opnsense: 24.1 [OPNsense]
   pcre2: 10.47_1 [OPNsense]
   perl5: 5.42.2 [OPNsense]
   pftop: 0.13 [OPNsense]
   php85: 8.5.8 [OPNsense]
   php85-ctype: 8.5.8 [OPNsense]
   php85-curl: 8.5.8 [OPNsense]
   php85-dom: 8.5.8 [OPNsense]
   php85-filter: 8.5.8 [OPNsense]
   php85-gettext: 8.5.8 [OPNsense]
   php85-ldap: 8.5.8 [OPNsense]
   php85-mbstring: 8.5.8 [OPNsense]
   php85-pcntl: 8.5.8 [OPNsense]
   php85-pdo: 8.5.8 [OPNsense]
   php85-pear: 1.10.18 [OPNsense]
   php85-pear-Crypt_CHAP: 1.5.0_1 [OPNsense]
   php85-pecl-mcrypt: 1.0.9 [OPNsense]
   php85-pecl-radius: 1.4.0b1_4 [OPNsense]
   php85-phalcon: 5.18.2 [OPNsense]
   php85-phpseclib: 3.0.55 [OPNsense]
   php85-session: 8.5.8 [OPNsense]
   php85-simplexml: 8.5.8 [OPNsense]
   php85-sockets: 8.5.8 [OPNsense]
   php85-sqlite3: 8.5.8 [OPNsense]
   php85-xml: 8.5.8 [OPNsense]
   php85-zlib: 8.5.8 [OPNsense]
   pkcs11-helper: 1.31.0 [OPNsense]
   pkg: 2.3.1_1 [OPNsense]
   py313-Babel: 2.18.0 [OPNsense]
   py313-Jinja2: 3.1.6 [OPNsense]
   py313-aioquic: 1.3.0_1 [OPNsense]
   py313-anyio: 4.13.0 [OPNsense]
   py313-async_generator: 1.10_1 [OPNsense]
   py313-attrs: 26.1.0 [OPNsense]
   py313-bottleneck: 1.6.0_2 [OPNsense]
   py313-certifi: 2026.6.17 [OPNsense]
   py313-cffi: 2.0.0 [OPNsense]
   py313-charset-normalizer: 3.4.7 [OPNsense]
   py313-cryptography: 48.0.1,1 [OPNsense]
   py313-dnspython: 2.8.0_1,1 [OPNsense]
   py313-duckdb: 1.5.5 [OPNsense]
   py313-h11: 0.16.0 [OPNsense]
   py313-h2: 4.3.0 [OPNsense]
   py313-hpack: 4.1.0 [OPNsense]
   py313-httpcore: 1.0.9 [OPNsense]
   py313-httpx: 0.28.1_2 [OPNsense]
   py313-hyperframe: 6.1.0 [OPNsense]
   py313-idna: 3.18 [OPNsense]
   py313-jq: 1.11.0 [OPNsense]
   py313-ldap3: 2.9.1_1 [OPNsense]
   py313-markupsafe: 3.0.3 [OPNsense]
   py313-numexpr: 2.14.1_2 [OPNsense]
   py313-numpy: 2.4.6_1,1 [OPNsense]
   py313-outcome: 1.3.0_2 [OPNsense]
   py313-packaging: 26.2 [OPNsense]
   py313-pandas: 2.3.3_3,1 [OPNsense]
   py313-pyasn1: 0.6.0 [OPNsense]
   py313-pyasn1-modules: 0.4.1 [OPNsense]
   py313-pycparser: 2.23 [OPNsense]
   py313-pylsqpack: 0.3.24 [OPNsense]
   py313-pyopenssl: 26.2.0,1 [OPNsense]
   py313-pysocks: 1.7.1_1 [OPNsense]
   py313-python-dateutil: 2.9.0 [OPNsense]
   py313-pytz: 2026.2,1 [OPNsense]
   py313-pyyaml: 6.0.3 [OPNsense]
   py313-requests: 2.34.2 [OPNsense]
   py313-service-identity: 24.2.0 [OPNsense]
   py313-six: 1.17.0 [OPNsense]
   py313-sniffio: 1.3.1 [OPNsense]
   py313-socksio: 1.0.0_1 [OPNsense]
   py313-sortedcontainers: 2.4.0_1 [OPNsense]
   py313-sqlite3: 3.13.15_10 [OPNsense]
   py313-trio: 0.33.0 [OPNsense]
   py313-truststore: 0.10.4 [OPNsense]
   py313-tzdata: 2026.2 [OPNsense]
   py313-ujson: 5.12.1 [OPNsense]
   py313-urllib3: 2.7.0,1 [OPNsense]
   py313-vici: 6.0.3 [OPNsense]
   python313: 3.13.15 [OPNsense]
   radvd: 2.20 [OPNsense]
   readline: 8.3.3 [OPNsense]
   rrdtool: 1.9.0_1 [OPNsense]
   samplicator: 1.3.8.r1_1 [OPNsense]
   sqlite3: 3.53.3,1 [OPNsense]
   strongswan: 6.0.7 [OPNsense]
   sudo: 1.9.17p2_2 [OPNsense]
   suricata: 8.0.6 [OPNsense]
   syslog-ng: 4.12.0 [OPNsense]
   unbound: 1.26.0 [OPNsense]
   wpa_supplicant: 2.12_1 [OPNsense]
   zip: 3.0_5 [OPNsense]
   zstd: 1.5.7_2 [OPNsense]

Number of packages to be installed: 169

The process will require 1 GiB more space.
222 MiB to be downloaded.

If I try to update I get:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.7 (amd64) at Sun Aug 23 13:02:50 PDT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: . done
The following package files will be deleted:
   /var/cache/pkg/opnsense-26.7.2_2.pkg
   /var/cache/pkg/opnsense-devel-27.1.a_119~96fc2ed938.pkg
   /var/cache/pkg/opnsense-26.7.2_2~34b31765e9.pkg
   /var/cache/pkg/opnsense-devel-27.1.a_119.pkg
The cleanup will free 12 MiB
Deleting files: .... done
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
OPNsense is up to date.
The following packages will be fetched:

New packages to be FETCHED:
   opnsense: 26.7.2_2 (6 MiB: 49.99% of the 12 MiB to download)
   opnsense-devel: 27.1.a_119 (6 MiB: 50.01% of the 12 MiB to download)

Number of packages to be fetched: 2

The process will require 12 MiB more space.
12 MiB to be downloaded.
Fetching opnsense-26.7.2_2.pkg: .......... done
Fetching opnsense-devel-27.1.a_119.pkg: .......... done
pkg-static: No package(s) matching opnsense
Starting web GUI...done.
Partial update failure detected: report this error log to OPNsense.
No further actions will be taken. Please restart the update now.
***DONE***

#3
26.7 Series / Make my backup history safer.
Last post by Roger@Opnsense - Today at 09:57:53 PM
Hi,

I recently did a System → Configuration → Backups → Restore configuration and quickly discovered that I lost everything under /conf/backup.

I guess I should have been a bit more cautious. After looking into it, I see that I had "Flush (full) local configuration history" selected, which I assume explains what happened.

From what I have found, I assume the deleted files are not recoverable through OPNsense itself, particularly since I am using UFS rather than ZFS. I do still have the configuration backups that I downloaded through the interface and stored externally, so I could probably reconstruct at least some of the Git history from those, or simply accept the loss.

Is there any practical way to recover either the old Git repository or the deleted XML configuration files on UFS?

I was also wondering whether the restore behavior could be made a little less aggressive. For example, could "Flush (full) local configuration history" be unchecked by default?

Finally, would moving the Git repository outside /conf/backup and replacing it with a symlink make it safer from this particular operation? For example:

mkdir -p /backup/git
ln -s /backup/git /conf/backup/git

Would the flush operation follow the symlink and delete the target contents, or would it only remove the symlink itself?

Thanks!
#4
26.7 Series / Re: SOLVED: interface works fr...
Last post by jensk - Today at 09:55:07 PM
Hi,

When you boot the FW with the installer USB Stick all interfaces are automatically up.
When you boot the "installed" FW (same kernel, same config) only configured interfaces are up.

When you think about it it is clear, but I was wondering why the interface is not shown a link and a connection speed after the install, when a cable is plugged in. And I posted is because when I search for it I could not find it.

CU
Jens

#5
To reflect on it I use Chatgpt, Claude and self hosted LLMs and also other tools like Stable Diffusion since years now, incrementally seeing how these tools evolve.

Yet I dont pretend to be an expert on the matter, I dont use MCP or autonomous agentic AI yet.

More compute and larger context + time means AI will be able to find more things.

If it's one tool or another doesn't matter that much in the grand scheme of things by how fast it's still evolving.

Im not attaching exceptional significance to one gated Anthropic product because Anthropic says it's exceptionally capable.
#6
Virtual private networks / Re: [Guide] ProtonVPN WireGuar...
Last post by mlenje - Today at 09:34:12 PM
Major update — 2026-08-23: the 1:1 NAT / BINAT workaround is NOT universally required — it's per-server

I want to correct something in my original post that I now believe was wrong, or at least incomplete: I described the BINAT workaround as something you need for any additional simultaneous WireGuard tunnel on a ProtonVPN account. That's not accurate. Whether you need it depends on which specific server you're connecting to — some servers need it, some don't, and there's no way to predict which from the outside.

What I found, testing across multiple tunnels and servers on the same account:

  • Some servers reply to ICMP correctly to whatever local address you've configured, with zero NAT tricks needed — real traffic and monitoring both work out of the box.
  • Other servers — even using an identical client-side setup — reply to ICMP using the old shared default address (10.2.0.2) regardless of what you've configured locally, and need the BINAT workaround to be reachable for monitoring purposes.
  • I initially assumed this was caused by reusing a client keypair across more than one server over time — it isn't. I tested this directly: generated a completely fresh keypair, used with exactly one server that had shown the problem, and it exhibited the exact same behavior. A fresh key doesn't avoid it.
  • Real application traffic (browsing, curl, etc.) works fine either way, on every server I tested — this only affects ICMP-based health monitoring (dpinger, ping, etc.), which is why it's easy to miss if you're not specifically checking.

I honestly don't know why some servers behave this way and others don't — I've emailed ProtonVPN support asking for clarity and will update this post if I get a useful answer. It could be different infrastructure/software versions across the fleet, something account-side, or something else entirely.

Revised recommendation for anyone building multiple simultaneous tunnels: don't build the BINAT/NAT workaround preemptively for every new tunnel. Build the tunnel plainly first (unique local address, standard outbound NAT to "interface address"), then test:

  • Check your gateway monitor status (dpinger, or just [tt]ping[/tt] from the firewall using the tunnel's local address as source).
  • If ICMP fails but real traffic works, check your firewall's live packet log (Firewall > Log Files > Live View in OPNsense) for the blocked reply — look at the actual destination address.
  • If it shows the old shared [tt]10.2.0.2[/tt] (or some other unexpected address) instead of your tunnel's real address, then add the 1:1 BINAT rule, translating that address back to your real one.
  • If you ever change which server a tunnel connects to, re-check — a workaround needed for one server can actively break a different server that replies correctly on its own (learned this the hard way: an active BINAT rule caused a new block once I switched to a server that didn't need it, since its correctly-addressed replies no longer matched the state the BINAT rule expected).
In short: test empirically per server, don't assume.
#7
26.1, 26,4 Series / Re: IPTV stopped working after...
Last post by ou1 - Today at 08:32:46 PM
I managed to get it to work. Somehow, I think the IGMP traffic into my LAN interface was being handled by another firewall rule, before my explicit IGMP rule, which didn't have "Allow options" enabled.

I don't know why this only started happening after the update. At least I learned something in the last couple of days, that a possible cause of tcpdump seeing IGMP traffic and igmp-proxy not could be forgetting to add allowopts on the firewall rule.
#8
Arguing about marketing ploys can be fun indeed, but completely impractical (unless you have access to a board-member of some frontier lab who's suddenly ready to get candid in public about this). Thus, that's not what I'm arguing about.

The more down-to-earth questions that interest me are:
1. Is there utility? Does it make sense to use those tools to find vulns in the code or it is a completely useless exercise?
2. How cost/benefit analysis changes this? Is it prohibitively expensive, or laying hands on these tools is impossible in practice, or there are some other obstacles/costs that make this non-viable?

My (speculative, using implicit evidence) argument was that the answers to these questions are "1. yes, there's one" and "2. not by much".

If from your POV the perceived utility is 0 because the real capability is so far below the advertised one, then it'd be a position, of course. But then there's a counter-argument of "how do you know if you haven't tried yet?".
Your own mention of "impressive findings" among "mundane observations, and garbage" tells me that it might be not as straightforward as this.

That's the questions I was looking to get answers for from you.


P.S.: Maybe I'm too early to the party. A year ago there were still a lot of skeptics (inc. in my circle) who were saying that agents will never be able to write proper code. Now most of them don't even read most of the code that an agent generates, except for the most critical paths. Maybe we'll just have to wait for the Chinese to release something that will force US labs to show their frontier to the public so everyone could try and see. If it all proves a failure, oddly enough I'll be among those celebrating this fact.

#9
I personally didn't have any issues with the RTL USB3 ethernet adaptor. I'm not a gamer and don't transfer large files out of my local network though. However, the N150 was ticking over all the time and I had a better use for it. So I now have a Celeron J6412 4 port 'passive' cooled lump. The passive cooling is ok up to about 20C, but the UK has been reaching nearly 40C for periods this year, and it was getting too hot.

The copper block is very good, with thermal compound between it and the chip and with the aluminium case. But it's not a heat pipe and temps were reaching 100C on occasion. Thermal lag. With a slow running 12" fan it's staying cool.

Unsurprisingly no issues with it either! It's basically ticking over also.

I'm very impressed with OPNsense and it can be considered a 'utility' not an experiment or lab kit. It auto updates every month and basically fit and forget :-)
#10
26.1, 26,4 Series / Re: Upgrade questions
Last post by Patrick M. Hausen - Today at 07:17:59 PM
It's all step by step written on the migration assistant page in the UI. Just follow that. 🙄