PHP Fatal error after adding port forward

axxxxe

I just tried to forward a port from my WAN port to a static IP on my LAN. I selected NAT reflection: Enable and Filter rule: Add associated filter rule.

After doing this I returned to the dashboard and found "Netgate pfSense Plus has detected a crash report or programming bug." which led me to:

=====
Crash report begins. Anonymous machine information:

arm
14.0-CURRENT
FreeBSD 14.0-CURRENT armv7 1400094 #1 plus-RELENG_23_09_1-n256200-3de1e293f3a: Wed Dec 6 20:55:45 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1-main/obj/armv7/XXxrkrip/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1

Crash report details:

PHP Errors:
[28-Jul-2025 15:11:12 Europe/Zurich] PHP Fatal error: Uncaught TypeError: format_number(): Argument #1 ($num) must be of type int, float given, called in /usr/local/www/firewall_rules.php on line 125 and defined in /etc/inc/util.inc:2338
Stack trace:
#0 /usr/local/www/firewall_rules.php(125): format_number(8715080869.0)
#1 /usr/local/www/firewall_rules.php(581): print_states(11000, 11999)
#2 {main}
thrown in /etc/inc/util.inc on line 2338

=

Now if I click on Firewall / Rules all of my interfaces appear to have no rules. Clicking between interfaces on the Rules page will eventually lock up the web interface.

How can I recover from this? Are my old rules active? I'm hoping this is just the web interface that's broken and not the underlying firewall config!

Gertjan

@axxxxe said in PHP Fatal error after adding port forward:

I just tried to forward a port from my WAN port to a static IP on my LAN.

Port forwarding ..... so devices from the Internet can reach an internal, LAN based, device, right ?

See here : Network Address Translation - so chose the very first proposition called Port Forwarding.

Imho, : you don't need to use, and don't need to deal with NAT Reflection.

delete your faulty NAT rule, reload the firewall and restart using [Network Address Translation](Network Address Translation) - so you've chosen the first proposition called Port Forwarding.

Btw : Beta 23.09 ?
Is it because you use an arm based device you've stopped updating / upgrading ?

stephenw10

Yup, you should upgrade. 23.09.1 is later than the last release for the SG-1000 so it must be a 3100 which supports the current Plus version.

You might have pulled in a newer pkg if the branch is selected and that could cause the PHP error.

axxxxe

Ok, thanks for the suggestions. It's a Netgate 3100 and running in production. I will try to update this weekend. (The old firewall rules do appear to be in operation - whew!)

axxxxe

I removed the NAT rule and the router restarted cleanly. All working ok now.
I will be upgrading to a Netgate 4200 in the next weeks.

stephenw10

You can upgrade the 3100 to 24.11 (or soon 25.07).

axxxxe

Interesting! I thought the 3100 was end of life a while ago.

stephenw10

Technically is was but as long as we can still build for it without too much difficulty we will try. There are some packages that no linger build for arm32 and are not available there. At some point the work required to make it build will become impractical and it will no longer upgradable.

nepeterson

I'm still getting this issue on 25.07.1-RELEASE, but I was able to fix it by opening /usr/local/www/firewall_rules.php in "Diagnostics -> Edit File" and changing the format_number entries on line ~125 from:

   format_number($evaluations),
   format_number($packets),
   format_number($bytes)

to:

   format_number((int)$evaluations),
   format_number((int)$packets),
   format_number((int)$bytes)

Save and the Firewall -> Rules page loads right away with no issue. Seems like a simple fix to still be having an issue this late in the development/deployment...

stephenw10

Do you know what rule you had that hit that?

Also I assume you mean: format_bytes((int)$bytes) ?

nepeterson

@stephenw10

No idea which rule hit that issue. I work for an MSP and we have dozens of rules across ~10 VLANs and our 3100 manages 6 public IP addresses (we lease a /29 network from the ISP). pfSense has been rock solid for us for the better part of a decade, other than this one bug that requires me to manually patch it with each release/upgrade.

Also, yes; format_bytes is correct, rather than format_number as used in the previous 2 lines. Good catch!

marcosm

The rules data comes from calling pfSense_get_pf_rules();. The relevant values returned by that function should already be integers and hence the casting to int shouldn't be necessary. Given that you mention the 3100 my guess is that there's some 32-bit specific issue when retrieving the values. That's unlikely to be fixed given that the 3100 is the only 32-bit ARM device that we have and it's been EOL'd for quite some time. You can run the following from Diagnostics > Command Prompt > Execute PHP Commands to try finding the offending rule: var_dump(pfSense_get_pf_rules());

If you can replicate the issue on another platform, please create a redmine with the details and we can follow up on it.

stephenw10

Mmm, that would be very interesting. I'm not seeing that on any rules on any 3100s here but presumably you have a relatively unusual rule. Or potentially some very high numbers being reported.

stephenw10

Ah actually it's probably this: https://redmine.pfsense.org/issues/14440