Firewall-config Not Functional

Home » CentOS » Firewall-config Not Functional
CentOS 10 Comments

I have a number of machines (hardware and VMs) running CentOS 7. I all cases firewall-config is not functional.

First, the service check boxes are not functional. When you click on one, it don’t change to “checked”, and nothing changes on the firewall. However you do see a “Changes applied”

Sometimes, f you go to permanent mode and attempt to edit a zone, the whole desktop locks up as soon as you click on the default target dropdown.

When I run firewall-config from the command line I see the following:

————————

10 thoughts on - Firewall-config Not Functional

  • cases firewall-config is not functional. one, it don’t change to “checked”, and nothing changes on the firewall. However you do see a “Changes applied”
    whole desktop locks up as soon as you click on the default target dropdown. org.freedesktop.NetworkManager was not provided by any .service files assertion ‘tree_view != NULL’ failed interact with the GUI. Though we do install NetworkManager-glib, if only because some packages require it. NetworkManager-libnm, but that did not make a difference. That RHEL bug also mentioned this problem only occurs on KDE, and not Gnome. And we only install KDE when a GUI is required, or desired.

    I’d suggest you install and test with NetworkManager

    Do note that the EL7 NM is a far cry from the one that shipped with EL6 and unless you specifically need a facility not exposed by NM it is strongly recommended you use it.

    Take a look at my article on nmcli – it’s rather lovely to use now:

    https://www.hogarthuk.com/?q=node/8

    As for the firewall tool… don’t use it … it’s horrible

    Either use firewall-cmd to configure at the CLI or switch to iptables and configure that as you did EL6

  • I actually like the firewall config tool as it provides easy, out of the box, management of servers that don’t require complicated iptables rules. At least it was easy when it worked. For more complicated servers, like gateways, we use shorewall.

    I can see no use case for NetwortManager on our systems. All network connections are static.

    The exception to that is a couple of laptops, and I agree that NetworkManager has gotten very handy in that single use case.

    Making any application dependent on NetworkManager is just plain silly. Even requiring installation of the NetworkManager libs should not be required.

    I suspect that this should probably be brought with the KDE group as it seems to be a problem with how some GTK apps are working within the KDE environment.

    Emmett

  • Just a thought – CentOS7 _minimal_ install doesn’t install a firewall. There were attempts to get Red Hat to reconsider this, but they fixed it with documentation.

    If this is your problem, then “yum install firewall-config firewalld”
    might fix it.

    HTH, HAND,

  • There are a couple reasons I still use NetworkManager on servers, but one big one is that the ‘network’ service runs once, on boot. If there is no network connection, your server’s network connection will never come up until you log in at a console to fix it or reboot. With the speed of computers these days, our servers often boot up faster than the networking equipment after a power cut.

  • Jonathan Billings wrote:
    Um, huh? SSH server;service network restart is certainly faster than a reboot.

    mark

  • By what magical incantation will you SSH into a server with no current network connection?

  • As far as I know the network service, in most cases started by systemd, will not fail simply because the network an interface is connected to is not up. Unless, of course, the interface is set up to use DHCP.

    Emmett

  • I must be missing something here, so the system comes up, ip(s) are assigned to the interface, routes, etc then sometime later the switch comes up and you ssh in. Never been a problem for me.

  • Even with static configurations, I’ve had this problem. At least in RHEL6, if the switch doesn’t indicate the interface is up during boot, the ‘network’ service detects the down interface and never starts the network service. full stop. I’ve also seen this happen when the switch has a broadcast storm or some other networking problem and doesn’t become active for more than a minute after boot. Often I’ll have to add a line to the ifcfg-* script to have it just sleep for 60 seconds before even trying to activate the interface, when I know the system is on a switch that takes a long time to perform its splay tree calculation. (Many of my systems are on networks I have no control over, so I have to just work around problems like this.)

    I’ve always used NM in RHEL7 so I’m not aware if systemd is smart about dynamic interface activation of the ‘network’ service. NM in RHEL7 is so much better than in RHEL6 so I haven’t really needed anything else.

    —
    Jonathan Billings