pfSense » pfSense Packages

Note: I suspect this is related to the fix for bug #10351 or related to the bug itself however it is marked resolved. If there is already a report for this I could not find it.

I have a PFSense 2.4.5-p1 installation with 23 IPSEC VTI Interfaces. I was having an issue where applying changes would freeze and not clear the ipsec_dirty file.

I inpected the php calls and traced back what the apply changes button actually calls. I created a short php script that I ran directly from shell to simulate clicking apply to hopefully find the culprit.

ini_set('error_reporting', E_ALL & ~E_NOTICE);
ini_set('display_errors', true);
require_once("functions.inc");
require_once("filter.inc");
require_once("shaper.inc");
require_once("ipsec.inc");
require_once("vpn.inc");
init_config_arr(array('ipsec', 'phase1'));
init_config_arr(array('ipsec', 'phase2'));
$a_phase1 = &$config['ipsec']['phase1'];
$a_phase2 = &$config['ipsec']['phase2'];
$ipsec_dynamic_hosts = vpn_ipsec_configure();
ipsec_reload_package_hook();
clear_subsystem_dirty('ipsec');
?>

Everything runs fine until ipsec_reload_package_hook where it freezes and dies completely.

Looking at /etc/inc/ipsec.inc starting at line 958 I saw that ipsec_reload_package_hook was iterating through a foreach loop starting at line 962.. I temporarily added

var_dump($package['name']);

on a new line at 963 and reran the php script I linked above. This showed that the command was freezing on FRR. I first uninstalled FRR and removed all the config lines from config.xml and reinstalled FRR to no avail, same issue. However completely removing FRR resolves the issue.

Also note: I could not find any actual error messages other than nginx times out before its able to complete.

Luckily I had not implemented FRR fully on that router and pulling it out had no real effect on my systems. However this needs looked at and I have gone as far with my time as I can justify with it.