Firewalld module seems very confused about default zone. It can't seem to read it correctly and can't seem to set it correctly either.
On srv1, e.g., I've got the zone set to public. When I query it from the command line, it shows "public". When I check it in Webmin, it's showing "trusted".
Further, when I try to change it in Webmin, it doesn't do anything. Just reloads the page, and the default zone still shows up as "trusted"...even though it's not, according to Firewalld.
Roughly the same problem on another server, where default zone is set to public, but Webmin says there is no default zone (which I'm not even sure is possible)...and it can't change the default.
I'm confused. The commands being run in the module look reasonable (--set-default-zone is correct), but it's not doing anything in Webmin.
Comments
Oddly, it also shows up in the log as being correct (but isn't actually doing anything): 1497205812.18711.0 [11/Jun/2017 14:30:12] root 887103ec105053b05e208a0fa50867ef 173.123.96.48 firewalld default_zone.cgi "default" "zone" "public"
OK, I see why it's happening.
firewall-cmd --list-all-zones
Shows "(active)" beside trusted zone...which is true. But, active is not default. active is a different thing (though I can't figure out exactly what it means...still researching).
So:
# firewall-cmd --get-active-zonesLists trusted. As expected, since it shows up as active in the list-all-zones list.
# firewall-cmd --get-default-zoneShows public. Again, as expected.
So, bug is that Webmin thinks "active" is default, but it aint.
OK, so active seems to mean "default for this interface" and overrides default.
If I associate a zone with an interface like so:
# firewall-cmd --zone=dmz --add-interface=eth0It'll show up as "active" and will be the rules that are applied to the eth0 interface.
Default is more about how rules are applied, rather than what traffic the zone applies to. Running commands without a zone specified makes them apply to the default zone.
More importantly, it seems like (though my comprehension may be weak here) any interface that isn't assigned to a zone will not have the firewall applied at all...which seems bizarre, but I'm gonna do some experiments to understand this better.
Firewalld was built by someone with a strange brain. It feels like they've flipped everything upside down and made "zones" this really important concept and the actual firewall rules are kind of an afterthought and you have to jump through a bunch of hoops to make them do anything. It makes automating it harder because now we've gotta figure out what interfaces exist on the system, and which ones are "real" interfaces that we want to apply the firewall too in an automated fashion. (At least, I think that's what it means.)
OK, I've made a PR to fix this. It uses --get-default-zone to determine the default zone. Seems to work for me.
We may need more clarity about active zones in the UI (there's a way to set active zones, which is actually more clear than the firewalld docs indicate, so maybe we're already OK there).