Messages

I use this
https://certifytheweb.com/

with powershell/ssh scripts etc to deploy to OPNSense, NAS's, nginx etc...all sorts.

Why dont you sanitise your config.xml of passwords/secrets etc, and upload it to chatgpt and describe your issue.

I'm not an advocate of AI, but it has actually resolved an issue for me in the past with asymmetric routing, and inevitably, it was caused by me....and identified by AI.

I have zero idea what the heck happened.

How old was the OPNsense installation ?

Sounds like ZFS issues that sometimes happen when the FreeBSD Bootloader is too old...

4 months...Device was new in December 25 and fresh installed with 25.7 then.

So that's 90 minutes I'm not getting back.

All I did was upgrade to 26.1.6 from .5 on a DEC750v2.
It rebooted and everything was working, but out of habit, after an upgrade I always run a health check.
It stalled on the 4 dots for ages, so I rebooted. Never came back.

I quickly put in a replacement 750v2, imported my config and we're back.

So I then put the original one on console, and it's weird.  I have a screenshot I'll try and link later but I saw something about "no pool to import". Leaving it for about 25 minutes, it does sort of begin to boot, but slow.
It hangs at "Initializing.........done." forever, then does a bit more 20 mins later.

Rather than waste time, I reinstalled 26.1.2 serial iso, upgraded to 26.1.6 and it's fine.

I have zero idea what the heck happened.

I may have bigger issues.

Whilst it was hung, I decided to reboot. Never came up again.

I've just swapped out the DEC750v2 with another and imported config and we're back.

Time to put a console port on this one..

Just upgraded to 26.1.6, but health check sticks.....

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.6 (amd64) at Thu Apr  9 14:21:30 BST 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.6 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.6 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-chrony 1.5_3
os-ddclient 1.30_2
os-theme-vicuna 1.51
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: ....

Can anyone else confirm?

The OPNSense docs state:

For legacy compatibility WAN interfaces set to type DHCP or interfaces with a Gateway Rules selection send reply packets to the corresponding gateway directly, also when the sender is on the same interface. This will break connectivity in some rare scenarios and can be disabled via Firewall->Settings->Advanced->Disable reply-to.

With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.

In my case, I have "Disable reply-to on WAN interface" selected, and my firewall rules have the reply-to explicitly set.
My secondary WAN is DHCP, and my primary is PPPoE, so this felt safest.

That works fine.

EDIT: I should add, I have migrated to the NEW rules....

I can tell you it works fine on 26.1.5 so you must have something misconfigured.

You havent really given us enough information.

Have you checked "Disable Reply-To on WAN rules" on Firewall/Settings/Advanced?
Have you set the "Reply-To" on the actual firewall rule? (advanced mode)

I am using PPPoE and get a /48 prefix from my ISP.

On 26.1.5, I have no issues and it works exactly as it should.

Identity association on the LAN and I get a /64 with an Assign prefix ID of 0

I do "Request Prefix Only" on the WAN interface, and nothing else. (Apart from Prefix delegation size of 48)

Doesn't help you, but I just wanted to say it works perfectly for me.....

Now that makes a lot more sense :)

In which case, I change my answer to I never get a /128 :)

Perhaps a poorly setup at the ZEN ISP end then....

For now, because I am a *clean log* man, I just request a PD only.  It works for me.

I do get a non temporary address yes, but it seems to come via SLAAC. (If I untick request prefix only)

So requesting a prefix only gives fe80::1%pppoe0/64 on the WAN, unticking Request Prefix only gives an address in my ND, e.g. 2a02:X0XX:XX01:XX6a::1/64, but then I get the entries in the log no address/prefix.

I think dhcp6c is trying to get the WAN IPv6 via DHCPv6 and thats why it throws no addresses.

The PD comes via DHCPv6, and that always works.

What is very interesting though, is even though I request prefix only, under Interfaces/Overview, I do still see the above ND address, but not on the dashboard interfaces widget, just fe80::1%pppoe0/64

Odd....

It's not a major issue for me as *both* options work, I was just interested in why the log was displaying those messages.

Keep up the good work Franco :)

Will be in 26.1.5.


Cheers,
Franco

Thanks Franco..... that's brilliant

Oooooh nice.

Would be great to see this in a 26.1.x release :)

I was literally looking at this right now.

I migrated most of my "Outbound" NAT rules to "Source NAT" but also noticed the missing "Static-port" option.

I saw a post by franco saying that Outbound NAT will become legacy, so thought I'd jump the gun, but the static-port option remains a bit of a mystery in Source NAT

If I "Request Prefix Only" the problem goes away......

So that is what I shall do, even though the ISP gives me a /64 for WAN.

This is ZEN UK.

EDIT: Looks like ZEN give the WAN IP via SLAAC, not IA_NA, and thats where the issue was.