Messages

Thanks for the guide! I can understand and relate to both sentiments; years ago I'd have been thrilled to have a "personal" IP so I could just send print jobs to my home printer instead of emailing attachments, with the convenience of not needing dynamic DNS even.
But today the sole reliance on properly configured and working firewall rules seems to not suffice to counter the ever-increasing threat the internet poses. So now that I have it, I don't want it anymore.
And AFAICS, the one singular purpose of a firewall is to break connectivity, it's the whole idea behind it. So it makes sense to have an additional layer of "connectivity breakage by default", unless you truly need to provide services that cannot be put in a DMZ, for which you'd be willing to lower the "breakage level". It's all a matter of use case, and the real boon of IPv6 to me is not to be forced to use one or the other, even if the use case doesn't lend itself well to it, anymore.

Plus I don't feel like reconfiguring all my devices whenever I change ISPs or when/if they decide to send me a different prefix. So I looked for guides such as this, and before finding yours I found this one:
https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/
I totally love how he clearly expresses his resentment of NAT, in a refreshingly humorous way, only to grudgingly set it up himself because it provides a solution to his problem. :)

Right, the actual thing I'd set out to ask is if using the officially assigned "private" range (ULAs, fc00::/7), which makes the system prefer IPv4 over IPv6, would be an impediment if I relegate IPv4 to local hosts only, anyway, with using IPv6 for WAN exclusively?
Edit: seems like it is ( https://datatracker.ietf.org/doc/html/draft-buraglio-v6ops-ula-05 ) in cases of v6-only hosts (do those even exist yet?) or if I deny outbound IPv4. I'd still rather use the ULAs over other ranges in the hope they'll be declared "unroutable" and therefore unable to leak into the internet because the first ISP router would block them.

Quick edit: Oh, and reduce your net.inet.rss.buckets?

It might be that the driver just can't live with this not matching, IDK what this number depends on, so maybe setting it directly doesn't have much effect.

I had success bringing a measly onboard RTL8168B up to speed while following this guide, which basically confirms jonny5s statement: ( https://binaryimpulse.com/2022/11/opnsense-performance-tuning-for-multi-gigabit-internet/ ).
That device originally had a stability issue when MSI/MSI-X was enabled (a "BIOS" (EFI) update fixed that) but still was slow and couldn't handle --bidir, so I switched to the proprietary drivers and then started tinkering with that guide. The sections following the "dispatch" setting occasionally gave incremental improvements, but the big boost came from the stuff above and including "dispatch" setting.
I had an iperf3 -P4 --bidir -t3600 running to a server on the OPNsense box itself during the tweaking, and indeed only after setting the "net.isr.dispatch" to "deferred" it had a notable effect. I had set and applied each setting sequentially in order to see if anything changed in the iperf3, maybe that matters? I'm too new to BSD tuning to be able to judge this reliably, so all I can do is share my observations on a really low-end device.

I've read that some ISPs use VLAN for their access stuff, so it would seem logical to assume that your VLAN setup conflicts with their VLAN and unless you pick the proper one (there's a list where some are listed: https://habbie.github.io/isp-vlans/) or they don't use VLAN it can't communicate just as you describe.

By chance I checked my still open shell and saw "pkg-static 92615 - [meta sequenceId="1"] opnsense-25.7.6 installed". Reloading the also still open browser window indeed brought back the dashboard like nothing ever happened. It's still not done yet but probably will end up finishing in due time. Apparently I wasn't patient enough last time.

BTW: it's a bit bothersome that one doesn't seem to be able to install missing plugins when an update is pending, at least it said I need to update first. Since I had recovered using a vanilla download, my reloaded config made it miss the plugins (it's working though). I'd have preferred to install them before retrying the update, though they're not essential.

Edit: it's indeed gone through and now is fully updated. However, during my restoring, I found that console settings aren't restored: nano has primary console set to "serial" and secondary to "VGA" by default, which I had changed around to "VGA" primary and "serial" secondary. The restore seemed to restore everything but not this. It's readily reproducible, just store the config, change the setting, apply, restore and reboot: the stored setting will not be restored.

You simply wait, as I've found out:
it seems like the upgrade indeed was just taking a coffee break. I've restored and then re-run the update. The GUI stopped responding at the exact same spot, but since this time I had opened a root shell, I was able to see that it indeed was and still is doing stuff. It's literally crawling around at about 0.1MB/s, mostly stuck waiting on block I/O. In /var/log/pkg/pkg<xxxxxxx>.log I can see that it still is making progress, so even though the GUI still is 404, it's doing its thing. Obviously, disk speed is the abcolutely determining factor here, on fast drives you might not even notice the outage when half the root fs isn't there, while on slower drives it'll be more likely to hit the window of opportunity. Having seen all that I'm pretty confident that even my snail will come back to life eventually. I'll need another storage device since I can't have day-long outages every couple weeks once I actually deploy it (well, I can if the core function stays active). But this trickle-writes probably are going to kill the thumbdrive sooner rather than later, even with /var and /tmp mounted as tmpfs as they are in -nano.
Reveal: I'm used to XigmaNAS (embedded), which does its updates as one large file in a couple of minutes at most, and otherwise runs completely in memory, so I sort of expected the same from -nano, especially given that bad actors might somehow manage to write to the filesystem. With a memory-only fs, it'll just be one reboot away from a clean system. OPNsense seems to be more hdd-centric with its package system, I'll need to adjust to this.

[3]

The 403 is expected, that always happens when the webgui is restarted: you're forcefully logged out, all access is rightly denied. Just go back to the index page, log in and done, like you did, nothing to be concerned about. You could run an audit. If this finds any missing or corrupt files, it should correct or at least report them, unless they're config files which probably aren't being checked (but a check would be possible for presence and syntax at least; semantics would also be possible, like if everything required is there and nothing extraneous, and even if the contents make sense, like if you have DHCP and a static IP configured for the same interface (unless that's a supported feature of course)).
So, everyone for whom the box came back from a 404, did you perchance look at the CPU usage? I had waited 30 minutes and the CPU was 100% idle before I killed it. The problem is that I'm using a thumbdrive so I have no indication of disk activity, and also it is very slow. The previous update took 2 hours to complete, and the CPU was mostly idle but not entirely (between 85% and 96% idle), but never 100% so I knew it hadn't died. I may try the update again and just leave it sit overnight in case it actually is just having a coffee break or something. ;)

I am on the -nano image, maybe there's a connection between working and failing and partially failing updates there?

...didn't go smoothly at all. First, the pkg was updated but threw some errors trying to follow-up the upgrade (so it hadn't already updated itself, I have no cron set up, OK). Then the second, "actual" update popped the respective note but after updating the first package I also got the "Danger" message like apunkt described, but with a "404 Not Found". However, I was still logged in over ssh, but only as normal user. Trying to su failed with "/usr/local/libexec/opnsense-auth: not found". Uh-oh. Investigating revealed that indeed that file wasn't there. So I waited a while (sadly, with thumbdrives, you don't see if the system actually is doing anything, but the CPU being 100% idle in top didn't bode well). 30 minutes later: the same situation, so I decided to reboot. As expected, the boot popped a bunch of errors about missing this and not finding that. "No problem, I got backups". So I yanked the thumbdrive and shoved the 25.7-nano image back onto it. Back in the system, reconfigured the interfaces and went to the GUI to restore the config, only to be greeted by

Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/etc/inc/rrd.inc:56 Stack trace: #0 /usr/local/www/diag_backup.php(337): rrd_import() #1 {main} thrown in /usr/local/etc/inc/rrd.inc on line 56

Oh, c'mon! So what is this file, anyway?

global $config;
    foreach ($config['rrddata']['rrddatafile'] as $rrd) {
        if (!empty($rrd['xmldata'])) {

Right, so it's parsing some part of the file in a loop. Inserting some logging messages revealed that it wasn't even getting into the loop. So what is this "rrddata", anyway? Looking at the config after manually decrypting it revealed this, right at the end:

<syslog/>
        <rrddata>
        </rrddata>
</opnsense>

So it choked on the tag being there but empty. Therefore I just removed these two lines, and loading the config finally worked. Then I recall having unchecked "Do not backup RRD data." in the config backup setup, which is checked by default. So by trying to make sure I lost nothing, I seem to have found a small bug. In fact, the restore had restored all settings (the ones I checked, anyway), but the dashboard and service changes hadn't been applied yet (it failed, so didn't bother/dare to reload/restart anything).

Anyway, the system is now restoring and I'm going to try the upgrade again, hopefully with better results this time... ;)

Edit: uhm, no.

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 25.7 (amd64) at Fri Oct 24 04:34:27 CEST 2025
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 (171 candidates): .......... done
Processing candidates (171 candidates): ..... done
The following 77 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    boost-libs: 1.88.0_1 -> 1.88.0_2
    ca_root_nss: 3.108 -> 3.115_3
    curl: 8.14.1 -> 8.16.0
    easy-rsa: 3.2.3,1 -> 3.2.4,1
    expat: 2.7.1 -> 2.7.3
    ivykis: 0.43.2 -> 0.43.2_1
    jq: 1.8.0 -> 1.8.1
    kea: 2.6.3_1 -> 3.0.1_1
    krb5: 1.21.3_1 -> 1.22.1
    libcbor: 0.12.0_2 -> 0.13.0
    libinotify: 20240724_2 -> 20240724_3
    libnghttp2: 1.66.0 -> 1.67.1
    libpfctl: 0.15 -> 0.17
    libucl: 0.9.2_1 -> 0.9.2_2
    libunistring: 1.3 -> 1.4.1
    lighttpd: 1.4.79 -> 1.4.82
    nspr: 4.36 -> 4.37
    nss: 3.113.1_1 -> 3.117
    openssh-portable: 10.0.p1_1,1 -> 10.2.p1,1
    openssl: 3.0.17,1 -> 3.0.18,1
    openvpn: 2.6.14 -> 2.6.15
    opnsense: 25.7 -> 25.7.6
    opnsense-lang: 25.1.11 -> 25.7.4
    opnsense-update: 25.7 -> 25.7.5_1
    pcre2: 10.45_1 -> 10.46
    perl5: 5.40.2_2 -> 5.42.0_1
    php83: 8.3.23 -> 8.3.26
    php83-ctype: 8.3.23 -> 8.3.26
    php83-curl: 8.3.23 -> 8.3.26
    php83-dom: 8.3.23 -> 8.3.26
    php83-filter: 8.3.23 -> 8.3.26
    php83-gettext: 8.3.23 -> 8.3.26
    php83-ldap: 8.3.23 -> 8.3.26
    php83-mbstring: 8.3.23 -> 8.3.26
    php83-pcntl: 8.3.23 -> 8.3.26
    php83-pdo: 8.3.23 -> 8.3.26
    php83-phpseclib: 3.0.46 -> 3.0.47
    php83-session: 8.3.23 -> 8.3.26
    php83-simplexml: 8.3.23 -> 8.3.26
    php83-sockets: 8.3.23 -> 8.3.26
    php83-sqlite3: 8.3.23_1 -> 8.3.26
    php83-xml: 8.3.23 -> 8.3.26
    php83-zlib: 8.3.23 -> 8.3.26
    py311-anyio: 4.9.0 -> 4.11.0
    py311-certifi: 2025.6.15 -> 2025.8.3
    py311-charset-normalizer: 3.4.2 -> 3.4.3
    py311-cryptography: 44.0.3_2,1 -> 44.0.3_4,1
    py311-dnspython: 2.7.0,1 -> 2.8.0,1
    py311-duckdb: 1.3.1_1 -> 1.3.2
    py311-jq: 1.8.0_1 -> 1.10.0
    py311-markupsafe: 3.0.2 -> 3.0.3
    py311-numexpr: 2.11.0 -> 2.13.0
    py311-numpy: 1.26.4_6,1 -> 1.26.4_7,1
    py311-pandas: 2.2.3_2,1 -> 2.2.3_3,1
    py311-pycparser: 2.22 -> 2.23
    py311-pyyaml: 6.0.1_1 -> 6.0.3
    py311-requests: 2.32.4 -> 2.32.5
    py311-sqlite3: 3.11.13_11 -> 3.11.14_11
    py311-trio: 0.30.0 -> 0.31.0
    py311-truststore: 0.10.1 -> 0.10.4
    py311-typing-extensions: 4.14.0 -> 4.15.0
    py311-ujson: 5.10.0_1 -> 5.11.0
    py311-urllib3: 1.26.20,1 -> 2.5.0,1
    python311: 3.11.13 -> 3.11.14
    strongswan: 5.9.14 -> 6.0.1
    sudo: 1.9.17p1 -> 1.9.17p2
    suricata: 7.0.11_1 -> 8.0.1
    syslog-ng: 4.8.2_3 -> 4.10.2
    unbound: 1.23.1 -> 1.24.0
    wpa_supplicant: 2.11_5 -> 2.11_7

Installed packages to be REINSTALLED:
    cyrus-sasl-2.1.28_5 (provided shared library changed)
    cyrus-sasl-gssapi-2.1.28 (provided shared library changed)
    dnsmasq-2.91_1,1 (required shared library changed)
    glib-2.84.1_3,2 (required shared library changed)
    ntp-4.2.8p18_4 (direct dependency changed: perl5)
    openldap26-client-2.6.10 (required shared library changed)
    rrdtool-1.9.0_1 (direct dependency changed: perl5)

Number of packages to be upgraded: 70
Number of packages to be reinstalled: 7

The process will require 9 MiB more space.
155 MiB to be downloaded.
[1/77] Fetching py311-sqlite3-3.11.14_11.pkg: ..... done
[2/77] Fetching py311-anyio-4.11.0.pkg: .......... done
[3/77] Fetching unbound-1.24.0.pkg: .......... done
[4/77] Fetching wpa_supplicant-2.11_7.pkg: .......... done
[5/77] Fetching py311-cryptography-44.0.3_4,1.pkg: .......... done
[6/77] Fetching lighttpd-1.4.82.pkg: .......... done
[7/77] Fetching php83-filter-8.3.26.pkg: ... done
[8/77] Fetching opnsense-update-25.7.5_1.pkg: ..... done
[9/77] Fetching py311-pandas-2.2.3_3,1.pkg: .......... done
[10/77] Fetching openssl-3.0.18,1.pkg: .......... done
[11/77] Fetching php83-curl-8.3.26.pkg: ...... done
[12/77] Fetching boost-libs-1.88.0_2.pkg: .......... done
[13/77] Fetching py311-numpy-1.26.4_7,1.pkg: .......... done
[14/77] Fetching py311-pycparser-2.23.pkg: .......... done
[15/77] Fetching nss-3.117.pkg: .......... done
[16/77] Fetching libunistring-1.4.1.pkg: ......... done
[17/77] Fetching py311-charset-normalizer-3.4.3.pkg: .......... done
[18/77] Fetching php83-ldap-8.3.26.pkg: ..... done
[19/77] Fetching easy-rsa-3.2.4,1.pkg: ....... done
[20/77] Fetching libcbor-0.13.0.pkg: ....... done
[21/77] Fetching py311-pyyaml-6.0.3.pkg: .......... done
[22/77] Fetching cyrus-sasl-gssapi-2.1.28.pkg: .... done
[23/77] Fetching openvpn-2.6.15.pkg: .......... done
[24/77] Fetching jq-1.8.1.pkg: .......... done
[25/77] Fetching krb5-1.22.1.pkg: .......... done
[26/77] Fetching libnghttp2-1.67.1.pkg: .......... done
[27/77] Fetching dnsmasq-2.91_1,1.pkg: .......... done
[28/77] Fetching php83-simplexml-8.3.26.pkg: .... done
[29/77] Fetching php83-pdo-8.3.26.pkg: ....... done
[30/77] Fetching rrdtool-1.9.0_1.pkg: .......... done
[31/77] Fetching ntp-4.2.8p18_4.pkg: .......... done
[32/77] Fetching syslog-ng-4.10.2.pkg: .......... done
[33/77] Fetching py311-markupsafe-3.0.3.pkg: ... done
[34/77] Fetching php83-sockets-8.3.26.pkg: ...... done
[35/77] Fetching py311-jq-1.10.0.pkg: ....... done
[36/77] Fetching py311-requests-2.32.5.pkg: .......... done
[37/77] Fetching php83-pcntl-8.3.26.pkg: ... done
[38/77] Fetching ca_root_nss-3.115_3.pkg: .......... done
[39/77] Fetching php83-sqlite3-8.3.26.pkg: .... done
[40/77] Fetching libinotify-20240724_3.pkg: .... done
[41/77] Fetching python311-3.11.14.pkg: .......... done
[42/77] Fetching py311-trio-0.31.0.pkg: .......... done
[43/77] Fetching py311-dnspython-2.8.0,1.pkg: .......... done
[44/77] Fetching ivykis-0.43.2_1.pkg: .......... done
[45/77] Fetching php83-phpseclib-3.0.47.pkg: .......... done
[46/77] Fetching php83-session-8.3.26.pkg: ..... done
[47/77] Fetching py311-certifi-2025.8.3.pkg: .......... done
[48/77] Fetching kea-3.0.1_1.pkg: .......... done
[49/77] Fetching php83-mbstring-8.3.26.pkg: .......... done
[50/77] Fetching php83-gettext-8.3.26.pkg: . done
[51/77] Fetching php83-zlib-8.3.26.pkg: ... done
[52/77] Fetching pcre2-10.46.pkg: .......... done
[53/77] Fetching php83-ctype-8.3.26.pkg: . done
[54/77] Fetching curl-8.16.0.pkg: .......... done
[55/77] Fetching nspr-4.37.pkg: .......... done
[56/77] Fetching py311-numexpr-2.13.0.pkg: .......... done
[57/77] Fetching php83-8.3.26.pkg: .......... done
[58/77] Fetching libpfctl-0.17.pkg: .. done
[59/77] Fetching py311-truststore-0.10.4.pkg: ..... done
[60/77] Fetching py311-urllib3-2.5.0,1.pkg: .......... done
[61/77] Fetching cyrus-sasl-2.1.28_5.pkg: ........ done
[62/77] Fetching openssh-portable-10.2.p1,1.pkg: .......... done
[63/77] Fetching php83-xml-8.3.26.pkg: ... done
[64/77] Fetching php83-dom-8.3.26.pkg: ......... done
[65/77] Fetching suricata-8.0.1.pkg: .......... done
[66/77] Fetching openldap26-client-2.6.10.pkg: .......... done
[67/77] Fetching glib-2.84.1_3,2.pkg: .......... done
[68/77] Fetching libucl-0.9.2_2.pkg: .......... done
[69/77] Fetching perl5-5.42.0_1.pkg: .......... done
[70/77] Fetching py311-ujson-5.11.0.pkg: ....... done
[71/77] Fetching opnsense-25.7.6.pkg: .......... done
[72/77] Fetching py311-duckdb-1.3.2.pkg: .......... done
[73/77] Fetching py311-typing-extensions-4.15.0.pkg: .......... done
[74/77] Fetching strongswan-6.0.1.pkg: .......... done
[75/77] Fetching sudo-1.9.17p2.pkg: .......... done
[76/77] Fetching opnsense-lang-25.7.4.pkg: .......... done
[77/77] Fetching expat-2.7.3.pkg: .......... done
Checking integrity... done (0 conflicting)
[1/136] Upgrading libcbor from 0.12.0_2 to 0.13.0...
[1/136] Extracting libcbor-0.13.0: .......... done
[2/136] Upgrading libpfctl from 0.15 to 0.17...
[2/136] Extracting libpfctl-0.17: ...... done
[3/136] Upgrading libunistring from 1.3 to 1.4.1...
[3/136] Extracting libunistring-1.4.1: .......... doneThen the "Danger" message pops up and things are failing again. Seems like it's one of those days. I'll go to bed now.