Boot hangs after upgrade and other issues

Started by reservado, July 15, 2026, 05:36:37 PM

Previous topic - Next topic
July 15, 2026, 05:36:37 PM Last Edit: July 15, 2026, 05:41:00 PM by reservado
I have attempted to upgrade to 26.7 approx 7 times and had to roll back each time due to issues.

I upgrade from the web UI. The system reboots as expected, then reboots again, which I assume is normal. After the second reboot the system hangs. Nothing notable appears on the console. I have to hard reboot to get back into the web UI.

After getting back in, I see these error messages even though none of my block rules have a gateway or reply-to set:



2026-07-15T14:45:25
Error
firewall
There were error(s) loading the rules: /tmp/rules.debug:330: route-to, reply-to and dup-to are not supported on block rules - The line in question reads [330]: block in log quick on pppoe0 reply-to ( pppoe0 redacted IP ) inet from {any} to {any} label "4b28d971-1a4d-46d1-ae84-900122150176" # block all IN pppoe
2026-07-15T14:45:25
Error
firewall
/usr/local/etc/rc.filter_configure: The command </sbin/pfctl -f '/tmp/rules.debug.old'> returned exit code 1 and the output was "/tmp/rules.debug.old:330: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:330: skipping rule due to errors /tmp/rules.debug.old:330: rule expands to no valid combination /tmp/rules.debug.old:336: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:336: skipping rule due to errors /tmp/rules.debug.old:336: rule expands to no valid combination /tmp/rules.debug.old:340: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:340: skipping rule due to errors /tmp/rules.debug.old:340: rule expands to no valid combination /tmp/rules.debug.old:345: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:345: skipping rule due to errors /tmp/rules.debug.old:345: rule expands to no valid combination /tmp/rules.debug.old:395: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:395: skipping rule due to errors /tmp/rules.debug.old:395: rule expands to no valid combination pfctl: Syntax error in config file: pf rules not loaded"



What I have tried so far:

  • Temporarily changing the affected rules and saving. - Same result.
  • Deleting and recreating the affected rules from scratch. - Same result.
  • Importing my firewall rules after the upgrade. - Same result.
  • Restoring my full backup config after the upgrade. - Same result.
  • Checking the "Disable reply-to on WAN rules" option. - This removes the error but other problems remain (see below).

Other problems after the upgrade:

  • None of my firewall rule descriptions or labels show up in the live log.
  • Firewall rules do not seem to work correctly. Traffic is blocked where it should be allowed.
  • I cannot get my WireGuard VPN to reconnect. My VPN routes all my internet traffic.

About my setup:

I use PPPoE for my WAN connection. I run a setup where all traffic is blocked in and out of pppoe because I want my VPN to carry everything, including traffic from OPNsense itself. This means I have to manually intervene if my vpn drops which it does from time to time or when I reboot but this isn't and issue as I work from home and quite like to keep things as secure as possible.

This means whenever I reboot I have to temporarily disable my WireGuard gateway for a few seconds. This allows my "allow WG connect out" rule to reach the external VPN server via pppoe. That rule is a floating rule on the opt6,wan interface group, direction out, UDP port [redacted] to my VPN server at [redacted IP], using the PPPOE gateway. This is a bit clunky but has worked perfectly until now.

Here is the rule:



bb60401b-a408-43e3-9ed2-d201ff5a628c  1  keep  6  pass  1  0  opt6,wan  out  inet  UDP  (self)  0  [redacted]  [redacted IP]  0  [redacted]  PPPOE_PPPOE  0  1  0  0  0  ALLOW WG CONNECT FLOAT


Some of my block rules use an interface group (opt6,wan) instead of a single interface. The affected block rules shown in the error also use this group.

I am running this on a protectli vault pro vp4630.

All rules work perfectly on 26.1.11_10 and are fine again once I revert to my previous snapshot.

Please help, I am becoming incredibly frustrated with this.

Kind regards,
Franklin

Are you sure the upgrade went through, or is it not installing the 26.7 core package? Because there were supposed to be two patches in it fixing the behaviour you see.  Unfortunately it's an upstream restriction that causes more harm than good.


Cheers,
Franco

July 15, 2026, 06:01:49 PM #2 Last Edit: July 15, 2026, 06:05:39 PM by reservado
Thank you for replying so swiftly Franco. :)

To be honest, no, I am not sure if the upgrade completed properly and can only presume. In my frazzled state I neglected to check if the dashboard actually showed 26.7 after the hard reboot.

The upgrade certainly downloads and the web UI console output seems fine during the process. I get the message that it will reboot, it reboots, I get the system beep once the Ethernet ports light up, then a few moments later they go off again, then the port lights come back on and I get another beep. After that the VGA console output seems just the same as always and without errors, but then it just hangs indefinitely and the web ui never comes up. I leave it for 10 minutes just in case and then have to hard reboot and face the multiple issues I previously described.

The Protectli vault is running coreboot. Perhaps this is causing issues with such a major upgrade?

How can I check if the 26.7 core package actually installed correctly? Is there a way to force the core package to reinstall from the console, or to verify the patches you mentioned are in place? I am happy to try the upgrade again and run any commands you suggest before I hard reboot.

I am tempted to create a bootable OPNsense ISO, clean install, and restore my config, but I am very worried about ending up with the same issues and not being able to revert to a previous ZFS snapshot. I suppose I could still create another USB with a previous version of OPNsense and restore my snapshot to that if all else failed, but I really do not want to have to go through all of that.

I am pretty tired now so I will pick this up tomorrow with any suggestions you may have.

Kind regards,
Franklin

After upgrade there should be an upgrade log available in the firmware screen and that holds all the information.

From the console it can be gathered via: # opnsense-update -gG

OK, I'll try again first thing tomorrow, vielen dank. :)

Kind regards,
Franklin

Today at 02:23:33 AM #5 Last Edit: Today at 02:35:37 AM by Melroy vd Berg
Yup I can confirm.. Same issue here as well:

QuoteThere were error(s) loading the rules: /tmp/rules.debug:444: route-to, reply-to and dup-to are not supported on block rules - The line in question reads [444]: block in quick on pppoe0 reply-to ( pppoe0 212.121.121.44 ) inet from $Banned_countries to {any} label "7fbfe385-70e6-497a-

/usr/local/etc/rc.newwanipv6: The command </sbin/pfctl -f '/tmp/rules.debug.old'> returned exit code 1 and the output was "/tmp/rules.debug.old:444: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:444: skipping rule due to errors /tmp/rules.debug.old:444: rule expands to no valid combination /tmp/rules.debug.old:445: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:445: skipping rule due to errors /tmp/rules.debug.old:445: rule expands to no valid combination /tmp/rules.debug.old:446: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:446: skipping rule due to errors /tmp/rules.debug.old:446: rule expands to no valid combination /tmp/rules.debug.old:447: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:447: skipping rule due to errors /tmp/rules.debug.old:447: rule expands to no valid combination /tmp/rules.debug.old:448: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:448: skipping rule due to errors /tmp/rules.debug.old:448: rule expands to no valid combination /tmp/rules.debug.old:449: route-to, reply-to and dup-to are not supported on block rules /tmp/rules.debug.old:449: skipping rule due to errors /tmp/rules.debug.old:449: rule expands to no valid combination /tmp/

Honestly the whole upgrade went really bad here to 26.7. I got issues like "failed waiting for configd" in a loop, it was stuck here. After that Opnsense asked me to run pkg bootstrap -f. It most likely didn't fully installed 26.7 at all. Restoring snapshot also worked here for now.

I think I will just reinstall from scratch now. How can I plugin the installer USB at the same time as the second USB (with my backup config), while the DEC3800 only has 1 USB port on the front here.   
Hardware: DEC3852
Version: OPNsense v25.7.5

I fixed this error editing three firewall rules in my case, while rc1,2 qas released.

In advanced, uncheck:
[ ] Disable reply-to

Quote from: Melroy vd Berg on Today at 02:23:33 AMHow can I plugin the installer USB at the same time as the second USB (with my backup config), while the DEC3800 only has 1 USB port on the front here.
I asked something like this in the past because a single USB port seems like a limitation, but IIRC the consensus was that in this case you should restore the config from the OPNsense GUI after installation.
N5105 | 8/250GB | 4xi226-V | Community

Can you try renaming $Banned_countries to $BannedCountries?

Are there any other aliases with special characters? Can you give examples before renaming those too?

Don't expect anything special to happen with a fresh install. As long as you're bringing the old config file the issue is still there.

I would simply retry upgrading after taking care of that and any similarly named aliases.

If there's nothing else -and I don't think it is- you'll be up and running on 26.7 shortly. And once Franco fixes the bug you can get back to the old naming convention if needed (with a snapshot testing the fix will be easy enough)