Messages

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 made one change and things are working again. Specifically I found a suggestion to add a firewall rule to WAN to allow incoming ICMP. I didn't have this before, but adding it now seems to have fixed things. :-)

This thread can be closed - 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.

I only reverted OPNSense itself using opnsense-revert -r 22.1.4 opnsense . I did not revert Python or the kernel.

Running audit/health check shows the following:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.1.4_1 (amd64/OpenSSL) at Fri Apr  8 13:57:23 CDT 2022
>>> Check installed kernel version
Version 22.1.5 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.1.5 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-dyndns 1.27_3
os-theme-cicada 1.29
os-theme-tukan 1.25
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 65 dependencies to check.
Checking packages: .........................
opnsense-22.1.4_1 repository mismatch: unknown-repository
opnsense-22.1.4_1 version mismatch, expected 22.1.5
Checking packages: .......................................... done
***DONE***

Update: Reverted to 22.1.4 and the errors went away. Please advise.

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>.

Thanks to help from the support staff I was able to track this problem down. Had to check the 'Disable hardware TCP segmentation offload' box in the interface settings. Everything running fine now.  :)

@sy, I take it all back, you were correct! I stopped eastpect through ssh and the GUI returned. I could then access the bug report. Thank you!

Thanks, I'll try that when I pluck up the courage to try again. However 'top' showed that eastpect was only using max 6.5% of CPU. The entire system was running at only 2.9% CPU so I don't think it was anything being processor bound that was causing the problem with the GUI.

I could see packets being filtered in the logs, and the Elasticsearch database was being updated, it was just the OPNSense GUI that was completely borked.

Unfortunately I don't know how to submit a Sensei bug report as the Sensei GUI in OPNSense is inaccessible. All you get on any of the Sensei tabs is the 'Initializing...' bar. No access to configuration page. It pretty much locks up the rest of OPNSense as well with pages taking nearly a minute to load.

I tried removing the Sensei plug in through Firmware/Plugins (no access to uninstaller). Deleted the /usr/local/sensei folder and tried again. Same result unfortunately, OPNSense grinds to a crawl and the Sensei GUI is not accessible. For now I've deleted it all again so OPNSense can run. Deleting the plug-in restores OPNsense and the GUi to normal operation.

System is Qotom 4 Q355G4 Intel i5 running at 2.2GHz so should have the power to run Sensei.

How would you like me to submit the bug report?

   

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)