Hello, when deleting the state manually, confirmed not to ask anymore, now the connection is not deleted at all, does anyone know how to return the confirmation window for deletion? The reboot did not help.

Crash report begins.  Anonymous machine information:

amd64
16.0-CURRENT
FreeBSD 16.0-CURRENT #7 plus-RELENG_25_11_1-n256519-3d5e07ee0abe: Mon Jan 19 17:34:47 UTC 2026     root@pfsense-build-release-amd64-1.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-Plus-snapshots-25_11_1-main/obj/amd64/8uazGBdh/var/jenkins/workspace/p

Crash report details:

PHP Errors:
[26-Mar-2026 17:29:22 America/New_York] PHP Fatal error:  Uncaught ValueError: date_create_from_format(): Argument #2 ($datetime) must not contain any null bytes in /usr/local/www/widgets/widgets/suricata_alerts.widget.php:188
Stack trace:
#0 /usr/local/www/widgets/widgets/suricata_alerts.widget.php(188): date_create_from_format()
#1 /usr/local/www/widgets/widgets/suricata_alerts.widget.php(78): suricata_widget_get_alerts()
#2 {main}
  thrown in /usr/local/www/widgets/widgets/suricata_alerts.widget.php on line 188
[26-Mar-2026 21:32:12 America/New_York] PHP Fatal error:  Uncaught ValueError: date_create_from_format(): Argument #2 ($datetime) must not contain any null bytes in /usr/local/www/widgets/widgets/suricata_alerts.widget.php:188
Stack trace:
#0 /usr/local/www/widgets/widgets/suricata_alerts.widget.php(188): date_create_from_format()
#1 /usr/local/www/widgets/widgets/suricata_alerts.widget.php(78): suricata_widget_get_alerts()
#2 {main}
  thrown in /usr/local/www/widgets/widgets/suricata_alerts.widget.php on line 188

No FreeBSD crash data found.

The system is running totally fine. All services are up, no issues are shown. I checked in shell.

Only when i use "pfSsh.php playback svc status" in shell, i get the error:

<pre style="white-space: pre-wrap;">PHP ERROR: Type: 1, File: /etc/inc/util.inc, Line: 142, Message: Uncaught TypeError: is_process_running(): Argument #1 ($name) must be of type string, null given, called in /etc/inc/service-utils.inc on line 290 and defined in /etc/inc/util.inc:142
Stack trace:
#0 /etc/inc/service-utils.inc(290): is_process_running()
#1 /etc/inc/service-utils.inc(607): is_service_running()
#2 /usr/local/sbin/pfSsh.php(374) : eval()&#039;d code(119): get_service_status()
#3 /usr/local/sbin/pfSsh.php(374): eval()
#4 /usr/local/sbin/pfSsh.php(379): playback_text()
#5 /usr/local/sbin/pfSsh.php(233): playback_file()
#6 {main}(°information text

For me this is only a "cosmetics" issue cuz pfsense is using PHP only for the GUI. Seems like it has zero impact on pfsense. But i want to try to fix it anyway or at least to find out whats the problem exactely.

Maybe someone has a plan how to do it?

When i try it to put "tune.lua.bool-sample-conversion normal" in the global advanced pass thru it comes behind the lua load section and this tunable needs to be in front of it. Trying to manualy edit the haproxy config file its not kept after reboot. It seems to that i need to have an option in the tunables section to add this tuneable "tune.lua.bool-sample-conversion normal"

I am trying to customize HOME_NET for Suricata on pfSense CE and something seems inconsistent between the GUI and the actual rule evaluation.

What I did (following the recommended procedure from this thread):

Created an alias SURICATA_HOME_NET containing:

10.0.10.0/24

10.0.20.0/24

10.0.30.0/24

10.0.40.0/24

192.168.200.200/32 (WAN IP of the firewall)

Created a Pass List, added that alias at the bottom, saved it.

In Suricata → Interface Settings (WAN), in “Networks Suricata Should Inspect and Protect”, I selected this Pass List as HOME_NET, saved and restarted Suricata.

In the WAN interface I can see via “View HOME_NET” that 192.168.200.200/32 is indeed listed as part of HOME_NET, and EXTERNAL_NET looks correct as !HOME_NET.

I added the following two custom rules to custom.rules on the WAN interface:

alert tcp any any -> $HOME_NET 1:1024 (msg:"LAB T1046 SYN to HOME_NET"; flags:S; sid:4000001; rev:4;)
alert tcp any any -> 192.168.200.200 1:1024 (msg:"LAB T1046 SYN to WAN"; flags:S; sid:3999999; rev:3;)

After Save + Apply + restart of Suricata on WAN, I run:

nmap -sS -Pn -p1-1024 192.168.200.200

Result:

• list itemThe rule with the literal IP (sid:3999999) triggers alerts as expected.
• The rule using $HOME_NET (sid:4000001) never fires, even though 192.168.200.200/32 is clearly shown in the HOME_NET list in the GUI.

At the same time, a very simple test rule:

alert icmp any any -> any any (msg:"LAB TEST ICMP ANY"; sid:4999999; rev:1;)

does fire normally on the same interface, so custom.rules is loaded and working.

So the situation is:

• custom rules are loaded and working,
• HOME_NET/EXTERNAL_NET Pass List is configured and visible in “View HOME_NET”,
• traffic definitely hits the WAN interface (the static-IP rule sees it),
• but rules using $HOME_NET as destination do not match that same traffic.

Is this a known issue or am I misunderstanding how HOME_NET from a Pass List is applied internally? Any hints how to debug why $HOME_NET does not seem to include 192.168.200.200/32 at rule evaluation time, even though the GUI says it does?

I'd like to know if there is a reason for tha behavior below or if I could present a fix for that:

When presenting the list of CAs or the list of certificate, the main column is "Distinct Name", that is obtained from an array in the decoded certificate by function cert_get_subject in /etc/inc/certs.inc. For some reason, the elements of DN are sorted alphabetically by key, that means, the country (C) is always first, state (ST) usually the last with other elements in between. That order has no sense at all, so I see no help at all in two commands there. Although a distinct name is understood by many application, no matter the order of the elements, there are some where that matters a lot. IPsec, for example, will not allow conection if the ID used is a DN in a order different from the actual certificate. So, copying the DN from the Certificates GUI and pasting in IPsec phase 1 settings will give you a headache with no purpose.

More, as said, the new alphabetic order means not but non-sense. To get worst, creating the string, the function join the elements backwards (starting with ST, ending with C). The actual order in the certificates created by pfSense webGUI makes much more sense (starts with CN - more specific, ends with C - less specific). In my point of view, it helps nothing the reordering and is less helpful also, as we can't use it in other applications (we actually must open the certificates details and copy the DN record that is exactly the name above, but, this time, in the correct order.

If that's an issue, the correction is very easy, deleting two lines (the sorting) and adjusting other two (the one that is assembling the elements in the reverse order.