https://github.com/opnsense/core/tags
a few more hours of work but yes ;)
We are anxious =)
Well, the announcement is out now. Upgrade path still to do but a bit too much for one day today.
Cheers,
Franco
I just got excited :)
is the old openvpn really gone then? so i cannot upgrade.
Quote from: maclinuxfree on January 28, 2026, 06:20:18 PMis the old openvpn really gone then? so i cannot upgrade.
What exactly do you need that is not in the new OpenVPN?
Quote from: Patrick M. Hausen on January 28, 2026, 06:21:32 PMQuote from: maclinuxfree on January 28, 2026, 06:20:18 PMis the old openvpn really gone then? so i cannot upgrade.
What exactly do you need that is not in the new OpenVPN?
Keys, maybe? ;-)
> is the old openvpn really gone then? so i cannot upgrade.
still there under community plugins
Cheers,
Franco
I haven't upgraded yet from the old OpenVPN Server to the new configuration.
Is this required for 26.1?
You can install the community plugin and continue to use the legacy setup.
Which, being on 25.7, would already be installed anyway. ;)
Cheers,
Franco
strange - our CE nodes are not registering the new 26.1 as installable.
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 25.7.11_2 (amd64) at Thu Jan 29 09:09:19 CET 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.
Checking for upgrades (76 candidates): .......... done
Processing candidates (76 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***
# cat /tmp/pkg_upgrade.json
{
"api_version":"2",
"connection":"ok",
"downgrade_packages":[],
"download_size":"",
"last_check":"Thu Jan 29 09:25:14 CET 2026",
"needs_reboot":"0",
"new_packages":[],
"os_version":"FreeBSD 14.3-RELEASE-p7",
"product_id":"opnsense",
"product_target":"opnsense",
"product_version":"25.7.11_2",
"product_abi":"25.7",
"reinstall_packages":[],
"remove_packages":[],
"repository":"ok",
"upgrade_major_message":"",
"upgrade_major_version":"",
"upgrade_needs_reboot":"0",
"upgrade_packages":[],
"upgrade_sets":[]
}
yesterday the changelog had a wrong date (2025 instead of 2026)
today this is fixed
# /usr/local/opnsense/scripts/firmware/changelog.sh list | grep '\"26\.1\"'
{"series":"26.1","version":"26.1","date":"January 28, 2026"}
but maybe this has been cached somewhere?
https://github.com/opnsense/changelog/blob/86b8199499debb7cc3452d7d585564d9bc384514/community/26.1/26.1#L19-L22
Oh - sorry and thanks for the hint (those who can read have a clear advantage aka. wlkikiV)
No worries. The upgrade path is live now. :)
Cheers,
Franco
Just upgraded from 25.11 to 26.1 via the web-gui on a VM in Proxmox without any problems! :))
Appears to be a bug when trying to create a rule in the new FW GUI that uses the q-feed blocklist alias.
I installed the Q-feed plugin as per the documentation and confirmed the API key is working and downloads the IP and DNS feed.
The alias is also populated with 200K odd entries.
The error when trying to save the rule is "__qfeeds_malware_ip is not a valid source IP address or alias"
When I create the rule using the old FW GUI, the rule is created without any issues.
Hello donks,
I just tried it out, I'm using qfeeds since a while with the new firewall rules GUI. For me on the current 26.1 release I can add and remove rules using the alias.
Are there any additional steps to reproduce?
Quote from: Monviech (Cedrik) on January 29, 2026, 01:14:11 PMHello donks,
I just tried it out, I'm using qfeeds since a while with the new firewall rules GUI. For me on the current 26.1 release I can add and remove rules using the alias.
Are there any additional steps to reproduce?
Okay interesting. I tried to create a rule on the WAN and LAN interface but both failed. Perhaps I'll reboot my device and try again tomorrow.
Just to be sure I also tried it on my LAN interface too, I could also create the rule.
Maybe a reboot will help, but if it's a persistent issue then to post here, the qfeeds maintainer will see and test as well I suppose:
https://forum.opnsense.org/index.php?board=49.0
Thank you to the awesome OPNSense team for another "boring" update. Updated to 26.1 without problem (boring). Removed unused ISC plugin and no longer see those legacy entries under Services (boring). Migrated to new rules interface without incident (boring). Love the new update! My pre-update snapshot will get deleted soon. Yawn :)
Quote from: julsssark on January 29, 2026, 05:26:47 PMMigrated to new rules interface without incident
i receive the following message when i try to import the rules to the new interface:
[interface] Option [enc0] not in list.In the interfaces overview i can see "enc0" but i can't do anything. It's a virtual machine running on Proxmox.
Quote from: donks on January 29, 2026, 12:54:29 PMAppears to be a bug when trying to create a rule in the new FW GUI that uses the q-feed blocklist alias.
I installed the Q-feed plugin as per the documentation and confirmed the API key is working and downloads the IP and DNS feed.
The alias is also populated with 200K odd entries.
The error when trying to save the rule is "__qfeeds_malware_ip is not a valid source IP address or alias"
When I create the rule using the old FW GUI, the rule is created without any issues.
I experienced the same problem as donks described. Before that, I migrated the old rules to the new ones (via migration assistant and according to the process described there).
Later on that day I tried to setup q-feeds as written in their setup guide for opnsense.
I can confirm that it works in the old fw rules section, but not in the new one. As workaround I created this as an old rule and imported it within the new rules section.
Cheers, Mario
Could someone with a Linux client that uses bridge interfaces try to reproduce this?
I changed my switch port to get LAN access in order to perform rule migration in 26.1 and I noticed that my desktop client's bridge did not get a DHCP address on LAN (192.168.1.0/24). The client was stuck with the IP address it had from the client network (172.21.30.0/24).
I also got SLAAC addresses on both networks with two active prefixes, which remained the case even when I switched the port back. Not sure if that's expected but IIRC the interface would drop the prefix when switching ports. At least that's how my laptop works, which is a raw interface with no bridge.
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute br0
valid_lft 69258sec preferred_lft 69258sec
inet6 2601:xx:xxxx:3163:734f:7d77:3ab1:944b/64 scope global temporary dynamic
valid_lft 86355sec preferred_lft 80370sec
inet6 2601:xx:xxxx:3163:xxxx:xxx:xxxx:c3d/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86355sec preferred_lft 86355sec
inet6 2601:xx:xxxx:3161:9bb7:5d29:2077:1560/64 scope global temporary dynamic
valid_lft 81515sec preferred_lft 80370sec
inet6 2601:xx:xxxx:3161:xxxx:xxxx:xxxx:30/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 81515sec preferred_lft 81515sec
inet6 fe80::xxxx:xxxx:xxxx:fb89/64 scope link noprefixroute
My setup is Dnsmasq for DHCP and RAs and I have "Identity Association" set on the interfaces.
This could be something that happened on my end only, but I'm not sure. I don't think I've seen this before.
Quote from: Monviech (Cedrik) on January 29, 2026, 01:43:25 PMJust to be sure I also tried it on my LAN interface too, I could also create the rule.
Maybe a reboot will help, but if it's a persistent issue then to post here, the qfeeds maintainer will see and test as well I suppose:
https://forum.opnsense.org/index.php?board=49.0
A reboot fixed my issue. I can now create the q-feed rules in the new FW GUI.
Quote from: OPNenthu on January 29, 2026, 08:35:49 PMCould someone with a Linux client that uses bridge interfaces try to reproduce this?
I changed my switch port to get LAN access in order to perform rule migration in 26.1 and I noticed that my desktop client's bridge did not get a DHCP address on LAN (192.168.1.0/24). The client was stuck with the IP address it had from the client network (172.21.30.0/24).
I also got SLAAC addresses on both networks with two active prefixes, which remained the case even when I switched the port back. Not sure if that's expected but IIRC the interface would drop the prefix when switching ports. At least that's how my laptop works, which is a raw interface with no bridge.
For my curiosity : Did you UP/DOWN the interface on the Linux Desktop or the Switch during the change ?
And did you have any applications open that were using the network connection and continued using them without closing them first ?
Those two things tend to mess up things most of the time...
Quote from: sc00by1984 on January 29, 2026, 06:13:14 PMi receive the following message when i try to import the rules to the new interface:
[interface] Option [enc0] not in list.In the interfaces overview i can see "enc0" but i can't do anything. It's a virtual machine running on Proxmox.
It's used for IPSec connections : https://man.freebsd.org/cgi/man.cgi?query=enc&sektion=4
So maybe you had that running at some point and now it's no longer in use but there were some related rules leftovers ?!
Quote from: nero355 on January 30, 2026, 04:10:15 AMIt's used for IPSec connections : https://man.freebsd.org/cgi/man.cgi?query=enc&sektion=4 (https://man.freebsd.org/cgi/man.cgi?query=enc&sektion=4)
So maybe you had that running at some point and now it's no longer in use but there were some related rules leftovers ?!
indeed. i removed the legacy ipsec plugin and can't find any rule, but the import still fails unfortunately.
Quote from: nero355 on January 30, 2026, 04:10:15 AMFor my curiosity : Did you UP/DOWN the interface on the Linux Desktop or the Switch during the change ?
I can't :( Ever since I made manual changes to my network layout in NetworkManager, IF up/down commands doesn't have any effect on the bridges. The only thing that works to clear the network stack is to reboot.
QuoteAnd did you have any applications open that were using the network connection and continued using them without closing them first ?
Just FF tabs open at that point. I had shut down the desktop VMs that were running.
Quote from: OPNenthu on January 30, 2026, 10:45:40 AMI can't :(
Ever since I made manual changes to my network layout in NetworkManager, IF up/down commands doesn't have any effect on the bridges.
The only thing that works to clear the network stack is to reboot.
Are you sure : https://man.archlinux.org/man/nmcli.1.en ?!
And if you are running any Desktop Environment on that 'Desktop Client' you should be able to do it with a single click :)
If both things don't work it's time to submit a bug to the NetworkManager developers IMHO...
QuoteJust FF tabs open at that point.
Then there is a chance that Firefox was holding onto the IP stack so to speak and preventing it to recover properly.
At least that's my experience with both the Linux and Windows version.
Quote from: nero355 on January 30, 2026, 03:02:46 PMQuote from: OPNenthu on January 30, 2026, 10:45:40 AMI can't :(
Ever since I made manual changes to my network layout in NetworkManager, IF up/down commands doesn't have any effect on the bridges.
The only thing that works to clear the network stack is to reboot.
Are you sure : https://man.archlinux.org/man/nmcli.1.en ?!
And if you are running any Desktop Environment on that 'Desktop Client' you should be able to do it with a single click :)
If both things don't work it's time to submit a bug to the NetworkManager developers IMHO...
QuoteJust FF tabs open at that point.
Then there is a chance that Firefox was holding onto the IP stack so to speak and preventing it to recover properly.
At least that's my experience with both the Linux and Windows version.
I'll play around some more with the nmcli commands when I get a moment but as for reporting bugs upstream... sigh. This is the downside of Linux and why I wish FreeBSD was on par as a desktop OS. Linux is made up of thousands of independent packages and as a user I would need to open accounts and track bugs all over the damn place. That's not likely to happen if I'm honest.
As a developer of a package or a kernel contributor it's perfectly fine, but as an end user of a distribution it's kind of maddening at times. On the plus side, I've found very little that doesn't work on my particular hardware.
At least OPNsense is easy to contribute / report to. :)
----
UPDATE: to close the loop, I was able to bring the bridge interface down with 'nmcli conn down br0', but the inverse 'nmcli conn up br0' returned success and never actually brought it up. I followed up with 'nmcli device up br0' and this timed out (failed). I then used the GUI toggle switch for the parent interface (which was already up in 'ip a' but showed as down in the GUI) and it brought it back up. However the same toggle switch does not bring the br0 interface down :P
So it's quite an inconsistent mess. Probably either a Mint / Ubuntu bug, or my configuration is just too complex or I set it up incorrectly.
Quote from: OPNenthu on January 30, 2026, 05:42:54 PMUPDATE: to close the loop, I was able to bring the bridge interface down with 'nmcli conn down br0', but the inverse 'nmcli conn up br0' returned success and never actually brought it up.
I followed up with 'nmcli device up br0' and this timed out (failed).
I then used the GUI toggle switch for the parent interface (which was already up in 'ip a' but showed as down in the GUI) and it brought it back up.
However the same toggle switch does not bring the br0 interface down :P
So it's quite an inconsistent mess. Probably either a Mint / Ubuntu bug, or my configuration is just too complex or I set it up incorrectly.
There are a couple more
nmcli options I see mentioned in the man page : Maybe try those too ?
Another option is
nmtui which might help.
And if you are in for an adventure you could try configuring networking via SystemD and remove NetworkManager completely like I did last year :)
I could not open a new thread.
When I start IPS, then OPNsense uses 6.6 GB RAM.
The boot time lies at ~ 3 min (without IPS ~30 sec.).
After that, I disabled IPS. But the boot time remains at ~3 min.
The RAM consumption lies then at ~ 800 MB (without IPS 660 MB).