Firewalld

Home » CentOS » Firewalld
CentOS 33 Comments

I just noticed that when rebooting a CentOS 7 server the firewall comes back up with both interfaces set to REJECT, instead of the eth1 interface set to ACCEPT as defined in ‘permanent’ firewalld configuration files.

All servers are up to date.

By “just noticed” I mean that I finally investigated why a newly rebooted VM failed to allow NFS connections. Prior to doing that. I’d been stopping the firewall to get access, then restarting the firewall after setting the eth1 interface to ACCEPT. This time I took a look at iptables and found that eth1 was set to REJECT, before I stopped the firewall. Because it was obvious that firewalld had been started by systemd by noticing the output of iptabled -nvL had the same set of rules you can see when firewalld is restarted, except that after restart interface eth1 is set to ACCEPT.

I assume there must be a different set of configuration files that are accessed upon reboot than those accessed upon firewalld restart.

Note that all CentoOS 7 machines (VM and hardware) in our data center have this same issue.

Anyone know where and what those files are?

Emmett

33 thoughts on - Firewalld

  • The saved rules are under /etc/firewalld/zones. The rules for the default zone should be the ones loaded. The default zone is defined in /etc/firewalld/firewalld.conf.

  • Rather than paraphrasing, could you show the specific rules, chains, or policies you’re talking about? A standard firewalld rule set has the INPUT policy set to ACCEPT, with a terminal REJECT rule. An INPUT_ZONES
    table will direct to an IN_public table, with log, deny, and accept rules.

    Typically, the only rule that references an interface is the one in INPUT_ZONES that “goto”s IN_public_allow. It is neither REJECT nor ACCEPT, so it’s really hard to guess what you’re seeing that you don’t expect to see.

  • Thanks, that’s a lot more clear. Weird, though. Does
    /etc/sysconfig/network-scripts/ifcfg-eth1 specify a “ZONE=”? Are you using the “network” or the “NetworkManager” service?

  • I never use NetworkManager except on portable machines. Can’t see the need.

    Here are the configuration files:

    NAME=”eth0″
    HWADDRR:54:00:76:0D:7F
    ONBOOT=yes UUID=”8ab7ac2c-c089-4f9f-bb65-1abb781fe912″
    IPV6INIT=no BOOTPROTO=none TYPE=Ethernet IPADDR

  • In that case, specify a ZONE in ifcfg-eth1.

    If you look at ifup-eth, you’ll see that firewall-cmd is called during interface configuration. If no zone is specified, the default is used.
    I believe that firewalld starts first, configures the firewall correctly, and then the “network” service starts later and sets both interfaces into the default zone.

    If you specify ZONE=trusted in ifcfg-eth1, then it’ll be placed into that zone.

  • Yesterday I noticed that I was not able to ping one of our development servers so I logged in via VNC and ran the Firewalld GUI.

    To my surprise, except for the interface definition for public and trusted zones, nothing seemed to be configured. That is, none of the services were checked off that we want open at the firewall. Also, this server is a gateway and masquerading and forwarding appears to be off as well.

    So it looks like the GUI is not correctly reading the firewalld configuration.

    I can find nothing in Google bout this.

    Emmett

  • Firewalld doesn’t read the iptables state of the system, it relies on its own representation of the desired configuration. You or another admin may have configured the iptables rules on that host using a service other than firewalld. For instance, you may have added rules to
    /etc/sysconfig/{iptables,ip6tables} and run the “iptables” service. In that case, firewalld would have no information about the rules that are present. Check there first, then decide if you want to continue supporting that configuration or migrate to firewalld.

  • These machines have only had firewalld configured. Currently firewalld version 0.3.9-14.el7 is installed, and in this particular case, the server is fully up to date. If I run iptables -nvL I see this for the first chain:

    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    766K 72M ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
    75 5514 ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
    79630 5463K INPUT_direct all — * * 0.0.0.0/0 0.0.0.0/0
    79630 5463K INPUT_ZONES_SOURCE all — * * 0.0.0.0/0 0.0.0.0/0
    79630 5463K INPUT_ZONES all — * * 0.0.0.0/0 0.0.0.0/0
    956 78983 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0
    2792 142K REJECT all — * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

    So firewalld was definitely used to generate the rules in iptables. And indeed systemd starts it upon reboot. It looks like only the GUI has a problem reading the configuration. Note that the GUI does show that firewalld is connected.

    There are other machines that have this same issue. Were there changes to config file locations, or permissions, as I know the GUI worked just find until just recently.

    Emmett

  • Got 7.3 installed Wednesday, things went so so.

    Been working on getting roundcubemail setup and firewalld is kicking my butt.

    I can’t figure out all these zones. I opened imap, imaps, pop3, pop3s, SMTP, smtps in zones internal, trusted and public.

    I still get connection refused.

    I telnet localhost 143, I get connection refused.

    What zone is used for the local network and what zone is used for outside access? Two days and can’t access mail.

    Is this a Redhat brain child? According to firewalld.org, only Redhat, CentOS and Fedora are using it.

    Not too happy

  • All traffic from localhost is allowed. No zone is involved.

    The zone for “outside” access depends on which interface receives the packet, and what zone you’ve put that interface in. I believe that defaults to “public.”

  • defaults to

    I’m telneting in from SSH on a machine on the local network, still getting connection refused.

    The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same services/ports opened in each zone).

    I may as well disable firewalld and let my router handle the firewall.

    I don’t plan to use my server as a workstation.

  • defaults to

    I’m telneting in from SSH on a machine on the local network, still getting connection refused.

    The zone apparently means something because an interface can only be on one. Moving it to a different zone results in the same error (same services/ports opened in each zone).

    I may as well disable firewalld and let my router handle the firewall.

    I don’t plan to use my server as a workstation.

    Have a read through this and then decide on if you want to use it or not.

    You can also switch to iptables-service and mask firewalld if you want the same behaviour as in C6.

    7.3 also has nftables as a tech preview, but I’ve not finished my article on that yet.

  • The “zones” are just labels and are used to create kernel iptables. Each zone has a default set of open and closed ports ranging from
    “trusted” which accepts all packets to “public” which has everything closed. You can modify the allowed ports and services on each zone at will.

    Some of the zones have “special” features – “block” rejects all packets, “drop” drops all packets, “external” has masquerading turned on and so on.

    If you have a single network, then that interface will, by default, be put in the “public” zone, so most ports will be closed. That’s fine, just leave it in that zone, it’s just a label/container.

    You can list the services open in the default zone by doing

    firewall-cmd –list-services

    or for ports not services

    firewall-cmd –list-ports

    or for a different zone

    firewall-cmd –zone=public –list-services

    You can also find out which zones your interface(s) is in with

    firewall-cmd –get-active-zones

    One of the gotchas with firewalld is that the changes are made in either the current running iptables *or* the stored rules, not both. So if you make a change to the running rule set, those changes won’t be kept the next time you restart firewalld. You can either use the ‘
    –permanent’ flag to set the stored rules (but it won’t affect the active rules) or the ‘–runtime-to-permanent’ flag to copy the current active rules to the stored ones.

    The bottom line is that firewalld is just another application that manipulates the kernel packet routing tables. Use something else if you prefer it – some of the system tools assume firewalld, but if you are aware of what’s happening it shouldn’t be an issue.

    If you are happy that there is nothing behind your firewall that could cause a problem then that’s an acceptable route.

    P.

  • Thanks,

    That’s a better explanation of things than I have read so far.

    Yes, initially I wasn’t adding the –permanent to the rules but I wasn’t doing really any reboots.

    I did a few –reloads so that may have gotten me.

    I have zoneminder, dns, and urbackup working. I can SSH and scp in from work but mail is being a pain.

    Thanks

  • firewalld isn’t the only thing that will prevent services from accessing the internet. I found that I needed to do a relabel before postfix could access DNS and I have seen other issues as well. Have you tried disabling the firewall to see if you can get connections to work? Then try to disable SElinux and see if that works.

    # netstat –inet -l -n

    Is the service listening on port 143?

    # systemctl stop firewalld

    Does it now work?

    # setenforce 0

    Does it now work?

  • Just a side note here, since EL7 removed net-tools from the default install (after all it has been deprecated for about a decade now) you probably should get used to providing advice using the iproute2 suite instead.

    In this case `ss -tlnp` to list all tcp ports in a listening state, showing the pid using the port and not resolving the ports to friendly names.

    For an example of why this is important think about using pacemaker or keepalived to manage IPs migrating between systems. They won’t be visible using ifconfig but only via ip as they aren’t exposed in the kernel structures that ifconfig uses –
    https://www.hogarthuk.com/?q=node/6

    Another example is when you have multiple interfaces and you have source policy routing (or similar advanced routing behaviour) that makes use of rules and multiple routing tables. The older route command is only capable of displaying the default main table, not the rest of the tables in use, but `ip route show table all` will give you all the routing tables in use on your system (even in a default install it’s a lot more than the route command shows) and ip rule gives you the rules in use, if any.

    On a similar note bridge-utils is also deprecated, though brctl is ingrained into many minds!

    https://fedoramagazine.org/build-network-bridge-fedora/

  • the firewall is more likely to give you connection timed out as it genereally drops rather than rejects the connectiosn.

    connection refused often means nothing is actually listening on that port, 143/tcp being IMAP. you sure the imap service is running?

  • Still un-resolved. Could be wrong but I think its firewalld preventing me from accessing mail with roundcube.

    I’m getting Connection to storage server failed. From roundcubemail log:

    [29-Jan-2017 16:45:05 -0500]: <4r5ccifn> IMAP Error: Login failed for tdukes from 192.168.1.102. AUTHENTICATE PLAIN: * BYE Internal error occurred. Refer to server log for more information. in
    /usr/share/roundcubemail/program/lib/Roundcube/rcube_imap.php on line 197
    (POST /?_task=login?_task=login&_action=login)

    There is absolutely nothing in the httpd logs.

    I telnet to localhost 143 or 993 and I can connect, telneting to 25 or 465, connection refused.

    Clearly, below, those services and ports are open as well as mysql.

    Ouput from: firewall-cmd –list-all-zones

    work
    target: default
    icmp-block-inversion: no
    interfaces:
    sources:
    services: dhcpv6-client SSH urbackup-server
    ports:
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    drop
    target: DROP
    icmp-block-inversion: no
    interfaces:
    sources:
    services:
    ports:
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    internal (active)
    target: default
    icmp-block-inversion: no
    interfaces: enp1s0 lo
    sources:
    services: dhcp dhcpv6 dhcpv6-client dns ftp http https imap imaps mdns mysql openvpn pop3 pop3s rsyncd samba samba-client SMTP SMTPs ssh transmission-client urbackup-server
    ports: 465/tcp 20000/tcp 25/tcp 10000/tcp
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    external
    target: default
    icmp-block-inversion: no
    interfaces:
    sources:
    services: SSH urbackup-server
    ports:
    protocols:
    masquerade: yes
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    trusted (active)
    target: ACCEPT
    icmp-block-inversion: no
    interfaces: virbr0
    sources:
    services: dhcp dhcpv6 dhcpv6-client dns ftp http https imap imaps mysql ntp openvpn pop3 pop3s rsyncd samba samba-client SMTP SMTPs ssh transmission-client urbackup-server
    ports: 465/tcp 20000/tcp 25/tcp 10000/tcp
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    home
    target: default
    icmp-block-inversion: no
    interfaces:
    sources:
    services: dhcpv6-client mdns samba-client ssh
    ports: 10000/tcp
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    dmz
    target: default
    icmp-block-inversion: no
    interfaces:
    sources:
    services: ssh
    ports:
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    public (active)
    target: default
    icmp-block-inversion: no
    interfaces: eno1
    sources:
    services: dhcp dhcpv6-client dns ftp http https imap imaps mysql pop3
    pop3s rsyncd samba samba-client SMTP SMTPs SSH transmission-client urbackup-server
    ports: 465/tcp 20000/tcp 25/tcp 10000/tcp
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    block
    target: %%REJECT%%
    icmp-block-inversion: no
    interfaces:
    sources:
    services:
    ports:
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    eno1 is on the public zone, lo is on the internal zone

    I can read mail with mutt and usermin.

    What am I missing?

    TIA

  • As I mentioned before: firewalld allows all traffic to localhost. If you’re getting connection refused, then those services aren’t running.

    As for dealing with login denied errors, you should be looking at the IMAP server’s logs, not the HTTP server’s.

  • as someone else already suggested, did you turn selinux off temporarily
    “setenforce 0” to see if it still fails?

    I’ve had several problems lately where that simple step revealed selinux as the cause, not firewall.

    Fred

  • you’re

    Here’s the excerpts from maillog:

    Jan 29 13:52:28 ts130 MailScanner[3941]: MailScanner Email Processor version
    5.0.3 starting… Jan 29 13:52:28 ts130 logger[3944]: MailScanner started Jan 29 13:52:28 ts130 MailScanner[3941]: Reading configuration file
    /etc/MailScanner/MailScanner.conf Jan 29 13:52:28 ts130 MailScanner[3941]: Reading configuration file
    /etc/MailScanner/conf.d/README
    Jan 29 13:52:28 ts130 MailScanner[3941]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:28 ts130 MailScanner[3941]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:28 ts130 MailScanner[3941]: Using SpamAssassin results cache Jan 29 13:52:28 ts130 MailScanner[3941]: Connected to SpamAssassin cache database Jan 29 13:52:28 ts130 MailScanner[3941]: Enabling SpamAssassin auto-whitelist functionality… Jan 29 13:52:33 ts130 MailScanner[4235]: MailScanner Email Processor version
    5.0.3 starting… Jan 29 13:52:33 ts130 MailScanner[4235]: Reading configuration file
    /etc/MailScanner/MailScanner.conf Jan 29 13:52:33 ts130 MailScanner[4235]: Reading configuration file
    /etc/MailScanner/conf.d/README
    Jan 29 13:52:33 ts130 MailScanner[4235]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:33 ts130 MailScanner[4235]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:33 ts130 MailScanner[4235]: Using SpamAssassin results cache Jan 29 13:52:33 ts130 MailScanner[4235]: Connected to SpamAssassin cache database Jan 29 13:52:33 ts130 MailScanner[4235]: Enabling SpamAssassin auto-whitelist functionality… Jan 29 13:52:38 ts130 MailScanner[4363]: MailScanner Email Processor version
    5.0.3 starting… Jan 29 13:52:38 ts130 MailScanner[4363]: Reading configuration file
    /etc/MailScanner/MailScanner.conf Jan 29 13:52:38 ts130 MailScanner[4363]: Reading configuration file
    /etc/MailScanner/conf.d/README
    Jan 29 13:52:38 ts130 MailScanner[4363]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:38 ts130 MailScanner[4363]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:38 ts130 MailScanner[4363]: Using SpamAssassin results cache Jan 29 13:52:38 ts130 MailScanner[4363]: Connected to SpamAssassin cache database Jan 29 13:52:38 ts130 MailScanner[4363]: Enabling SpamAssassin auto-whitelist functionality… Jan 29 13:52:43 ts130 MailScanner[4459]: MailScanner Email Processor version
    5.0.3 starting… Jan 29 13:52:43 ts130 MailScanner[4459]: Reading configuration file
    /etc/MailScanner/MailScanner.conf Jan 29 13:52:43 ts130 MailScanner[4459]: Reading configuration file
    /etc/MailScanner/conf.d/README
    Jan 29 13:52:43 ts130 MailScanner[4459]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:43 ts130 MailScanner[4459]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:43 ts130 MailScanner[4459]: Using SpamAssassin results cache Jan 29 13:52:43 ts130 MailScanner[4459]: Connected to SpamAssassin cache database Jan 29 13:52:43 ts130 MailScanner[4459]: Enabling SpamAssassin auto-whitelist functionality… Jan 29 13:52:48 ts130 MailScanner[4528]: MailScanner Email Processor version
    5.0.3 starting… Jan 29 13:52:48 ts130 MailScanner[4528]: Reading configuration file
    /etc/MailScanner/MailScanner.conf Jan 29 13:52:48 ts130 MailScanner[4528]: Reading configuration file
    /etc/MailScanner/conf.d/README
    Jan 29 13:52:48 ts130 MailScanner[4528]: Read 1501 hostnames from the phishing whitelist Jan 29 13:52:48 ts130 MailScanner[4528]: Read 12749 hostnames from the phishing blacklists Jan 29 13:52:48 ts130 MailScanner[4528]: Using SpamAssassin results cache Jan 29 13:52:48 ts130 MailScanner[4528]: Connected to SpamAssassin cache database Jan 29 13:52:48 ts130 MailScanner[4528]: Enabling SpamAssassin auto-whitelist functionality… Jan 29 13:53:03 ts130 MailScanner[4235]: Auto: Found virus scanners:
    clamavmodule Jan 29 13:53:03 ts130 MailScanner[3941]: Auto: Found virus scanners:
    clamavmodule Jan 29 13:53:05 ts130 MailScanner[4363]: Auto: Found virus scanners:
    clamavmodule Jan 29 13:53:05 ts130 MailScanner[4459]: Auto: Found virus scanners:
    clamavmodule Jan 29 13:53:11 ts130 MailScanner[4528]: Auto: Found virus scanners:
    clamavmodule Jan 29 13:53:17 ts130 MailScanner[4459]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4459]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4459]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[4235]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4235]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4235]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[4363]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4363]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[4363]: Using locktype = flock Jan 29 13:53:17 ts130 MailScanner[3941]: Connected to Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[3941]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:17 ts130 MailScanner[3941]: Using locktype = flock Jan 29 13:53:21 ts130 MailScanner[4528]: Connected to Processing Attempts Database Jan 29 13:53:21 ts130 MailScanner[4528]: Found 0 messages in the Processing Attempts Database Jan 29 13:53:21 ts130 MailScanner[4528]: Using locktype = flock

    Last login attempt from roundcube

    Jan 29 16:38:08 ts130 dovecot: imap-login: Login: user=, method=PLAIN, rip=::1, lip=::1, mpid 76, secured, session=
    Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: user tdukes:
    Initialization failed: Namespace ”: Mail storage autodetection failed with home=/home/tdukes Jan 29 16:38:08 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:44:47 ts130 dovecot: imap-login: Login: user=, method=PLAIN, rip=::1, lip=::1, mpid”82, secured, session=
    Jan 29 16:44:47 ts130 dovecot: imap(tdukes): Error: user tdukes:
    Initialization failed: Namespace ”: Mail storage autodetection failed with home=/home/tdukes Jan 29 16:44:47 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:44:56 ts130 dovecot: imap-login: Login: user=, method=PLAIN, rip=::1, lip=::1, mpid”90, secured, session=
    Jan 29 16:44:56 ts130 dovecot: imap(tdukes): Error: user tdukes:
    Initialization failed: Namespace ”: Mail storage autodetection failed with home=/home/tdukes Jan 29 16:44:56 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information. Jan 29 16:45:05 ts130 dovecot: imap-login: Login: user=, method=PLAIN, rip=::1, lip=::1, mpid#01, secured, session=
    Jan 29 16:45:05 ts130 dovecot: imap(tdukes): Error: user tdukes:
    Initialization failed: Namespace ”: Mail storage autodetection failed with home=/home/tdukes Jan 29 16:45:05 ts130 dovecot: imap(tdukes): Error: Invalid user settings. Refer to server log for more information.

    ???

    I have no clue

  • It’s a dovecot configuration error. The login has clearly worked, so stop fussing with the firewall.

    You need to look in /etc/dovecot/conf.d/10-mail.conf and set
    ‘mail_location’ to where the user’s email is stored. If you are using Maildir then it will probably be

    mail_location =  maildir:~/Maildir

    if mbox, then probably

    mail_location = mbox:~/mail:INBOX=/var/mail/%u

    but adjust the paths to where things are actually stored.

    You will, obviously, have to set your MTA to deliver the mail to the correct location and in the correct format as well.

    P.

  • Thank you!!!!!!

    Its working now! Never had to do that before, everything always worked out of the box.

    # Location for users’ mailboxes. The default is empty, which means that Dovecot
    # tries to find the mailboxes automatically. This won’t work if the user
    # doesn’t yet have any mail, so you should explicitly tell Dovecot the full
    # location.
    #
    # If you’re using mbox, giving a path to the INBOX file (eg. /var/mail/%u)
    # isn’t enough. You’ll also need to tell Dovecot where the other mailboxes are
    # kept. This is called the “root mail directory”, and it must be the first
    # path given in the mail_location setting.
    #
    # There are a few special variables you can use, eg.:
    #
    # %u – username
    # %n – user part in user@domain, same as %u if there’s no domain
    # %d – domain part in user@domain, empty if there’s no domain
    # %h – home directory
    #
    # See doc/wiki/Variables.txt for full list. Some examples:
    #
    # mail_location = maildir:~/Maildir
    # mail_location = mbox:~/mail:INBOX=/var/mail/%u
    # mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
    #
    #
    #
    mail_location = maildir:~/Maildir <<<<<------ this!! Really appreciate the help!!

  • I have two VMs, both with firewalld installed. One on machine It this in the IN_public chain:

    Chain IN_public (2 references)
    pkts bytes target prot opt in out source destination
    81 3423 IN_public_log all — * * 0.0.0.0/0 0.0.0.0/0
    81 3423 IN_public_deny all — * * 0.0.0.0/0 0.0.0.0/0
    81 3423 IN_public_allow all — * * 0.0.0.0/0 0.0.0.0/0
    79 3335 REJECT all — * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

    On the other I see:

    Chain IN_public (2 references)
    pkts bytes target prot opt in out source destination
    101 4232 IN_public_log all — * * 0.0.0.0/0 0.0.0.0/0
    101 4232 IN_public_deny all — * * 0.0.0.0/0 0.0.0.0/0
    101 4232 IN_public_allow all — * * 0.0.0.0/0 0.0.0.0/0
    1 84 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0

    As might be expected, pinging the first VM fails. That is the ping is rejected with:

    [emmett@ws1 ~]$ ping 96.92.106.4
    PING 96.92.106.4 (96.92.106.4) 56(84) bytes of data. From 96.92.106.4 icmp_seq=1 Destination Host Prohibited From 96.92.106.4 icmp_seq=2 Destination Host Prohibited

    And pinging the second works as expected.

    I’ve searche the firewalld configuration files in /usr/lib/firewalld and /etc/firewalld and can find no reference to any icmp rule. The two machines were cloned originally from the same VM. Why are they different?

    How can I remove the reject-with icmp rule using firewalld. I can remove it using “iptables -D [IN_public | FWDO_public | FWDI_public ] 4” and I can then ping that machine. But of course the rule is returned whenever firewalld is restarted.

    Emmett

  • That was the clue I needed. On the first machine:

    target: %%REJECT%%
    icmp-block-inversion: no
    interfaces: eth0
    sources:
    services: ftp_passiv http SSH https ftps
    ports:
    protocols:
    masquerade: no
    forward-ports:
    source-ports:
    icmp-blocks:
    rich rules:

    And the second:

    target: default
    icmp-block-inversion: no
    interfaces: eth0
    sources:
    services: ftp_passiv http SSH https ftps
    ports:
    protocols:
    masquerade: no
    forward-ports:
    source-ports:
    icmp-blocks:
    rich rules:

    Changing the target to “default” instead of “%%REJECT%%” by setting the zone policy to default in firewalld-config fixed it. NOt sure whay that would be, but I am happy with the result.

    Thanks!

  • I’m fighting a firewalld mystery myself, mostly a result of not really understanding the philosophy of the thing and trying to sleuth it out by black boxing it. But fortunately this is open source, so I’m also grepping the firewalld sources to figure out where these mysteries are coming from:

    https://github.com/firewalld/firewalld

    firewalld creates a lot of iptables/netfilter rules, which makes it hard to follow what’s going on. I may cobble together a netfilter visualization tool that will take iptables-save and convert it into a graph in GraphViz dot file format to try to figure out what’s going on. I found a Python program that seems like a partial attempt to create this, but it seems incomplete. The dot files lack connections between the chains so I just get a bunch of floating bubbles with chain names. The program assumes that uppercase chain names are terminal nodes, and firewalld loves to create chains with uppercase names.

    https://github.com/larsks/dot-iptables