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.
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 IPFire.org. 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.
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?
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.
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.
The hint to the memory was a good one - 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
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:
Let this be a warning to all users, how to NOT configure a firewall rule
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…
- 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 
That you will be successful.
I think so…
