Topics

Updated to 26.7. All working fine, thank you.

However I'm confused by the Migration Assistant. This is what I see in the menu:



(Posted an image here but it doesn't show up for some reason, here's the url: https://shottr.cc/s/1B0N/SCR-20260717-fmu.png )

There is only a 'Rules' entry, not a 'Rules(new)'. Does this mean that I already did the migration (which I might have done in a prior release, but forgotten)? If I have done it why is the Migration Assistant still saying I haven't? However, if I haven't run the migration, then how do I do it without the 'Rules (new)' option?

I updated to 24.7.7 this morning and since then the graphs under Reporting/Health do not update. They are frozen at the time I performed the update, 09:43 this morning. A reboot does not fix this.

All other graphs under 'Reporting' are fine, it's just the 'Health' ones that are broken.

Grateful for any suggestions on how to get this running again. I'm tracking this data as I've been getting a lot of loss from Spectrum cable, so I really don't want to lose the historical data.

I'd appreciate help with what I hope is a simple question.

I'm getting a Tesla Powerwall installed which has a fixed IP address of 192.168.91.1. This cannot be changed. It will be connected to my Wi-Fi for connection to the Tesla cloud but I'd also like to be able to access this from within my LAN which is at 192.168.0.1/23.

Can I set up a static route and give the 192.168.91.1 address an alias IP within my normal LAN range?

I know I could do this on a computer using, for example, something like :

Code Select Expand

sudo ip route add 192.168.91.1 via 192.168.0.100

How do I do the same with OPNSense so that any computer on the LAN can access it?

No panic as I've solved the problem but thought it might be worth reporting. Just upgraded my system to 24.1 and it froze during reboot. Connected a monitor and nothing, wouldn't boot at all. After an hour of trouble shooting I finally, in desperation, switched the Bios to boot in Legacy mode rather than UEFI and, wonder of wonders, with sighs of relief, it came up!

Does the 24.1 upgrade disable UEFI booting in some way? I'm now running Legacy - which is fine, but it was all very odd that I had to change it.

Hi, the release notes for 23.7 say "The new OpenVPN instances pages and API create an independent set of instances more closely following the upstream documentation of OpenVPN.  Legacy client/server settings cannot be managed from the API and are not migrated, but will continue to work independently."

The text is ambiguous to me, it says that legacy clients (which I take to read as my OpenVPN clients set up in 23.1.11) will not be migrated but then it goes on to say they they will continue to work. How will they continue to work if not migrated and, if they do, how would they be managed?

In either case, what is the recommended way to transfer existing OpenVPN clients to 23.7? Do we have to delete the existing client definitions before upgrading and then recreate them in the new system?

Thank you.

I think this problem just started today when I upgraded to 23.1, but it's possible it happened recently with a prior version. Symptoms:

1. IPv6 works fine from router to ISP. ISP assigns an IPv6 address (starting 2605 - this is Spectrum) and I can ping6 from the OPNSense shell successfully.

2. Computers on LAN have IPv6 addresses correctly assigned (starting 2603 - not link local addresses). They show up as leases in the DHCPv6 leases list on OPNSense and display as 'active'.

3. The problem is that none of the LAN devices can access the outside world on IPv6.

EDIT: The outgoing IPv6 ping6 data shows in the firewall logs, but nothing seems to come back


AFAIK I have changed nothing and I can't see where the problem lies. What is blocking the incoming ipV6 data? What do you need from me to help me fix the problem?

Help much appreciated - thank you.

After updating yesterday I get the following error logged from configd.py. If I reboot I get a similar error every time. Can you suggest where I should look for the problem?

Code Select Expand

[e13f0d6f-b71c-4fbd-9ef9-9231da63008a] Script action failed with Command '/usr/local/opnsense/scripts/filter/pftablecount.py ''' died with <Signals.SIGBUS: 10>. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 478, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.8/subprocess.py", line 364, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/opnsense/scripts/filter/pftablecount.py ''' died with <Signals.SIGBUS: 10>.

New install of Sensei on OPNSense 21.7.3_3 using external ElasticSearch database. Install looked to go OK, worked successfully through the wizard, but now the Sensei GUI page is stuck on 'Initializing...' It's been like that for over an hour. Tried rebooting OPNSense but Sensei still says initializing.

Is it normal to take so long to initialize? How do I find out what the problem is?

(It has also killed the responsiveness of the OPNSense GUI. Now taking many 10's of seconds to open a page)