Configure firewall rules / NAT from console (no more access to WUI after firewall rule created in WUI))

Dear IPFire PROs

I thoroughly screwed up (related to my capabilities) and would be glad if I could get some support on the below:

  • My initial IPFire system main aspects:
    Alix board w/ red (WAN), green (LAN), blue (WiFi), orange (DMZ), OVPN
    IPFire 2.21 (i586) core 128
    No specific firewall rules except routing blue to green for TCP and UDP
    SSH is off.

  • tried to create a (set of) firewall rules in IPFire WUI to tie in a device that obviously could not communicate with it’s cloud service based on existing firewall rules (DMZ pinhole) (excluded device defect by tying it in at ISP router which I need to use as modem)

  • gave that device which is connected via ethernet only a static IP based on MAC in IPFire DHCP setup

  • Managed with some firewall rule configuration to reach a sync, but no further communication as it would do if it was not sitting behind my firewall

  • attempted further variations of firewall rule and finally managed (seemingly) to route ALL queries directed to my IPFire to the IP of that device, since actually i cannot reach my IPFire WUI any longer.

  • Only access I still have to the IPFire currently is to the console via RS232 and Putty.

  • Internet access through the IPFire sill works, however since I’m not 100% sure what that latest rule variation does, I unplugged red (long live mobile hotspot)

  • I researched couple of community entries and wiki articles and could find one line in iptables FORWARDFW rules that would most likely represent this malicious rule i created, however it seems that it will not be removed even if i use iptables -D to this line - or if it takes effect, which other rule in iptables would relate to this:

      -A FORWARDFW -d 192.168.0.**/32 -i red0 -j ACCEPT

which seems to be the same as below in FORWARDFW chain for iptables -L

    ACCEPT     all  --  anywhere             **device.**Network
  • only other line i traced that /could/ be related is this one in POLICYFWD after doing iptables -L:

      ACCEPT     all  --  **Fire.**Network/24  anywhere

otherwise I could not identify any rules or chains from iptables that would have an indication to the specific device or the IPFire host.

  • I looked into the firewall.local yet I could not find a more detailed syntax / description on how firewall rules are represented there, how and where they are tied in, which would give me sufficient confidence to utilize this script.

If I remember correctly, that rule looked like the following in WUI (but i might be wrong here):

Source: Standard Network RED
NAT: Destination NAT (Port forwarding)
New source IP: green (IP of IPFire)
Destination: static Device IP

Optically it looked in the rules list such that RED was listed under source and a combination of IPFire address above target address was listed under Destination.

So here I am now, asking kindly and hoping for your support or guidance on how I best could remove this stupid rule that forwards my former WUI query to a different IP (respectively masks the reply with a different IP) so that I can no longer reach it, other than by console.

Thanks in advance for your replies, and let me know what additional information would be required to give recommendations.


If you have access via Putty, you can try using elinks.
After connecting, type elinks in SSH console.
Then you can log in

After logging in, you can go to Firewall Rules and try to fix what you broke.

Maybe you just need to remove the bad rule.

After deleting the rule, be sure to Apply changes

A little hint. When you press F9, the elinks menu shows up.




" elinks, the text-based browser is also no longer an add-on any more, but shipped with the core system."


Hi tphz,

thanks for that detailed reply, i was looking into it already and possibly fail already in installing elinks:

  • tried to upgrade my IPfire (since i read that elinks is included in later versions) but received error message:

CORE UPGR: Upgrading from release 128 to 131
meta-core-upgrade… 100.00% |=============================>| 964.00 B
core-upgrade-2.21… 100.00% |=============================>| 8.93 MB
meta-core-upgrade… 100.00% |=============================>| 964.00 B
core-upgrade-2.21… 100.00% |=============================>| 2.46 MB
meta-core-upgrade… 100.00% |=============================>| 965.00 B
core-upgrade-2.23… 100.00% |=============================>| 52.70 MB
DOWNLOAD ERROR: The downloaded file (os/Linux/distr/ipfire/pakfire2/2.21/paks/core-upgrade-2.23-131.ipfire) wasn’t verified by Sorry - Exiting…
TIME ERROR: Unable to get the nettime, this may lead to the verification error.

  • tried to get individual packfire package but seems no longer there (even after packfire update):

PAKFIRE WARN: The pak “elinks” is not known. Please try running “pakfire update”.
PAKFIRE ERROR: No packages to install. Exiting…

  • started the attempt to install it from elinks homepage, download with wget successful but
    a) upon ./configure of the extracted package i receive error

checking for aclocal… config/missing aclocal
checking for autoconf… config/missing autoconf
checking for autoheader… config/missing autoheader
checking for gnumake… no
checking for gmake… no
checking for make… no
checking for false… /bin/false
checking for “./features.conf”… yes
checking for “/home/elinks-0.11.7/features.conf”… yes
checking for gcc… no
checking for cc… no
checking for cl.exe… no
configure: error: no acceptable C compiler found in $PATH
See `config.log’ for more details.

b) in IPFire documentation I found this page which suggests that this process is exceeding my current abilities (though I’m open for learning)

Ideally i could call for the old packfire package - but I am not sure how I could do this?
Second option would be to “fix” the error for packfire upgrade - would you have suggestions here how to overcome?

Thanks again

Your problem with upgrading is likely to be because your current version is Core Update 128 which is 2.5 years old. IPFire is currently on Core Update 159. There have been many changes in that time period, some of which may give problems with trying to upgrade with such a large jump.

Maybe check if the time of your IPFire is correct. This message is suggesting it couldn’t get the time from your IPFire and that is why ther verification failed.

I found this message in the forum which might be suggesting that the verification failure could be because of lack of memory.

elinks was moved from being an addon to being a part of the core4 distribution in Core Update 141 so that is why you can’t find it any more as an addon.

You could look at doing a new install and then doing a restore from your backups but even with that there might be differences in what is stored in the backup from so long ago with what the packages expect to get now.

I think your two best options are

  • To wait till someone who has the knowledge can tell you in what files to make what changes to fix the issues that you have. I don’t know enough about where the firewall rules are placed to be able to help on that topic.
  • Doing a fresh install and seeing how the backup restore works or recreating your configuration if it is not too complicated.

I note that you have the i586 version. In case you are not aware, the End Of Life for the i586 version has been defined for end of 2021. After that there will be no Core Updates for i586.

So if your Alix is 64 bit compatible then you should really upgrade to the 64 bit IPFire version.
If your Alix is physically 32 bit then you need to be thinking about getting some new hardware. The two blog articles give the background for why you should be looking to do this.


Hi bonnietwin,

thanks as well to you for your detailed reply! :muscle:

The hint to the memory was a good one :+1: - i remember experiencing this issue in the past every now and then. So I managed to overcome it by killing Guardian on my IPFire from the console, which I know is a huge memory consumer and doesn’t harm until next reboot. With this i managed to get a step closer to my target :smiling_face_with_three_hearts:

Will keep you updated.

Thanks again

1 Like

Hi @moodymammoth

Glad to hear you are making progress.
:crossed_fingers: That you will be successful.

1 Like

:thinking: I think so…

If access to WUI is blocked, after insert some rule in WUI --> Firewall Rules,
and you cannot start or install elinks, at the same time,
but you have access to SSH console

then, (for emergency restore access to WUI from GREEN network) you can try some solution:

  • login to SSH console
  • go to /var/ipfire/firewall folder
  • rename config to config.old
  • rename input to input.old
  • rename outgoing to outgoing.old
  • reboot

If I’m wrong, someone please correct me.

1 Like

@tphz , @bonnietwin

so so many thanks :pray: :pray: :pray:

I managed to reach core 141 and deactivate the rule via elinks, and what should I say. I have back the access to the WUI :clap: :clap: :clap: :+1: :muscle:

For reference, this is what the rule looks like:

Let this be a warning to all users, how to NOT configure a firewall rule :see_no_evil:
In future I will always add a time limit to the rules I create as long as I can’t judge the outcome - like that I will at least be able to get back into the system after some time if I shut me out…

Thanks once more and stay safe