Rule Web-Gui broken since 151

I have the same problem on i686, GUI doesn’t work.
You can try temporary solution with ssh connection to your server:

iptables-save > /etc/iptables.rules
edit this file and then
iptables-restore < /etc/iptables.rules

1 Like

This solution requests deep knowledge of iptables and the firewall in IPFire!
You should do that only, if you exactly know what you are doing. In worst case you cut your SSH connection. Better to do this on the console directly.

1 Like

Got the same problem even on test build 152 (Intel Atom X86 machine).

Hi, same Problem. Sorry for my bad english.

IPFire 2.25 (i586) - Core Update 151 (and some other architectures by customer, all ca. 30 times).
Rules are functional! No Edit, no new Rules
Edit iptables by shell is no option for normal users!

I hope this will help.

Have a look

nano /var/log/httpd/error_log

Clear Log

echo "" > /var/log/httpd/error_log

Read Log

tail -f /var/log/httpd/error_log

Edit some Rule by WUI

Edit some rule


[root@ipfire1 ~]# tail -f /var/log/httpd/error_log

libloc: loc_database_free: Could not unmap network nodes section: Invalid argument
Could not read database: /var/lib/location//database.db

Some Ideas?

Thanks, Lars


  • Backup of the settings
  • New installation x64 Core 151
  • Restore the settings

Time expenditure approx. 1 hour. I hope there will be another solution. If I have to do this with 30 firewalls then that is …


x64 for i686? Did you read the whole topic?

I migrated all my firewalls to 64 bit some 2+ years ago. A few required newer hardware (mainly cheap pre-owned Dell Optiplex SFF). It’s a one off migration, and as 32 bit being dropped by most operating systems, including Linux/IPFire, better to do sooner rather than later. There is really no excuse now that 64 bit hardware readily available at low cost.

Some of my 64 bit boxes that had HyperThreading CPU have been replaced too since Spectre/Meltdown, so even 64 bit machines might need upgrading for better performance/security.

Have fun!

1 Like

If your installations are 32bit… better start early.

Got the same issue on a fresh install on Raspberry PI 3 today… Wanted to try your captive portal voucher thing…

Any idead when a fix is on the horizon ?

Thanks in advance.

Best Regards,

For the record. The proposed solution in the bug report, to reduce init calls, works for me. Reinstalling didnt. If you really cant wait, diff the solution to the existing content of the /var/ipfire/ and make sure you understand what changes are being proposed.

1 Like

This solution is in development for the next update(s). It works for me also and is together with some other minor patches the right way to do the access to libloc.
At start of the module generate an interface object to the data base, use this during the process ( the web page for example ), delete it at exit.

1 Like

Hi - great that the solution is in development.
Do you know, when the update will be available or ist there a workaround?
My customer uses 60 IPFires and I really need to Update 1 Rule on each IPfire. Greetings.

1 Like

You can try my “work-around” from bugzilla


Thank!!! Works fine for my - did it 60 times :smiley:
Regards, Verena

1 Like

Hi all,

just for the records: The fix is scheduled for Core Update 153, which I expect to be closed in a few days, so there is probably a testing version available by next week.

Thanks, and best regards,
Peter Müller


I’m testing your patches now for some time. No problems. Thanks once more for converting my ‘work-around’ to a founded patch of the system.

Having read and checked the patches, run the ‘patched by hand’ system, I’m optimistic that the bug will be fixed with core 153.

1 Like

The change you propose on the file are the two lines on the bottom or did i missed something? Do i have to reboot the system after the change or just restart some service?

Thanks in advance

No, it is not only the initial init() call. Functions which did an init() call, are changed to use the global var instead. I’ve left the original code as comment. The origin of my work around was a trial for a correction of the issue.

Hi all,

in case you have not noticed: A testing version of Core Update 153 including this fix has been released today.

Thanks, and best regards,
Peter Müller

1 Like

Just chiming in to say I had this issue, I could not see the destination section in firewall rules on my pi 3b+ with 152 and as I’m brand new to ipfire I was thinking to myself “gee what am I supposed to do with a source only?” :joy::joy: But luckily I googled and came upon this thread.

Having updated to the 153 test build now has resolved this. Thank you muchly for your work people, love this project!!!