Turris Omnia - rtrom01
Turris OS 3.9.6
Kernel 4.4.119-082ea0f4a4e204b99821bedcb349ed54-0
stopped the firewall with /etc/init.d/firewall stop and network connectivity ceased entirely, the router not being accessible at all, neither through SSH nor http.
I hope that is not really by design, at least LAN connectivity should remain and thus access to the router from a LAN ip.
Same happens when the LAN zone is deleted from the the firewall and the router cannot be accessed even after a reboot (in a way logical since the LAN zone is not restoed). However removing the LAN zone from the firewall should not prevent LAN connectivity.
In the process of making a cut from iptables and switching to nftables (firewall) I am stuck now that fw3 can neither be disabled nor (preferrably) removed.
I procured this amzing device as being advertised as
an open Linux distribution in your device and can do anything you would with a normal Linux server. You can install additional software, reconfigure things from scratch etc. We simply do not limit you in what you want to do. Quite the opposite
I’m not sure about it but it could be that the routing from the LAN switch to the CPU ports is done by via iptables:
You could also try to use iptables-save to store the current iptables rules and then remove a single rule, restore with iptables-restore until you have a minimal iptable that only contains basic rules and then try to implement that in nftables.
The iptables rules do not seem to be doing any network routing and they should not as they are just netfilters. There are other components for routing and those should be not be impeded by the removal of filter zones/rules.
It is common standard to be able to turn off or remove the firewall or remove the firewall lan zone without loosing entire network connectivity, let alone access to the router.
Commonly a linux firewall is just an executable script with iptables or nftables rules being invoked at certain events, e.g. boot, change of firewall zones/rules, hotplugin etc.
fw3 however also has its own module /sbin/fw3 and not sure what its purpose and whether it might be the culprit to the issue.
Hello,
as you said in your OP, that’s correct behavior.
Once you remove LAN zone from firewall that default rule: Don’t talk with anyone! will apply, because our primary goal is security.
When you uninstall package firewall that you won’t have NAT and other things. Maybe IPTables has some patch in OpenWRT that it will drop all communication
@Pepe Since when is NAT part of a firewall? A firewall is strictly for packet filtering but not routing the network.
And what are “other things”?
Sounds you are not sure what exactly is happening wiht the firewall.
Like stated above I procured the router also with the aspect of being advertised as
open Linux distribution in your device and can do anything you would with a normal Linux server
On any normal linux server one can do whathever one wants with iptables/firewall scripts which does not seem to hold true however for Turris, apparently taking the server hostage by fw3. How is that for “can do anything”?
Routing is not part of the firewall but NAT is, at least on Linux.
Actually now that I read most of the stuff, when you uninstall firewall package, firewall gets stopped and flushes all the rules and ends up with the default ones which are dropping everything.
As with any Linux server, you can do anything. But it also implicitly expects that you know what are you doing. With server, you can also easily misconfigure firewall and cut yourself off the server which is what you did here. I bet you can still connect over serial and configure your iptables by hand and log in again.
Removing firewall will close all the open ports, but you can write your own and open them up again, but you have to make sure you know what you are doing and that it doesn’t fail.
That implies that removing the firewall is not removing the firewall as residue (“default ones which are dropping everything”) is left behind. That makes little sense as in removing something should not leave residue behind but cleanly remove everything belonging.
Thats makes certainly sense for the WAN interface but not at all for the LAN interface. I have not come across any others Linux/FreeBSD distro that would behave in such curious way. In any other distro stopping/removing the firewall does not cut access to the server. Imagine it would and the number of system admistrators crossing the edge like lemmings when they could not access the server from the LAN anymore. But perhaps they all got serial consoles handy notwithstanding today’s global cloud structure and LANs spread across the globe through VPN, or servers shipping even without a serial port.
That is not correct, neither did I misconfigure the firewall nor cut myself off, this is caused by stopping/removing the firewall.
Where did you get this from? NAT is routing (Chain PREROUTING / Chain POSTROUTING).
This might be a good read about NAT and that it is not part of a firewall.
Why is it part of the firewall in the Turris repo? NAT is even listed in LuCi → Status → Firewall, which seems a bad mix of netfilter routing tables (NAT) with netfilter filter tables (firewall).
Probably the NAT rules getting flushed with anything else if the firewall is stopped/removed?
It removes all the rules, you are just being hit by -P {INPUT,OUTPUT,FORWARD} DROP
Ok, let’s be exact, it doesn’t close them it flushes all the rules opening the ports. I think that every sysadmin at least once entered reboot command by mistake to wrong terminal and flushed iptables rules forgeting what the policy is set to. To know what is LAN and WAN you need to configure it somewhere and that somewhere is a firewall configuration surprisingly part of firewall package. And your LAN don’t have to be LAN where you trust everybody, it could quite well be LAN full of potentially infected IoT devices.
Which is how you ended up with misconfigured firewall. Removing firewall stops it and it flushes the tables. So you either have to specify diferent default policy or have something that opens up a ports for you after you remove the firewall.
How are you making this sort of statement? NAT is not part of the firewall since both serving entirely different purposes. Both work with iptables or nftables as userland for the underlying netfilter but that is about what they got in common.
of course but not in the firewall script, NAT does not serve any purpose for accepting/dropping/rejecting packets, which is what the firewall is for and that is its only purpose.
If you would like to write your own firewall package that does stuff differently, feel free to do so. I’m telling you what went wrong and why. If you don’t believe it, that is your problem and you are free to believe in whatever you want, but I’m not going to discuss that with you.
@miska Not doubting but appreciating your input about how the firewall is behaving.
It is just a very weird implementation in Turris that access to the router from the LAN is cut off entirely, save perhaps for the serial port. I have evaluated quite a few Linux distros and none would exhibit such odd behaviour. What is the benefit/advantage of such implementation, concern that the LAN is compromised by something malicious in the LAN messing with the firewall?
Any other firewall that I thus far deployed I can disable without having access to the server entirely revoked, let alone uninstalling the firewall.
Sometimes network debugging requires to disable the firewall (even for the wan) which is not an uncommon scenario but apparently is impossible with this firewall implementation. And yet there is no explanation what the purpose of this strange implementation is.
Thus apparently there is no other choice than to write a script or backport some other free scripts like CSF or some other.
You could theoretically do this, it’s just that you’d need to disable the normal firewall rules and install a rule to allow access from LAN at the same time. It shouldn’t be that hard, something like /etc/init.d/firewall stop; iptables -A …
