If you try to remove one of the predefined zones from Firewalld, e.g. public, you encounter the following error:
Error: BUILTIN_ZONE: 'public' is built-in zone
I don’t like that Firewalld is bloated with all of these built in zones that I will never use. I want to get rid of them, but, from what I’ve been able to find, it appears non-trivial to do so.
EDIT (2024-01-27T01:55Z):
I came across this GitHub issue. So it appears that this is a known “issue”, and it could potentially be changed in the future, albeit probably far in the future. It is a very strange initial design choice, though, in my opinion.
Because the people that wrote it decided to make it that way. If you don’t like it, just remove firewalld and manage your iptables/nftables directly
This is what I do.
Because the people that wrote it decided to make it that way.
Sure, but it still feels like a strange design decision.
If you don’t like it, just remove firewalld and manage your iptables/nftables directly
This is essentially what I ended up doing.
Maybe firewalld are not the right firewall for your use case if you feel the need to remove “bloat” zones? Do they impact your firewall efficiency?
Do they impact your firewall efficiency?
No – it just seems unnecessary to force the user to have the default ones – just allow the user to create the zones that they want/need.
The zones are there so you can set your ports/services as needed for home, work, public wiffi etc. the idea is you leave your ports alone and just swap adapter to the zone you are working in. Network Manager has a quick toggle on wifi to do this from connection settings. So at home your laptop has ssh, smb open etc, when you connect to starbucks wifi you set wifi to public. The other part of zones is each as a fallback default you can specify. So if a port or service traffic doean’t match your home zone you can have if failover to default, in my case default is public. if that doean’t match either it can failover to “drop” or “block” etc. they have a heirachy.
if you are just dealing with cli it can be intimidating. You can try OpenSUSE in a VM and use the Yast Firewall Gui tool to play around with adapter, default, zones, services and ports and get familiar with the idea behind it.
I believe you may have misinterpereted my post. I wasn’t asking why zones exist, I was asking specifically why one cannot delete the default zones in Firewalld.
I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules. Maybe you know that already. If you have a static machine at work mayne you don’t need home zone, but it is not causing “bloat”. You would also still need drop, block and so on. My thought is if you think firewalld is bloat, just use iptables directly.
I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules.
Yes, I am aware of that. Just allow the user to specify the zones though. Why force the default ones?
but it is not causing “bloat”.
It is if it’s saving alternative configuration that will never be used.
just use iptables directly.
This is essentially what I ended up doing.
It makes sense for them to include the Reject, drop, type for obvious reasons, the others seem like they asked “what will be the most common use cases for networks?” so they threw them in as work, home, public and trusted, external, dns , etc so that somebody starting out doesn’t have to create zones from scratch. I doubt having one extra zone takes up very much in the way of kb of space. compared to how much junk I have in my downloads folder that i should triage. What would be nice though would be a rename function, because we may have different Work rules depending on which workplace you are at that day with a system.
Because it aligns with most people’s use case. You’re free to patch it out if you’re so inclined.
Because it aligns with most people’s use case.
Sure, that is why we have defaults, but why force them? Why not create the defaults, and then allow the user to remove them if they wish?
You’re free to patch it out if you’re so inclined.
This is somewhat of a non-answer. Technically, yes, it is possible for a user to patch OSS as they see fit, but that does not excuse poor design desicions, nor is it necessarily fair to expect the user to do that.
Maybe you should take it up with the maintainers. I can’t tell you what they were thinking.
Maybe you should take it up with the maintainers.
See the linked GitHub issue.
