firewalld can be opaque
Just wasted two hours of my life discovering that firewalld has no facility for allowing routing between subnets on different interfaces.
firewall-cmd –direct –add-rule ipv4 filter FORWARD 0 -i $int1 -o $int2 -j ACCEPT
That was after discovering that using –permanent to change the zone assignment of an interface, well, isn’t permanent. But it doesn’t tell you that; it just announces “success”. You’re supposed to have read firewalld.zones and know that you have to edit the ifcfg file.
I’ll give this a shot, I guess, but I begin to think that my /etc/sysconfig/iptables from the previous (pre-firewalld) incarnation of this server may be the winning entry. I spent less time writing that by hand in the first place than I did debugging firewalld being opaque.
Michael K Johnson February 28, 2015 08:09
In theory, something like firewalld ought to make the process of setting up a firewall simpler, by having a simpler but consistent model.
In practice, firewalld fails because it can’t generally be understood alone. You can’t use it based on its simplified model and expect to get meaningful results. You still have to know iptables well, but now you also have to understand firewalld’s internal model, and know how firewalld’s internal model relates to iptables, which the documentation didn’t always clearly convey to me. This is why it can end up being easier to use iptables directly than to use firewalld when you want anything much more complex than an end-point desktop firewall.
In fact, you have to know more about iptables to work with firewalld than to use iptables alone, because if you are just using iptables to write a firewall configuration, you can be parsimonious in expression, but (as is normal and I think reasonable for generalized tools) the iptables configuration that firewalld generates is a large haystack to look for a needle in, and so is hard to debug rules failures. Here, it took a long time reading iptables-save output before I finally realized that there were missing FORWARD rules. There were a lot of FORWARD rules, just not a few that I needed. (It’s much harder to notice that something is missing than to spot something extra or wrong.)
For now, I’ll keep trying to use firewalld, since I think I finally have it working roughly the way I want, but if it causes me much more grief I’ll probably bail.
All that griping aside, if I do bail on firewalld and implement iptables directly, I’ll have a better iptables implementation than I did on the previous system because I was missing some uses of conntrack before, and I realized that while looking through iptables-save output trying to debug my broken configuration. ☺
Bastien Nocera February 28, 2015 12:50
The fact that firewalld’s “API” is opaque and harder to use than anything it could be hiding seems to be lost on its maintainers.
Michael K Johnson April 15, 2015 20:16
After a reboot, firewalld forgot which zone to associate my external network interface with. No, I hadn’t forgotten the –permanent; I checked history.
Also, dhcpd tried to start before the network was up and systemd gave up due to too many restarts. So firewalld isn’t the only flaky element of this stack.
Bastien Nocera April 16, 2015 00:18
I don’t see why dhcpd should wait for the network to be up. Hardly necessary.
Michael K Johnson April 16, 2015 05:36
It needs to know which interfaces to attach to. In my case that’s particularly important because one interface is my external interface for which the address is assigned by my provider’s DHCP server, and then there are two internal bridges on which I run a DHCP server, and the server must attach only to the bridge interfaces.
Michael K Johnson April 16, 2015 05:51
Also: my point about “I hadn’t forgotten the –permanent” is because I had forgotten that this particular assignment isn’t permanent but firewall-cmd doesn’t bother to remind you. Therefore I checked history and found it before I remembered this post.
The sad part that I forgot to mention is that it didn’t honor the setting that I had correctly put into the ifcfg file with a ZONE line. That’s the “flaky” part.
Imported from Google+ — content and formatting may not be reliable