Hi all,
Behind the scenes we were working on providing the first images for the upcoming 26.7 series. We aligned with the FreeBSD 15.1 release schedule and fixed all the installer compatibilities we've found. From early testing FreeBSD 15.1 behaves pretty well. The main difference from current community versions is PHP 8.5, OpenSSL 3.5 and that this image is only containing the development version. Upgrades to future versions are possible.
For now there's no path to upgrade from an existing 26.1.x but manual instructions can be shared once 26.1.11 is released next week. 26.7-RC1 will also add the stable release path.
You can find the usual images here:
https://pkg.opnsense.org/FreeBSD:15:amd64/snapshots/misc/26.7.b/
SHA256 (OPNsense-devel-26.7.b-dvd-amd64.iso.bz2) = 73fb138ae4ea0f2eccb1f7966a88f78d863a012f15b314105a5533f74b27abad
SHA256 (OPNsense-devel-26.7.b-nano-amd64.img.bz2) = 79c881c87af8fe27eef4d5a94cb7d211296870dc5fcfc00bc409c62fbdaa441f
SHA256 (OPNsense-devel-26.7.b-serial-amd64.img.bz2) = d7f257c7360c840e9d16360ef973cb6ca6b0b9ee10f761751d471ed92f16a0d7
SHA256 (OPNsense-devel-26.7.b-vga-amd64.img.bz2) = 62622a0a1a9954f77edde657fc8c66115977cd115737f475ec53aecc2b97117c
The public key for 26.7 is as follows:
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAziSNKuzrL2cwLx5LXmLn
cWS5Lk+i9CzRMXO/4xQYBQCaSnd8GBg/HA/g4aPoTUa6ovAI0AHfW8KQJQyBkFzn
pi6MLZJ9tEaFcn0CiV+tSTJd1RV4bB8jtpKl5oTkgFrPsyaB7iBlG5Cd49VCW19h
DxClQ24lkWkVoYfsfCQEt4ADNGLygWCPyf4bxGD/t6/tiW9SsOs2+gfOZ9C/G2d/
EBhJFoBEoz5lvULVxTdfY5PScYrHD/waZnk3rGc2A+9pI/SM2JAwKqsgZ6MSFbXO
DNocSjqFUUkdqhty+Qcc0OJ+hMbKKVE+f3QJBQIwT3ayys8QK0m5CCo91/f+DjoN
noj+t5YN9x8GREkF0wrdIi7hevkwrL2/SJQbq1bL1BLB+mMSXYR611lgT8YfYjyZ
7tmpNVC3O5Pj7l20snm1lVUSqS0PsFBvh6HQtBRwQDGppaIIhH1Nt9yIatmSiGZt
2YrMVNBzbQrJzSX+vWcAulkaPIt4t+XxmpO5IDNZ+4uMZ7XyJq1lAhIeyXx+Falf
v7S+ZpJWFVNz0/N5z6lBbADD855i+gFY6B5209xGyhd6FwaPOjISgQKkgBwF1AiW
MDuTuP9lkh/U5gGBZIFTnbdEMgOAL4P+Hsw9Nozav+3QIpiU3Pv9F29a1erCkq09
rpQyNglY7Jqme/RipzbYia8CAwEAAQ==
-----END PUBLIC KEY-----
The roadmap has a few more insights on what to expect: https://opnsense.org/roadmap/
Cheers,
Franco
Ran an upgrade from a 26.7.b_68 VM on Proxmox on Hetzner using OPNsense-devel-26.7.b-dvd-amd64.iso/26.7.b_110.
Booting into the DVD, importing the config from the zroot pool and then ran the installer. Went all smooth, few missing packages which I replaced with the *-devel package variant.
- WAN is set to a static private IPv4 and IPv6/ULA (Proxmox does the NAT-ting)
- LANs have static IPv4 and IPv6 (different ULA), with outbound NAT for both IPv4 and IPv6
- Tayga does what it doas
- KEA for DHCPv4/v6
- Unbound for DNS
All of the above works as it worked before, thanks Devs for the excellent work!
Remark: All the IPv6 NAT-ting is just because I can, I could have solved it different with less NAT but where is the fun in that.
Remark II: I had to re-enable console password protection, otherwise the installer - after importing the config - shows the console menu as user root and I couldn't run the installer. Just a reminder to my future self.
Sali and thanks for checking this out so quickly!
> All of the above works as it worked before, thanks Devs for the excellent work!
Lovely to hear.
> Remark: All the IPv6 NAT-ting is just because I can, I could have solved it different with less NAT but where is the fun in that.
That's a good benchmark for regressions and happy to hear that nothing was visible on that front.
> Remark II: I had to re-enable console password protection, otherwise the installer - after importing the config - shows the console menu as user root and I couldn't run the installer. Just a reminder to my future self.
You can literally at any point in time go to option 8 and type "opnsense-installer" in the console.
Cheers,
Franco
@patient0 Were you on using there the new FW rules or haven't migrated yet?
Quote from: newsense on June 26, 2026, 11:10:23 PM@patient0 Were you on using there the new FW rules or haven't migrated yet?
I had migrated the firewall rules some time ago, the VM is running latest devel since OPNsense 25.
But I just realized I have not migrated the outbound NAT rules yet. So these two (one for IPv4 and one for IPv6) were and still are in the legacy 'Outbound' section.
Addition: I just tried exporting the two Outbound NAT rules in the migration assistant and it did throw an error:
Quote{"errorMessage":"fputcsv(): the $escape parameter must be provided as its default value will change","errorTrace":"#0 [internal function]: {closure:/usr/local/opnsense/www/api.php:27}(8192, 'fputcsv(): the ...', '/usr/local/opns...', 198)\n#1 /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php(198): fputcsv(Resource id #8, Array, ';')\n#2 /usr/local/opnsense/mvc/app/controllers/OPNsense/Firewall/Api/MigrationController.php(79): OPNsense\\Base\\ApiControllerBase->exportCsv(Array)\n#3 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php(166): OPNsense\\Firewall\\Api\\MigrationController->downloadOutboundAction()\n#4 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\\Mvc\\Dispatcher->dispatch(Object(OPNsense\\Mvc\\Request), Object(OPNsense\\Mvc\\Response), Object(OPNsense\\Mvc\\Session))\n#5 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\\Mvc\\Router->performRequest(Object(OPNsense\\Mvc\\Dispatcher))\n#6 /usr/local/opnsense/www/api.php(36): OPNsense\\Mvc\\Router->routeRequest('/api/firewall/m...', Array)\n#7 {main}"}
This patch should help:
# opnsense-patch https://github.com/opnsense/core/commit/5716c7184
Cheers,
Franco
@patient0 Thanks. And your setting in Outbound NAT was Automatic, Hybrid or Manual?
Quote from: newsense on June 27, 2026, 10:05:41 AM@patient0 Thanks. And your setting in Outbound NAT was Automatic, Hybrid or Manual?
@newsense: it is set to 'Hyprid'
Forgot: thanks franco for the remark about "... go to option 8 and type "opnsense-installer" in the console.", I didn't know that.
Quote from: franco on June 27, 2026, 09:58:02 AMThis patch should help:
# opnsense-patch https://github.com/opnsense/core/commit/5716c7184
That didn't resolve it for me, the patch did apply find though.
Syste: Firmware: Reporter (without the dmesg)
--- system information ---
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
FreeBSD 15.1-RELEASE volatile/26.7-n283588-da0c912a9737 SMP amd64
OPNsense 26.7.b_110 a1d16690c
Plugins os-bind-devel-1.34_2 os-crowdsec-devel-1.0.12 os-git-backup-devel-1.1_3 os-nextcloud-backup-devel-1.2 os-qemu-guest-agent-devel-1.3 os-sftp-backup-devel-1.1_2 os-tailscale-devel-1.4 os-tayga-devel-1.5 os-theme-cicada-devel-1.41_1 os-theme-rebellion-devel-1.9.4 os-theme-vicuna-devel-1.51 os-zerotier-devel-1.3.2_6
Time Sat, 27 Jun 2026 10:14:26 +0200
OpenSSL 3.5.7
Python 3.13.14
PHP 8.5.7
--- PHP Errors: ---
[27-Jun-2026 10:11:35 Europe/Berlin] ErrorException: fputcsv(): the $escape parameter must be provided as its default value will change in /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php:198
Stack trace:
#0 [internal function]: {closure:/usr/local/opnsense/www/api.php:27}(8192, 'fputcsv(): the ...', '/usr/local/opns...', 198)
#1 /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php(198): fputcsv(Resource id #9, Array, ';', '\\')
#2 /usr/local/opnsense/mvc/app/controllers/OPNsense/Firewall/Api/MigrationController.php(79): OPNsense\Base\ApiControllerBase->exportCsv(Array)
#3 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php(166): OPNsense\Firewall\Api\MigrationController->downloadOutboundAction()
#4 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\Mvc\Dispatcher->dispatch(Object(OPNsense\Mvc\Request), Object(OPNsense\Mvc\Response), Object(OPNsense\Mvc\Session))
#5 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\Mvc\Router->performRequest(Object(OPNsense\Mvc\Dispatcher))
#6 /usr/local/opnsense/www/api.php(36): OPNsense\Mvc\Router->routeRequest('/api/firewall/m...', Array)
#7 {main}
[27-Jun-2026 10:11:58 Europe/Berlin] PHP Warning: Undefined array key "network" in /usr/local/www/firewall_nat_out.php on line 471
Shall I open an GH issue for it?
Sure, open an issue, although it should fix it as it adds the parameter. I can check later.
Cheers,
Franco
Quote from: franco on June 27, 2026, 03:46:53 PMSure, open an issue, although it should fix it as it adds the parameter. I can check later.
I first try with a fresh installation and see if the same pops up.
@franco: Installing a fresh 26.7-BETA, appying the patch and importing the config shows the same error. 'opnsense-patch -l' shows the patch installed.
For testing I deleted the outbound rules and re-created a IPv6 NAT rule in the source NAT section. That works as it should but that leaves me with another question: the mode was set to 'Hybrid Source NAT rule generation' and the IPv6 NAT rule works fine. I then set the mode to 'Automatic Source NAT rule generation', my created rule disappears as expected but it seems the rule is still active, the IPv6 NAT-ting is still working. All the automatic rules are IPv4 only. Is that expected?
If the mode is automatic any manual rules should be skipped by this condition:
https://github.com/opnsense/core/blob/fbbc4ade70527a60be7b66790ae7cd6816f98aea/src/etc/inc/filter.inc#L196
If they aren't there is either something wrong with this condition or the new SNAT rules use a different pipeline for their rule register?
Quote from: Monviech (Cedrik) on June 28, 2026, 10:04:52 AMIf they aren't there is either something wrong with this condition or the new SNAT rules use a different pipeline for their rule register?
I set up a clean OPNsense 26.7.b based on the DVD ISO, all default. Ping to 9.9.9.9 work.
- set the NAT mode to Hybrid
- create a NAT Source rule with a wrong IPv4 NAT rule, that makes sure that I can check if the rule is applied or not
- - Interface WAN
- - Translate Source IP == LAN address
- - rest default
- Now again run a ping to 9.9.9.9 and doesn't work, as expected
- change NAT mode to Automatic, the manually created rule disappears
- ping 9.9.9.9 again, ping fails. I expected ping to work again
The same does behave as expected in the Outgoing NAT.
Since the legacy Outgoing NAT section is not available on the clean installation, I imported only the NAT from the other VM's configuration. That created the Outgoing NAT section again with two rules. I created then the above rule in the Outgoing section and delete the imported two rules (since useless on this VM).
Just to be sure: I check /tmp/rules.debug and the rule create in Source NAT is in, no matter if Hyprid or Automatic mode is set.
Does the rule show via
# pfctl -s nat
regardless of automatic or manual being selected after the apply?
Quote from: Monviech (Cedrik) on June 28, 2026, 11:22:16 AMegardless of automatic or manual being selected after the apply?
Yep, the output of `pfctl -s nat` is identical for both Automatic or Hybrid (not using Manual) (the "inet all -> (vtnet1:0)" line):
root@OPNsense:~ # pfctl -s nat
no nat proto carp all
nat on vtnet0 inet all -> (vtnet1:0) port 1024:65535
nat on vtnet0 inet from (vtnet1:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (lo0:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from 127.0.0.0/8 to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (vtnet1:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from (lo0:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from 127.0.0.0/8 to any -> (vtnet0:0) port 1024:65535
no rdr proto carp all
no rdr on vtnet1 proto tcp from any to (vtnet1) port = ssh
no rdr on vtnet1 proto tcp from any to (vtnet1) port = http
no rdr on vtnet1 proto tcp from any to (vtnet1) port = https
Can you open a ticket on github with this issue? We will look into it. Thanks for testing.
Quote from: Monviech (Cedrik) on June 28, 2026, 12:09:04 PMCan you open a ticket on github with this issue?
Yes, I'll do that later this evening.
I may be affected by this NAT issue as well, however my experience is a bit different ( or @patient0 didn't test for it)
My tests so far:
- test vm on 26.1 upgraded to 26.7.b, pretty much bare bones in terms of settings ( the only two rules there allow me to https/ssh from wan to manage it ). One Linux vm behind it. Traffic works as expected. Rules not migrated to New. NAT untouched.
- local hardware FW upgraded to 26.7.b. Rules not migrated. Traffic flows through the FW from vlans. NAT on hybrid. WireGuard server operational and allows me to connect to the FW mgmt but I don't have access to internet over WireGuard post upgrade - which sounds like a NAT issue
Interestingly IPsec works fine and I can remote into machines in various vlans.
- another FW and the first one who saw 15.1 couple weeks ago. Worked just fine with the kernel and when I installed base no traffic passed through. Rules not migrated and NAT hybrid.
- last FW, same HW as the first one in this post, upgraded to 26.7.b. Rules not migrated and NAT hybrid although now only the LAN exists. No traffic passing through from lan to wan however I can ZeroTier and manage it remotely and everything works apart from the lan-wan traffic issue.
I kept the one with the WireGuard issue on 26.7.b for now and I'll see what happens in the meantime.
When testing only the 15.1 kernel ( before 26.7.b was ready ) all these firewalls ran fine on it which is a good sign.
@patient0 sorry, I failed to count properly and this should fix it on top:
# opnsense-patch https://github.com/opnsense/core/commit/283ce7026a
Cheers,
Franco
Quote from: franco on June 28, 2026, 08:37:21 PM@patient0 sorry, I failed to count properly and this should fix it on top:
# opnsense-patch https://github.com/opnsense/core/commit/283ce7026a
I was _not_ able to reproduce it on a clean 26.7.b_110 where I imported the NAT rules only.
Thank you @franco, with this patch on top of the previous one, export was possible. Now I do get the following PHP error everytime I visit 'Firewall: NAT: Outbound' if there is at least one rule and mode set to Manual or Hybrid (Outbound is not visible of course in Automatic mode).
[29-Jun-2026 10:35:45 Europe/Berlin] PHP Warning: Undefined array key "network" in /usr/local/www/firewall_nat_out.php on line 471|But as mentioned, I was not able to isolate the issue on a clean installation, don't spend anymore time on it. If I can reproduce it on a clean installation, I'll be back.
@patient0 the SNAT automatic issue should be fixed via
# opnsense-patch https://github.com/opnsense/core/commit/aa2a54a5a8
Quote from: Monviech (Cedrik) on June 29, 2026, 10:56:51 AMhe SNAT automatic issue should be fixed via
# opnsense-patch https://github.com/opnsense/core/commit/aa2a54a5a8
Works like a charm now, excellent and thank you.
>>> don't spend anymore time on it. If I can reproduce it on a clean installation, I'll be back.
Well that's the kicker: not everyone will have migrated to the new rules before upgrading to 26.7 and not everyone will have Automatic in SNAT.
There's an issue there for sure and whether Cedrik's latest patch fixes everything or not is unclear as I'm not able to test for now.
What is likely though in the absence of the fix is that anyone not using automatic or doing fresh installs might be affected.
Thankfully 26.7 is still weeks away and by RC1 things should be clearer.
The biggest question mark for me is where the issue actually is... since it would appear that installing base 15.1 affects the core where the NAT code resides (?)
Quote from: newsense on June 29, 2026, 11:25:10 AMWell that's the kicker: not everyone will have migrated to the new rules before upgrading to 26.7 and not everyone will have Automatic in SNAT.
You are right, yes. But as long as I can't show steps on how to reproduce it, the devs won't be able to fix it.
I did read through your post but I didn't take the time to build a system with a WG tunnel. In your case it could be NAT or something else.
What outgoing NAT rules did you create? For what you wrote it seems that all necessary rules should have been automatic rule, no?
Quote from: patient0 on June 29, 2026, 11:36:26 AMWhat outgoing NAT rules did you create? For what you wrote it seems that all necessary rules should have been automatic rule, no?
The road warrior WG setup worked fine for years, only broke when moving to 26.7.b
Why exactly I had to move to hybrid I don't remember right now, once everything was working I didn't have to go back there for a long time.
@newsense
Can you show your NAT ruleset that has problems (26.7.b), and the NAT ruleset which does not have problems (pre 26.7.b, e.g. 26.1.10)?
# pfctl -s nat
# pfctl -s rules
If there is something unexpected also check rules.debug, it shows if rules have been skipped before being loaded for some reason. (DEBUG: lines)
# cat /tmp/rules.debug
Try do find if there is a difference, e.g. by piping both outputs in files and using a command like "diff -u file1 file2" or a diff capabable editor.
Hi Cedrik,
Got a small window on a FW and was able to get the the nat rules on .10 and _110 ( sent it to Franco as it was the fastest option available )
I also applied your patch and rebooted but it didn't seem to make a difference ( still couldn't connect to a machine in lan over a vpn )
Forgot about the debug files, I'll try and get it later today when I can get another window for a couple reboots
Something strange here. After the update for RC, after a restart and after I verified that everything went well (the basic), the firewall crashed, and give me a error on the nvme driver. It's been running good since 2022. So there is something broken with the update.
The update replaces FreeBSD 14.3 with FreeBSD 15.1. There might be some change in the NVMe subsystem that does not work quite well with your hardware.
So what is the exact error message, please?
Quote from: Patrick M. Hausen on July 08, 2026, 07:21:40 PMThe update replaces FreeBSD 14.3 with FreeBSD 15.1. There might be some change in the NVMe subsystem that does not work quite well with your hardware.
So what is the exact error message, please?
My hardware is a Hunsn box with a N5105 and 8GB Crucial. The NVme it's a cheap Patriot 128GB. It only says that it's reseting the NVME, and other times it bricks after the OPNsense menu. Just trying to instaling the current image right now :(
@Patrick M. Hausen Should I change to a normal ssd maybe ? I'm thinking when the final version get out I maybe still have problems with this nvme ?
You could just for curiosity boot a stock FreeBSD 15.1. I'd expect that to show the same behaviour.
Since even in the mid term the only way with releases is forward - if you have a spare device or the budget for another one, by all means give it a try.
Quote from: newsense on June 28, 2026, 12:44:31 PM- local hardware FW upgraded to 26.7.b. Rules not migrated. Traffic flows through the FW from vlans. NAT on hybrid. WireGuard server operational and allows me to connect to the FW mgmt but I don't have access to internet over WireGuard post upgrade - which sounds like a NAT issue
Interestingly IPsec works fine and I can remote into machines in various vlans.
This was fixed on RC1 with https://github.com/opnsense/core/commit/d35b281636be applied on top. Will be in RC2 this afternoon.
I will stay away from opnsense installs on NVMe's for now, as I've seen some issues with them on forums, particularly on freeBSD 15. It was just a pretty assemble on the box then a SSD for the same price. Also thank you Patrick for your attention.
But still, the Deciso DEC697 uses a 256GB NVMe. Any one knows the brand and model ?
For what it's worth, I upgraded from 26.1.11 to 26.7rc1 last night and had issues . I had to rollback. I just upgraded to rc2 and it worked straight away.
Quote from: Miguel Lopes on July 09, 2026, 04:27:21 PMI will stay away from opnsense installs on NVMe's for now, as I've seen some issues with them on forums, particularly on FreeBSD 15.
Quote from: Miguel Lopes on July 09, 2026, 04:51:03 PMBut still, the Deciso DEC697 uses a 256GB NVMe. Any one knows the brand and model ?
To be honest :
This kind of SSD =>
Quote from: Miguel Lopes on July 08, 2026, 07:31:02 PMThe NVme it's a cheap Patriot 128GB.
Can have all sorts of random cheapass NVMe Controller onboard so I am not really surprised it has issues all of a sudden!
Combine that with the fact that all those things are mainly Windows focused and you have yourself a nice possible issues party :)
Quote from: Miguel Lopes on July 09, 2026, 04:51:03 PMBut still, the Deciso DEC697 uses a 256GB NVMe. Any one knows the brand and model ?
You can use nvmecontrol or smartctl to get that information. I don't own a DEC697 but a DEC750 (1st gen) and at work we run some older 6XX unit with a SATA SSD. From that small sample I can guess that Deciso likes to use Transcend SSDs.
I also recommend and use these as boot devices for e.g. TrueNAS. They are not the fastest but have really high TBW (write endurance) numbers even for the smaller ones. Nice industrial grade stuff.
In my DEC750 there's a TS256GMTE710T (https://cdn.transcend-info.com/products/images/modelpic/1208/Transcend-MTE710T_MTE710T-I_202201-1.pdf).
Kind regards,
Patrick
Quote from: Patrick M. Hausen on July 09, 2026, 10:03:14 PMI can guess that Deciso likes to use Transcend SSDs.
I also recommend and use these as boot devices for e.g. TrueNAS. They are not the fastest but have really high TBW (write endurance) numbers even for the smaller ones. Nice industrial grade stuff.
In my DEC750 there's a TS256GMTE710T (https://cdn.transcend-info.com/products/images/modelpic/1208/Transcend-MTE710T_MTE710T-I_202201-1.pdf).
You reminded me of something from a while ago : https://forum.opnsense.org/index.php?topic=51263.0
And today this topic popped up : https://forum.opnsense.org/index.php?topic=52339.0
And there is also this older topic : https://forum.opnsense.org/index.php?topic=51528.0
Transcend in all of them indeed! Good call! :)