pfSense

Another instance of this (v23.05):

#0 /usr/local/www/status_ipsec.php(345):array_key_first(NULL)
#1 /usr/local/www/status_ipsec.php(51): print _ipsec _body
#2 {main}
thrown @2023-08-07 18:04:25
• PHP ERROR: Type: 1, File: /usr/local/www/status _ipsec.php, Line: 345, Message:
Uncaught TypeError: array_key_first(: Argument #1 (Sarray) must be of type array,

Do we know what reproduces this error?

I began getting the same error by doing this:

I had an IPsec connection to a remote site already set up, but the remote site was getting a new ISP and would have both connections for a few days. So I created an IPsec tunnel to the new WAN interface (with two phase 2 entries) and made sure they worked before deleting the old one. At some point during this, I began getting this error every time I visit the dashboard on either the remote or local pfSense servers. Note that it affects both installations the same way.

Crash report begins.  Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 RELENG_2_7_0-n255866-686c8d3c1f0: Wed Jun 28 04:21:19 UTC 2023     root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/obj/amd64/LwYAddCr/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/sources/FreeBSD-src-REL

Crash report details:

PHP Errors:
[24-Sep-2023 02:15:25 Europe/Stockholm] PHP Fatal error:  Uncaught TypeError: array_key_first(): Argument #1 ($array) must be of type array, null given in /usr/local/www/status_ipsec.php:345
Stack trace:
#0 /usr/local/www/status_ipsec.php(345): array_key_first(NULL)
#1 /usr/local/www/status_ipsec.php(51): print_ipsec_body()
#2 {main}
  thrown in /usr/local/www/status_ipsec.php on line 345

No FreeBSD crash data found.

As you suspected; starting and stopping did solve the issue (and restarting it did not). At least on the local router, I rebooted pfSense on the remote site as I would not be able to turn the daemon back on again (already done that mistake once or twice).

Filip Bengtsson wrote in #note-5:

As you suspected; starting and stopping did solve the issue (and restarting it did not). At least on the local router, I rebooted pfSense on the remote site as I would not be able to turn the daemon back on again (already done that mistake once or twice).

OK, that tells me it may have something to do with some "stale" data in the running IPsec daemon from the old/removed tunnel. Hopefully that makes it easier to reproduce in the lab.

Thanks!

Tested patch on
2.7.0-RELEASE (amd64)
built on Wed Jun 28 03:53:34 UTC 2023
FreeBSD 14.0-CURRENT

Patch fixed this issue.

Tetsed on
23.05.1-RELEASE (amd64)
built on Wed Jun 28 03:57:27 UTC 2023
FreeBSD 14.0-CURRENT

The patch working as well