Project

General

Profile

Actions

Regression #14525

closed

PHP error in ``status_ipsec.php`` after removing active IPsec tunnel configuration

Added by Christopher Cope over 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

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
[29-Jun-2023 09:53:43 US/Central] 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

A customer hit this on 23.05. I will attempt to reproduce it, but we should add a check for this situation either way.


Files

error.jpg (92 KB) error.jpg aleksei prokofiev, 10/11/2023 09:14 AM
Actions #1

Updated by Craig Coonrad about 1 year ago

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,
Actions #2

Updated by Kris Phillips about 1 year ago

Do we know what reproduces this error?

Actions #3

Updated by Filip Bengtsson about 1 year ago

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.
Actions #4

Updated by Jim Pingle about 1 year ago

  • Subject changed from PHP error in status_ipsec.php to PHP error in ``status_ipsec.php``
  • Assignee changed from Christopher Cope to Jim Pingle
  • Target version set to 2.8.0
  • Plus Target Version set to 23.09
  • Tracker changed from Bug to Regression

Did the error go away if you stopped/started (not restart) the IPsec daemon?

For it to hit the error there, it would have to have a P1 in the connection state data, but no P2 SA, though I can't provoke that here yet. We can certainly at least try to avoid that error, though, but it would be nice to have an easy way to replicate it.

I'll try to re-create your scenario in a lab here to see what happens.

Actions #5

Updated by Filip Bengtsson about 1 year ago

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

Actions #6

Updated by Jim Pingle about 1 year ago

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!

Actions #7

Updated by Jim Pingle about 1 year ago

  • Status changed from New to In Progress

While I could not reproduce it yet, I checked in what should be a fix for it. I tested the fix on several lab systems including one with ~20 IPsec tunnels of varying types and connection states and it was solid there.

Actions #8

Updated by Jim Pingle about 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #9

Updated by Jim Pingle about 1 year ago

  • Subject changed from PHP error in ``status_ipsec.php`` to PHP error in ``status_ipsec.php`` after removing active IPsec tunnel configuration
Actions #10

Updated by aleksei prokofiev about 1 year ago

I can reproduce this error with follow
1. S2S Ipsec
2. With working state, I delete P2 on one side and got this error in status page
3. Restart is not solve it, only stop/start service

Actions #11

Updated by aleksei prokofiev about 1 year ago

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.

Actions #12

Updated by aleksei prokofiev about 1 year ago

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

Actions #13

Updated by Jim Pingle about 1 year ago

  • Status changed from Feedback to Resolved
Actions #14

Updated by Jim Pingle 11 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF