Messages

1

23.7 Legacy Series / Re: Mullvad WG Tunnels Loop Detected

« on: November 11, 2023, 05:29:51 pm »

Hi, I have same problem - so I use monit to solve it.

1. You need to know internal id's for wireguard interfaces
just execute :

Code: [Select]

/usr/local/sbin/pluginctl -S wireguardyou will receive somethinh like this:

Code: [Select]

[
    {
        "description": "Wireguard wg0",
        "configd": {
            "start": [
                "wireguard start xxxx-xx-tt-yy-uuuuuuu"
            ],
            "restart": [
                "wireguard restart xxxx-xx-tt-yy-uuuuuuu"
            ],
            "stop": [
                "wireguard stop xxxx-xx-tt-yy-uuuuuuu"
            ]
        },
        "nocheck": true,
        "id": "xxxx-xx-tt-yy-uuuuuuu",
        "name": "wireguard",
        "status": "wireguard[xxxx-xx-tt-yy-uuuuuuu] is running."
    }
]
That

Code: [Select]

xxxx-xx-tt-yy-uuuuuuu is internal id.
2.  Configure monit
2.1 Go to Service-Monit-Settings
        tab "Service Tests Settings"
        add new ("+" button)
         name: TEST_NAME_1
         condition: content = "wg1: loop detected"
         action: Restart
  Save-Apply

2.2 tab "Service Settings"
       add new ("+" button)

        check "enabled"
        name: TEST_SERVICE_1
        type:   File
        path:  /var/log/system/latest.log
        Start: /bin/sh -c '/usr/local/sbin/pluginctl -s wireguard start xxxx-xx-tt-yy-uuuuuuu'
        Stop: /bin/sh -c '/usr/local/sbin/pluginctl -s wireguard stop xxxx-xx-tt-yy-uuuuuuu'
        TESTS:  TEST_NAME_1  (from step 2.1)
  Save-Apply

2.3 Enable monit on tab "General Settings" (if not enabled yet)
      Check monit Status page for it is up and running
   
3. If you have more than one wg interface  - repeat steps 2.1, 2.2 with appropriate id changes and wg interface name changes.

2

Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering

« on: March 08, 2020, 12:53:16 pm »

Hi mb, can you read and comment some topics in main 20.1 forum branch about unsuccessful upgrade to 20.1.2 with sensei plugin installed.

 https://forum.opnsense.org/index.php?topic=16164.0

3

20.1 Legacy Series / Re: syslog-ng crashed after 20.1.1 -> 20.1.2 upgrade

« on: March 08, 2020, 12:45:58 pm »

It seems to me, that real cause of system lock up was sensei, which depends on syslog-ng. When syslog-ng (on some reason) can't start -> sensei waiting for syslog-nd daemon -> syslog-ng still down -> sensei waiting -> and infinite loop.
So If I revert syslog-ng to previous version (3.24) will it help? And could it affect other packages which use syslog-ng?

4

20.1 Legacy Series / syslog-ng crashed after 20.1.1 -> 20.1.2 upgrade

« on: March 06, 2020, 06:11:45 pm »

Recently upgraded my opnsense 20.1.1 -> 20.1.2 and get completely unresponsive opnsense host. No ping, no ssh connection. Found in log:

Code: [Select]

2020-03-06T19:29:31 syslog-ng[69376]: syslog-ng starting up; version='3.25.1'
2020-03-06T19:29:29 kernel: -> pid: 88979 ppid: 1 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>
2020-03-06T19:29:29 kernel: [HBSD SEGVGUARD] [syslog-ng (88979)] Preventing execution due to repeated segfaults.
2020-03-06T19:29:29 kernel: [HBSD SEGVGUARD] [syslog-ng (88979)] Preventing execution due to repeated segfaults.
2020-03-06T19:29:28 kernel: -> pid: 73968 ppid: 88979 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>
2020-03-06T19:29:28 kernel: [HBSD SEGVGUARD] [syslog-ng (73968)] Suspending execution for 600 seconds after 5 crashes.
2020-03-06T19:29:28 kernel: pid 73968 (syslog-ng), uid 0: exited on signal 6 (core dumped)
2020-03-06T19:29:27 kernel: pid 20038 (syslog-ng), uid 0: exited on signal 6 (core dumped)
2020-03-06T19:29:26 kernel: pid 70069 (syslog-ng), uid 0: exited on signal 6 (core dumped)
2020-03-06T19:29:25 kernel: pid 55160 (syslog-ng), uid 0: exited on signal 6 (core dumped)
2020-03-06T19:29:23 kernel: pid 37176 (syslog-ng), uid 0: exited on signal 6 (core dumped)

Upgrade time is around 19:28-19:29.
After several soft restart (by power button) and after disabling sensei plugin - system work ok now.

5

Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering

« on: March 02, 2020, 08:06:54 pm »

Hi, freshly installed sensei 1.4 caused SEGVGUARD and stops all traffic.
It looks like that in dmesg.today log file:

Code: [Select]

[HBSD SEGVGUARD] [/usr/local/sensei//bin//eastpect (62199)] Suspension expired.
 -> pid: 62199 ppid: 13537 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>
...
[HBSD SEGVGUARD] [/usr/local/sensei//bin//eastpect (49329)] Suspension expired.
 -> pid: 49329 ppid: 44449 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>
...


When I tried to enable Generation of Support Data (Sensei -> Configuration -> Updates & Health; here turn on "Enable Generation of Support Data".) - nothing happened. After page refresh - "Enable Generation of Support Data" still disabled.
How also I can enable generation of support data to catch core dump file ?

6

20.1 Legacy Series / Re: VPN: OpenVPN: Log File Loading...

« on: February 29, 2020, 07:04:28 pm »

Confirm - patch e3774dd working.
All logs ok now.

7

Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering

« on: February 01, 2020, 04:08:00 pm »

I also get errors like this:

Code: [Select]

PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20170718/mongodb.so (Shared object "libcrypto.so.11" not found, required by "mongodb.so"), /usr/local/lib/php/20170718/mongodb.so.so (Cannot open "/usr/local/lib/php/20170718/mongodb.so.so")) in Unknown on line 0Even after complete uninstall of sensei plugin.
OPNsense 19.7.10_1-amd64