Hi,
For the brave early testers the upgrade path is now live:
1. Switch to release type "development" and save.
2. Check for updates and install.
3. Check for updates again and it will offer 26.7.rc1 and install.
4. After upgrade switch back to release type "community" and save.
5. Check for updates and install 26.7.r1.
This will make the installed files match the published RC1 images.
A note of caution:
This is a major upgrade in the exact sense of the word: FreeBSD 15.1, PHP 8.5 and OpenSSL 3.5 are the components where we can be sure more problems are hiding somewhere, but we won't find out any other way. If you have third party repository or plugin installed proceed with caution: we do not vet upgrades of them and they are likely not ready to make the jump. Removing them beforehand is likely the best course of action at the moment.
Cheers,
Franco
Just upgraded my lab firewall from 26.1.11_6 to 26.7.r1 without issue.
>>> If you have third party repository or plugin installed proceed with caution
As usual Zenarmor users will need to wait for an official announcement.
The mimugmail repository will have to be rebuilt against openssl35.
Until that happens and there's an announcement from Michael packages depending on the openssl3.0 will be silently uninstalled during the upgrade ( i.e. Unifi controller )
I upgraded my test VM from 26.1.11_6 to 26.7.r1. I have some minor observations:
1) I had to check for updates multiple times at steps 2, 3 and 5. But the update eventually completed and it is running fine.
2) Thanks @newsense for posting about the mimugmail respository. I also ran into the same problem using the single repository with just AdGuard (mimugmail-single.conf). I could not get the upgrade to complete with that repo configured and I ended up needing to delete the repo config.
Just out of curiosity, has anyone built a digital twin (or as near as possible) of their network using Proxmox's SDN to better simulate testing/rules with VLANs? I tried to create one using Proxmox v8 last year but it didn't handle VLANs well and I haven't tried again with v9.
PS - The new services dashboard widget is great!
>>> single repository with just AdGuard (mimugmail-single.conf)
Actually AGH is the outlier that survives the upgrade to openssl35 - because AGH uses its own ssl from Go.
Still, the mimugmail repo-whichever may be in use - needs to be deleted ( as suggested above) or renamed as .bak for now in order for the OPNsense upgrade to succeed.
I tried to reinstall AGH single repository under 26.7.r1 and I still get the error:
pkg: Repository mimugmail has a wrong packagesite, need to re-create database
You don't add the current mimugmail repos on a 26.7.x OPNsense
You don't need the mimugmail repos for AGH if already installed. The AGH updates will work just fine
As long as BE and CE are on different versions of OpenSSL there should be a dedicated version of that 3rd party repository built against the respective OpenSSL target
Actually I used the 26.7 RC1 Image for a "Fresh" Installation on Baremetal...
From the Console I Assigned my WAN/LAN Interfaces, a "New" IPv4 LAN Address and Specified an IPv4 DHCP Range for my LAN Interface...
Unfortunately the Laptop connected to the LAN Interface was NOT being assigned its IP Addresses and therefore I was unable to Connect to the OPNsense Web Interface!!!
After Assigning Static IPv4 IP Addresses to the Laptop, I was able to able to Restore my 26.1 Confirguation...
From there I was able to install the "Missing" Plug-INs, Restored my 26.1 Configuration a Second Time and after that things have proceeded "Normally"...
@LHoust Still partially set up for ISC DHCP perhaps?
Cheers,
Franco
@newsense - thanks for confirming. Yes, AGH continues to run under 26.7 even though the repo does not work.
I opened an issue on the MAXIT GitHub: https://github.com/mimugmail/opn-repo/issues/300 (https://github.com/mimugmail/opn-repo/issues/300)
I expect the repo is not working because the ABI directory changes from FreeBSD:14:amd64 to FreeBSD:15:amd64 and it's simply not available yet.
Cheers,
Franco
Quote from: franco on July 09, 2026, 07:27:42 AM@LHoust Still partially set up for ISC DHCP perhaps?
Cheers,
Franco
Although my 26.1 Configuration uses Kea DHCPv4, the os-isc-dhcp Plug-IN was installed as part of my Configuration Restoration...
My assumption being the DHCP Range Assigned from the Console into my "Fresh" RC1 Installation should Support Kea DHCPv4 without adding any Plug-INs???
The range set pivots it to Dnsmasq which may have clashed with Kea on the same port.
We are aware of the problem but want to refrain from rewriting too much of this ancient console code at the moment. I think this is a future work item for when all pages are finally converted to MVC.
Cheers,
Franco
I've upgraded my system to OPNsense 26.7.r2_3-amd64 and noticed the following Blocked Firewall Logs without any Label after every reboot:
WG Out 2026-07-12T09:25:39 IP :: ff02:16 block
WG Out 2026-07-12T09:25:38 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:29 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:28 IP :: ff02::16 block
Is that normal or is this a leftover which needs to be hidden or corrected?
Thanks for your hard work. 26.7 is really nice so far!
All the best,
Wrigleys
Labels are off due to a kernel error but we found the problem already, see https://github.com/opnsense/src/issues/295
Quote from: franco on July 12, 2026, 12:51:27 PMLabels are off due to a kernel error but we found the problem already, see https://github.com/opnsense/src/issues/295
Great, thanks for that!
Quote from: franco on July 12, 2026, 12:51:27 PMLabels are off due to a kernel error but we found the problem already, see https://github.com/opnsense/src/issues/295
Hi Franco,
Sorry for this follow-up. I assume that this issue has deen fixed and implemented in the new 26.7 kernel but unfortunate, I'm still seeing FW-Logs without Label after every reboot. I've upgraded my appliance from RC2 to 26.7 this morning.
Thanks and regards,
Wrigleys
Do these rules have descriptions? If they don't have descriptions there will be no label correlation.
In my case all rules have descriptions. For automatic generated rules and for my manually added rules. I think that those label-less rules are proceeded in the background. Could it be from kernel-/pf-internal filter rules?
Response from ChatGPT:If the entries:
- only occur during boot,
- appear only once or twice per restart,
- have the destination ff02::16,
- and never reappear until the next reboot,
then they are most likely related to the initialization of the IPv6 networking stack. During startup, FreeBSD/OPNsense registers multicast group memberships on active interfaces using MLDv2 (Multicast Listener Discovery v2). The IPv6 multicast address ff02::16 is specifically reserved for all MLDv2-capable routers.
The fact that the source address is shown as :: (the IPv6 unspecified address) also fits the startup phase of an interface, before a normal IPv6 address has been fully configured. IPv6 control protocols can legitimately use special addresses during initialization.
The upgrade to OPNsense 26.7 (which is based on FreeBSD 15.1) likely changed how these packets are logged or made them visible in the firewall log. The underlying behavior itself is probably not new.
ConclusionBased on the symptoms you described, these log entries look like normal IPv6/MLDv2 startup traffic generated during interface initialization. The upgrade likely made the packets visible in the logs, but there is no indication of an actual networking or security problem.
Quote from: Wrigleys on July 12, 2026, 09:43:35 AMI've upgraded my system to OPNsense 26.7.r2_3-amd64 and noticed the following Blocked Firewall Logs without any Label after every reboot:
WG Out 2026-07-12T09:25:39 IP :: ff02:16 block
WG Out 2026-07-12T09:25:38 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:29 IP :: ff02::16 block
WAN Out 2026-07-12T09:25:28 IP :: ff02::16 block
I can confirm this. With current 26.7 I can see this messages for all interfaces at startup. Later on I can see allow messages from WAN from fe80::22 (connect with ONT Modem and DHCPv6). All my rules have labels and rules are made in this way that I can see only blocks, everything else is not logged. It has worked until latest 26.1 version, know I see this.
I'm still seeing those Label-less blocked filter rules even after installing 26.7 from scratch.
For testing purposes, I've enabled all logs under Firewall - Advanced but those few Label-less blocked filter rules are still there after a reboot.
It looks like a backend kernel-/pf-internal filter rules, which we unfortunately can't handle.
Can you grab the relevant entries from the firewall plain log?
Sure, here you go:
2026-07-15T21:54:03 Informational filterlog ,,,0,wg0,ip-option,block,out,6,0x00,0x00000,1,ip,0,76,::,ff02::16,INVALIDOPT
2026-07-15T21:54:00 Informational filterlog ,,,0,wg0,ip-option,block,out,6,0x00,0x00000,1,ip,0,76,::,ff02::16,INVALIDOPT
2026-07-15T21:53:53 Informational filterlog ,,,0,igb1,ip-option,block,out,6,0x00,0x00000,1,ip,0,36,::,ff02::16,INVALIDOPT
␀␀␀
Thanks for your help!
Output from ChatGPT:The sequence fits well with the following startup behavior:
- OPNsense boots up.
- IPv6 is initialized on the interfaces (igb1, wg0).
- The kernel or network services generate initial IPv6 multicast/MLD packets.
- At that moment, the interface may not yet have a fully configured IPv6 address, which is why the source address appears as ::.
- PF (the packet filter) classifies the packet as INVALIDOPT and drops it.
- A few seconds later, interface initialization is complete and IPv6 operates normally.
The fact that the packets are sent to ff02::16 (the MLDv2 multicast address) and appear only during startup strongly suggests an IPv6 initialization/timing issue rather than a configuration error.
Mine look like this (mac address shorted)
2026-07-16T09:34:52 Informational filterlog,,,0,vtnet1,normalize,pass,out,6,0xc0,0x00000,254,ipv6-icmp,58,32,fe80::22,fe80::short,datalength=32
2026-07-16T09:32:41 Informational filterlog,,,0,vtnet1,normalize,pass,out,6,0xc0,0x00000,254,ipv6-icmp,58,32,fe80::22,fe80::short,datalength=32
2026-07-16T09:20:31 Informational filterlog,,,0,vtnet2,ip-option,block,in,6,0x00,0x00000,1,ip,0,36,::,ff02::16,INVALIDOPT
Yes so according to https://github.com/opnsense/ports/blob/master/opnsense/filterlog/files/description.txt
rulenr = empty
subrulenr = empty
anchorname = empty
label = 0
Which basically means this isn't a rule coming from our generated rules or pf doesn't know where this log entry comes from at all.
Cheers,
Franco
I have looked into "Firewall -> Settings -> Advanced"
There are two new options which seems new to me (they're also in English and not translated into German as this my language as default).
Disable RFC4890 requirement rules
Disable port 0 block
Both options are not set in my case, so rules are created. All default logging options are disabled.
So maybe in this two settings the log options are not respected? (just a wild guess)
Quote from: franco on July 16, 2026, 09:58:44 AMYes so according to https://github.com/opnsense/ports/blob/master/opnsense/filterlog/files/description.txt
rulenr = empty
subrulenr = empty
anchorname = empty
label = 0
Which basically means this isn't a rule coming from our generated rules or pf doesn't know where this log entry comes from at all.
Cheers,
Franco
Thanks franco for this clarification. Makes sense to me. Therefore we have to wait and see if upstream FreeBSD will fix it in upcoming patches/releases.
@Ampfinger: as far as I understood, as long as the Packetfilter System returning Logs starting with 0, there are no options to configure inside OPNsense to prevent those logs from listing/spamming.