Messages

Same here, after an upgrade zenarmor stuck, so i reinstall the whole opnsense, restored from backup ( deleted the zenarmor configuration parts ) then install the fresh zenarmor. I try to setup but even the initial setup stuck with the Network Error
Please check your network connection message. It seems something is broken with this.

Hi!

After upgraded to 22.1.10 none of the Zenarmor (ex Sensei) menu works.
Got this error:
Fatal error: Uncaught Error: Class 'Phalcon\Config' not found in /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php:113 Stack trace: #0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(364): OPNsense\Sensei\Sensei->init() #1 /usr/local/opnsense/mvc/app/controllers/OPNsense/Sensei/IndexController.php(21): OPNsense\Base\BaseModel->__construct() #2 [internal function]: OPNsense\Sensei\IndexController->indexAction() #3 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->callActionMethod(Object(OPNsense\Sensei\IndexController), 'indexAction', Array) #4 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->dispatch() #5 /usr/local/opnsense/www/index.php(72): Phalcon\Mvc\Application->handle('/ui/sensei/inde...') #6 {main} thrown in /usr/local/opnsense/mvc/app/models/OPNsense/Sensei/Sensei.php on line 113

Update: Since we are a paid user, i opened a support ticket, so far the devs dont know whats the problem either.
I seems the issue is introduces in 1.8.9, ,its working with 1.8.8 and before but opnsense jumped 1.8.6 to 1.8.9 so who knows.
Devs suggest that we should try 1.10.x since its released and they fixed some issues what might be related to this.
So i think we should wait till freebsd/opnsense will have the 1.10.x version of zerotier-one package.

Too bad that the zerotier discussion board is not really active, i dont think any of the developers would notice any of my posts.
It seems multiple people reporting the same behavior even with windows and linux alike not just freebsd.
The last working version was the 1.8.8, the 1.8.9 brings many issues. Im reverting every of my zerotier client to 1.8.6, even in my workstation linux laptop. This seems resolve all the issues. I strongly recommended to downgrade on every zerotier member to <1.8.9.

You can lock the zerotier package from the GUI as well.


Cheers,
Franco

Ahh yes indeed :)

I second that

Note: you can lock the zerotier package to prevent future upgrade:
pkg lock zerotier

So the opnsense itself can be update normally but the zerotier package stays at 1.8.6.
Tested, no sideeffects, should be safe.

Yes, netflow was the issue. I had to disable (purge the database) then re-enable the service. Its solved now.
Thanks! :)

Something is seriously wrong with zerotier. Even in my linux laptop the 1.8.9 or the 1.8.10 eats my cpu after a while and generate a lot of bogus traffic, even when im not using any static routes. I revert back to 1.8.6 on my arch linux and problem solved.

I strongly suggest that opnsense devs should revert the zerotier package to 1.8.6 in the production series too. This probably causing a massive problem on many users firewall.

Thanks Man!

You saved my life! I try to figure out whats wrong since days.

Regards, Peter

Since the 22.1.6 zerotier eats 99% of one cpu, it was perfect in 22.1.6 but went wrong in 22.1.7.

In the latest update (22.1.8) the sqlite3 is also updated to the 3.38.2.
This eats one cpu fully.

The gateway log is full of this now:
(the gw is fine, i do a ping test all the time from my control machine, not a single packet loss or higher latency ping)
This was not happened with 20.7.6
Affected multiple opnsense in my company. The affected systems are: vmware VM with vmxnet, pcengine APU box with igb
Attached the screenshot, everything was unchecked except ipv6, now i checked the sticky connections and the disable the state killing feautre. With the disabled gateway monitoring and this two checked options the firewall is working fine now. The problematic system's where we have multiple gw with load balancing. These are broken.

2020-11-23T14:25:02   dpinger[8525]   GW_WAN <redacted>: Clear latency 304us stddev 71us loss 5%   
2020-11-23T14:23:53   dpinger[57575]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 1 RTT: 271ms RTTd: 53ms Loss: 22%)   
2020-11-23T14:23:53   dpinger[8525]   GW_WAN <redacted>: Alarm latency 271us stddev 53us loss 22%   
2020-11-23T14:22:18   dpinger[29789]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 0 RTT: 2538ms RTTd: 16750ms Loss: 5%)   
2020-11-23T14:22:18   dpinger[8525]   GW_WAN <redacted>: Clear latency 2538us stddev 16750us loss 5%   
2020-11-23T14:21:21   dpinger[20904]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 1 RTT: 288ms RTTd: 53ms Loss: 22%)   
2020-11-23T14:21:21   dpinger[8525]   GW_WAN <redacted>: Alarm latency 288us stddev 53us loss 22%   
2020-11-05T17:14:27   dpinger[73947]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 0 RTT: 343ms RTTd: 274ms Loss: 5%)   
2020-11-05T17:14:27   dpinger[8525]   

In the meantime i did reinstall a simple 20.7 and skip any further update. Reenabled gw monitoring and revert all settings back to what was like. No issues. Upgraded to 20.7.7_1, issues again. So something is wrong either with the dpinger or the ethernet kernel module. Hope i can help.

I had this one on a Fritzbox of provider too, in the end I let them replace the unit. Better ping an outside address?

Hi!

No ping latency problem from any computer behind the firewall. I setup a container for monitoring the gateway and the 1.1.1.1 for example. Ping values around 10-30ms all the time, no loss or higher values. Only the opnsense firewall sees high latency values.

The gateway log is full of this now:
(the gw is fine, i do a ping test all the time from my control machine, not a single packet loss or higher latency ping)
This was not happened with 20.7.6
Affected multiple opnsense in my company. The affected systems are: vmware VM with vmxnet, pcengine APU box with igb
Attached the screenshot, everything was unchecked except ipv6, now i checked the sticky connections and the disable the state killing feautre. With the disabled gateway monitoring and this two checked options the firewall is working fine now. The problematic system's where we have multiple gw with load balancing. These are broken.

2020-11-23T14:25:02   dpinger[8525]   GW_WAN <redacted>: Clear latency 304us stddev 71us loss 5%   
2020-11-23T14:23:53   dpinger[57575]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 1 RTT: 271ms RTTd: 53ms Loss: 22%)   
2020-11-23T14:23:53   dpinger[8525]   GW_WAN <redacted>: Alarm latency 271us stddev 53us loss 22%   
2020-11-23T14:22:18   dpinger[29789]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 0 RTT: 2538ms RTTd: 16750ms Loss: 5%)   
2020-11-23T14:22:18   dpinger[8525]   GW_WAN <redacted>: Clear latency 2538us stddev 16750us loss 5%   
2020-11-23T14:21:21   dpinger[20904]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 1 RTT: 288ms RTTd: 53ms Loss: 22%)   
2020-11-23T14:21:21   dpinger[8525]   GW_WAN <redacted>: Alarm latency 288us stddev 53us loss 22%   
2020-11-05T17:14:27   dpinger[73947]   GATEWAY ALARM: GW_WAN (Addr: <redacted> Alarm: 0 RTT: 343ms RTTd: 274ms Loss: 5%)   
2020-11-05T17:14:27   dpinger[8525]   

In the meantime i did reinstall a simple 20.7 and skip any further update. Reenabled gw monitoring and revert all settings back to what was like. No issues. Upgraded to 20.7.7_1, issues again. So something is wrong either with the dpinger or the ethernet kernel module. Hope i can help.

Hi!

After the upgrade i experienced a strange behaviour. The firewall randomly kills every tcp connection in every 15-20 minutes. It is a kill not connection reset, so if im on an ssh term its just frozen not got broken pipe.
Its a single gateway machine but if i disabled the state killing on gateway failure and enabled the sticky connection that help. The gateway is stable, i dint notice any gateway failure but still opnsense sometimes declared its down.
Even if i disable gateway monitoring! So this feature is pretty much garbage currently. No matter if you use or not, not reliable. Therefore every firewall with multiple gateway and load balancing is acting really weird now. I had to disable the load balancin completely.
There is a way to rollback the whole system without reinstalling? 20.7.6 was fine.

Thx!

Affected our firewalls too, from 12 of 10. So its pretty much affect almost everyone, not just a few people.
Disabled unbound and using dnsmasq solve the issue.