Firewalld Being Stupid

Home » CentOS » Firewalld Being Stupid
CentOS 18 Comments

Greetings,

One of my biggest frustrations with CentOS 7 has been firewalld.

Essentially all of the documentation just flat doesn’t work.

One common thing that needs to be done is to change the zone of an interface, however I’ve tried:

firewall-cmd –permanent –zone=internal –change-interface=ens192
firewall-cmd –permanent –zone=internal –add-interface=ens192

I’ve also tried setting in /etc/sysconfig/network-scripts/ifcfg-ens192:

ZONE=internal ZONE=”internal”

No matter what, when firewalld starts, ens192 will be in the public zone.

What am I doing wrong? Why does the documented command structure not work?

18 thoughts on - Firewalld Being Stupid

  • I haven’t messed with firewalld yet, so the following is purely conjecture…

    does

    firewall-cmd –get-zones

    list this “internal” zone ? if not, you may need to create it first,

    firewall-cmd –permanent –new-zone=internal
    firewall-cmd –reload

    THEN assign your interface to it,

    firewall-cmd –permanent –zone=internal –change-interface=ens192

  • interface, however I’ve tried:

    Firewalld does physical interfaces, NetworkManager has profiles on top of them. NM can specify a zone and communicate it to firewalld – which should work from your ifcfg edit – but the reverse currently doesn’t happen. Try with nmcli:

    nmcli con modify ens19p0 connection.zone internal

    …btw, the insertion of the ‘p’ was deliberate, I’ve seen more device names of that form. doublecheck your device name too.

    –Pete

  • I have a couple of relevant articles you may be interested in …

    On assigning the zone via NM:
    https://www.hogarthuk.com/?q=node/8

    Look down to the “Specifying a particular firewall zone” bit … remember that if you edit the files rather than using nmcli you must reload NM (or do nmcli reload) for that to take effect.

    If you specify a zone in NM then this will override the firewalld configuration if the zone is specified there.

    Here’s some firewalld stuff:
    https://www.hogarthuk.com/?q=node/9

    Don’t forget that if you use –permanent on a command you need to do a reload for it to read the config from disk and apply it.

  • Thanks for the articles, they’re informative.

    Here’s what’s really irritating me though.

    firewall-cmd –zone=internal –change-interface=ens224 –permanent

    ^^ This command results in NO ACTION TAKEN. The zone IS NOT CHANGED.

    firewall-cmd –zone=internal –change-interface=ens224

    This command results in the zone of ens224 being changed to internal, as desired. Of course, this is not permanent.

    As such, firewall-cmd –reload (or a reboot, ect) will revert to the public zone. To save the change, one must execute firewall-cmd
    –runtime-to-permanent.

    This is very frustrating, and not obvious. If –permanent doesn’t work for a command, then it should give an error – not silently fail without doing anything!

  • But –permanent *did* work.

    What you’re seeing is the documented behavior:
    –permanent
    The permanent option –permanent can be used to set options
    permanently. These changes are not effective immediately, only
    after service restart/reload or system reboot. Without the
    –permanent option, a change will only be part of the runtime
    configuration.

    If you want to make a change in runtime and permanent
    configuration, use the same call with and without the
    –permanent
    option.

  • That’s fairly annoying behavior as it creates the potential for accidentally diverging configurations. Why not do the same as virsh an have two options for this? When I attach a device I can specify –config to update the persistent configuration,
    –live to update the runtime configuration and both if I want to change both. That’s a much better API in my opinion.

    Regards,
    Dennis

  • Em 17-11-2015 01:26, Dennis Jacobfeuerborn escreveu:

    It’s the same thing but with different names and a default, –config. And I agree, it would be nice to be able to issue both options at once. Would you open a BZ asking for this or should I?

    Marcelo

  • This behaviour is congruent with SELinux. One utility adjusts the permanent configuration, the one that will be applied at startup. Another changes the current running environment without altering the startup config. From a sysadmin point of view this is desirable since changes to a running system are often performed for empirical testing. Leaving ephemeral state changes permanently fixed in the startup config could, and almost certainly would eventually, lead to serious problem during a reboot.

    Likewise, immediately introducing a state change to a running system when reconfiguring system startup options is just begging for an operations incident report.

    It may not be intuitive to some but it is certainly the logical way of handling this.

  • Another possible reason is because when you’re setting up firewalld, you might want to batch a bunch of changes with –permanent, then, once you’ve added them all, *then* you restart firewalld to pick up the changes. Having the firewall restart after *every* permanent change you want to make would leave the system’s firewall bouncing up and down.

  • The better way is to explicitly allow the user to dump the runtime configuration as the persistent configuration though as that makes it much more difficult to have subtly diverging configurations due to user errors. On network switches you often find something like “copy running-congig startup-config”.

    Regards,
    Dennis

  • I certainly don’t disagree with this behavior.

    What I disagree with is documented commands _*not working and failing silently*_.

  • No, it didn’t. Not for changing the zone.

    After using –permanent, and restarting the firewall, _the zone was not changed_. I’ve duplicated this behavior on a half dozen installs now.

  • Nick Bright wrote:
    I agree, and it seems to be the way systemd works, as a theme, as it were. I restart a service… and it tells me *nothing* at all. I have to run a second command, to ask the status. I’ve no idea why it’s “bad form” to tell me progress, and final result. You’d think they were an old New Englander…..

    mark, ayu’

  • Systemd has better mechanisms to report feedback compared to SysV
    scripts but if the creators of the service files and the daemons don’t make use of these that’s hardly systemd’s fault. The best way is to use
    “Type=notify” which allows a daemon to actually report to systemd when it is done initializing. If the daemon doesn’t support this then you can still use ExecStartPost to specify a command that verifies that the daemon indeed did start up correctly (and no the binary returning a code of 0 does not mean the service is actually up-and-running properly).

    Regards,
    Dennis

  • You may well be right. However for those of us who just want to get the system running it has lousy reporting. Under SysV setting -vx on the script gave meaningful output – there’s no easy equivalent under systemctl. Systemctl returning success status on daemon failure is plain stupid. I’m sure systemd does wonderful things and is the future and we’re stuck with it now until at least CentOS/RHEL 8. One of the great joys of *NIX is small, stable text files that can be handled without vast study unlike the obscure behemoth that would look good coming out of Redmond. Even getting ntp to supply time to another system takes hours instead of 5 minutes.

    If I ever meet Poettering I’ll be sure to sup with a long spoon. ;-(
    —–BEGIN PGP SIGNATURE—