Messages

Thank you geri441 for letting us know that flushing the state tables clears this issue (until the next reboot). I ran into a similar issue when upgrading to 26.1, which I posted about here, and I've been running 25.7 ever since. Today I upgraded all the way to 26.7 and with your clue I won't have to roll back again.

How about an option to enable automatic snapshots without cleanups for those that accept the responsibility to delete old snapshots themselves?

I didn't have any errors, but it looked to me like the output of the fetch commands was line buffered, and therefore didn't appear until each fetch completed. I upgraded from the console menu. The web GUI was functional and I could see from the traffic graphs that a download was taking place.

Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ................................................................................. done
Fetching kernel-26.1.11-amd64.txz: ............................ done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-26.1.11-amd64.txz... done

- I like using a private range for IPv6 and NAT'ing, because it means IPv4 works exactly the same as IPv6 which makes it simple to manage.

At the risk of going off topic, I have to say that after many years of running multi-WAN (most with pfSense but more recently with OPNsense) I completely agree with you. Using NAT to keep your LAN prefix from changing makes failover smoother, especially with ISPs that change your prefixes whenever they feel like it.

Note, however, that if you use a private range, your LAN clients will tend to prefer IPv4 connections (likely due to the use of getaddrinfo(3) and its compliance with RFC 3484). What I've ended up doing is making up my own public IPv6 prefix for use on my LAN so my clients prefer IPv6.

We're just breakin' all the (IPv6) rules!

This might not be your problem, but I've found that some providers, particularly wireless providers, sometimes drop the abnormally small ping packets sent by dpinger. For all of my gateways I set "Data Length" to 56 (you'll need to switch on "Advanced Mode" to see this option).

I've been using Multi-WAN for failover via Policy Routing and Gateway Groups on 25.7.X. After upgrading directly from 25.7.11 to 26.1.1, the system log fills with "arpresolve: can't allocate llinfo for %d.%d.%d.%d" errors for the primary (lowest tier) WAN interface. Multi-WAN still appears to work, but the messages continue to be generated. This is before attempting to migrate to the new Rules interface. Rebooting does not help. I've rolled back to a 25.7.11 snapshot and all works as before.

So something must have changed in 26.1. Suggestions?

Thanks!

Beszel now supports FreeBSD out of the box with an installation script:

Beszel is awesome but the script doesn't quite work correctly on OPNsense. It creates a new user beszel that OPNsense removes at the next reboot. The way I'm working around this for now is by editing /usr/local/etc/rc.d/beszel-agent and changing the value for beszel_agent_user from beszel to daemon.

This issue has been reported and is on the roadmap.

[System: Gateways: Configuration]

I've had problems with a 5G provider dropping pings with smaller than usual payload sizes, like those sent by dpinger by default. One thing to try is setting your ping payload size to 56 bytes so it looks like a normal ping.

To change this setting in OPNsense go to System: Gateways: Configuration, edit your gateway, switch on "advanced mode", and change Data Length to 56.

Creating your own scripts should no longer be necessary. The Beszel Hub Web GUI can now generate a FreeBSD command line you can copy which will take care of everything for you, including configuring automatic updates.

Console option 1 and 2 have always authoritatively changed defaults because they are tailored for initial setups and recovery purposes.

Thank you, this is good to know. I will need to change the LAN IPs of my system when I move it from test to production and wasn't sure whether the console or Web UI was the better choice.

I am guessing I will need to add additional rules for WebGUI and SSH access as well?

There are automatically generated rules for SSH and HTTPS that should take care of these, I think.

For anyone wondering, console option 2 did still work on an already installed system and updated the range in Dnsmasq.

I ran Option 2 twice (to change the LAN addresses as a test and then change them back) and both of my Dnsmasq ranges were deleted.

It looks to me like the process causing these regular CPU bumps is "configd.py console".

I found this issue in GitHub: wizard: auto configure DHCP/DNS registration query forwarding #8969. So it's a known limitation that the Wizard does not connect Dnsmasq and Unbound for you yet.

I'm also a pfSense user who's preparing to migrate (so I probably shouldn't be attempting to answer since I haven't migrated yet), but I think as of 25.7 you need to ignore any existing tutorials and look at the Configuration examples section of the Dnsmasq section of the documentation.

Basically you configure Dnsmasq to listen for DNS queries on an alternate port, and then configure Unbound to forward queries for your local domain to Dnsmasq. I'm not sure the Wizard sets up this forwarding for you, though, but it probably should.

The nice part of this scheme is that Unbound doesn't have to be restarted every time one of your DHCP mappings changes.