NAT forward rules
ALIX 2d13 latest image 2.2-RELEASE FreeBSD 10.1-RELEASE-p4 built on Thu Jan 22 14:04:25 CST 2015
I was able to add new rules, without a problem. But after enableing "UPNP & NAT-PMP", now whenever I want to add a new forward rule, php-fpm increases cpu slowly and then crashes and website gives error
500 - Internal Server Error
lighttpd: (mod_fastcgi.c.2562) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: unix:/var/run/php-fpm.socket kernel: pid 65338 (php-fpm), uid 0, was killed: out of swap space lighttpd: (mod_fastcgi.c.3346) response not received, request sent: 968 on socket: unix:/var/run/php-fpm.socket for /firewall_nat_edit.php?dup=2, closing connection
It's not a memory issue, because it crashes without using all the memory, ..
And I've disabled UPNP & NAT-PMP, however it doesn't go away.
kernel: pid 65338 (php-fpm), uid 0, was killed: out of swap space
On Alix there is only 256MB real memory and no swap space. So that "out of swap space" message really means "out of real memory".
Something is causing PHP to go into a spin and allocate a load of memory. On a 256MB system like that it will exhaust real memory before it exhausts the PHP allowed virtual address space for the process.
There is code that extends the firewall_nat_edit page:
I guess that code is installed by some package - does your system have any of those files in /usr/local/pkg/firewall_nat ?
That might be a source of unusual things starting to happen and not going away.
That directory doesn't exist:
And ok it goes from 123M to 56M however there's still free memory. However once the CPU hits 100% it just crashes.
firewall_nat_edit.php has a call to gen_subnet_max() - and gen_subnet_max() has a nasty bug on 32-bit systems which will cause code to loop through IP addresses up to 255.255.255.255, consuming a little memory and CPU in the process.
In this case it looks like it is called when there are VIPs, so if you have VIPs then firewall_nat_edit might go into a spin.
It is fixed by commit: https://github.com/pfsense/pfsense/commit/e69a0cf3a216c8647a6def4eee41ab01319ce90f
Whatever the problem is here, you certainly want this fix anyway - as the bug sends various things into a spin where gen_subnet_max() is called.
This was the reason thank you very much.
EDIT: only the fix doesn't work, Fatal error: Cannot redeclare gen_subnetv4_max() (previously declared in /etc/inc/util.inc:323) in /etc/inc/util.inc on line 355
I had to download the whole file and now it works https://raw.githubusercontent.com/pfsense/pfsense/master/etc/inc/util.inc
Line 323 is function gen_subnetv4($ipaddr, $bits)
I guess you had some editing error :(
imho it's best to use the system->patches addon to insert commits