RHEL7: How to get started with Firewalld.

Share this link

Note: This is an RHCSA 7 exam objective and an RHCE 7 exam objective.

Presentation

Firewalld is the new userland interface in RHEL 7. It replaces the iptables interface and connects to the netfilter kernel code. It mainly improves the security rules management by allowing configuration changes without stopping the current connections.

To know if Firewalld is running, type:

# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Tue 2014-06-17 11:14:49 CEST; 5 days ago
   ...

or alternatively:

# firewall-cmd --state
running

Note: If Firewalld is not running, the command displays not running.

If you’ve got several network interfaces in IPv4, you will have to activate ip forwarding.
To do that, paste the following line into the /etc/sysctl.conf file:

net.ipv4.ip_forward=1

Then, activate the configuration:

# sysctl -p

Note: If you interested in kernel parameter configuration, there is a tutorial about the sysctl command.

Although Firewalld is the RHEL 7 way to deal with firewalls and provides many improvements, iptables can still be used (but both shouldn’t run at the same time).

You can also look at the iptables rules created by Firewalld with the iptables-save command.

Zone Management

Also, a new concept of zone appears: all network interfaces can be located in the same default zone or divided into different ones according to the levels of trust defined. In the latter case, this allows to restrict traffic based on origin zone (read this article from lwn.net for more details).
Note: Without any configuration, everything is done by default in the public zone. If you’ve got more than one network interface or use sources (see Source management section below), you will be able to restrict traffic between zones.

To get the default zone, type:

# firewall-cmd --get-default-zone
public

To get the list of zones where you’ve got network interfaces or sources assigned to, type:

# firewall-cmd --get-active-zones
public
  interfaces: eth0

Note: You can have more than one active zone at a time.

To get the list of all the available zones, type:

# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

To change the default zone to home permanently, type:

# firewall-cmd --set-default-zone=home
success

Note: This information is stored in the /etc/firewalld/firewalld.conf file.

Network interfaces can be assigned to a zone in a permanent way.
To permanently assign the eth0 network interface to the internal zone (a file called internal.xml is created in the /etc/firewalld/zones directory), type:

# firewall-cmd --permanent --zone=internal --change-interface=eth0
success
# nmcli con show | grep eth0
System eth0  4de55c95-2368-429b-be65-8f7b1a357e3f  802-3-ethernet  eth0
# nmcli con mod "System eth0" connection.zone internal
# nmcli con up "System eth0"
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)

Note1: This operation can also be done by editing the /etc/sysconfig/network-scripts/ifcfg-eth0 file and add ZONE=internal followed by # nmcli con reload . It seems that with RHEL 7.5, the use of ZONE in ifcfg-* files no longer works (source).
Note2: More information about the nmcli command is available at the page dedicated to nmcli or at the IPV4 configuration page.
Note3: The RHEL 7.3 release improves the way Firewalld handles zones (v0.3.9 -> v0.4.3.2: BZ#1302802).

To know which zone is associated with the eth0 interface, type:

# firewall-cmd --get-zone-of-interface=eth0
internal

To get the permanent configuration of the public zone, type:

# firewall-cmd --permanent --zone=public --list-all
public (default, active)
  interfaces: eth0
  sources: 
  services: dhcpv6-client ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 

It is also possible to create new zones. To create a new zone (here test), type:

# firewall-cmd --permanent --new-zone=test
success
# firewall-cmd --reload
success

Note: Only permanent zones can be created.

Source Management

A zone can be bound to a network interface (see above) and/or to a network addressing (called here a source).
Any network packet entering in the network stack is associated with a zone.
The association is done according to the following pattern:
– is the packet coming from a source already bound to a zone? (if yes, it is associated with this zone),
– if not, is the packet coming from a network interface already bound to a zone? (if yes, it is associated with this zone),
– if not, the packet is associated with the default zone.

This way, multiple zones can be defined even on a server with only one network interface!

Caution: To get this feature, Firewalld relies on NetworkManager (see reference). This means that if you plan to stop NetworkManager for any reason (for example when building a KVM host), you will have to stop Firewalld and use Iptables instead!
Note: With the RHEL 7.3 release, Firewalld robustness has been improved in regard to NetworkManager (see details here).

To add a source (here 192.168.2.0/24) to a zone (here trusted) permanently, type:

# firewall-cmd --permanent --zone=trusted --add-source=192.168.2.0/24
success
# firewall-cmd --reload
success

Note1: Use the –remove-source option to delete a previous assigned source.
Note2: Use the –change-source option to move the source to the new specified zone.
Note3: If you want to temporarily add a source to a zone, don’t use the –permanent option and don’t reload the firewall configuration. If you reload the firewall configuration, this will cancel all the operation.
Note4: You can also make some changes and when you like your new configuration, have it become your permanent configuration with the firewall-cmd –runtime-to-permanent command.

With the RHEL 7.3 release, you can add a source based on a MAC address (here 00:11:22:33:44:55) to a zone (here trusted) permanently:

firewall-cmd --permanent --zone=trusted --add-source=00:11:22:33:44:55
success
# firewall-cmd --reload
success

With the RHEL 7.3 release, you can create an ipset (a set of IP addresses or networks, see below) and add a source based on it:

# firewall-cmd --permanent --new-ipset=iplist --type=hash:ip
success
# firewall-cmd --reload
success
# firewall-cmd --ipset=iplist --add-entry=192.168.1.11
success
# firewall-cmd --ipset=iplist --add-entry=192.168.1.12
success
# firewall-cmd --permanent--zone=trusted --add-source=ipset:iplist
success
# firewall-cmd --reload
success

To get the list of the sources currently bound to a zone (here trusted), type:

# firewall-cmd --permanent --zone=trusted --list-sources
192.168.2.0/24 00:11:22:33:44:55 ipset:iplist

Note: Remove the –permanent option if you only want to display temporary settings.

To keep track of your configuration (active zones are zones that have a binding to an interface or source), type:

# firewall-cmd --get-active-zones
public
  interfaces: eth0
trusted
  sources: 192.168.2.0/24

As an exemple of source management, let’s assume you want to only allow connections to your server from a specific IP address (here 1.2.3.4/32).

# firewall-cmd --zone=internal --add-service=ssh --permanent
success
# firewall-cmd --zone=internal --add-source=1.2.3.4/32 --permanent
success
# firewall-cmd --zone=public --remove-service=ssh --permanent
success
# firewall-cmd --reload
success

Source: Serverfault website.

With RHEL 7.3, a new option called –info-zone is available.
To get the detail of a zone called public, type:

# firewall-cmd --info-zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:

Note: You can also add the –permanent option.

Service Management

After assigning each network interface to a zone, it is now possible to add services to each zone.
To allow the http service permanently in the internal zone, type:

# firewall-cmd --permanent --zone=internal --add-service=http
success
# firewall-cmd --reload
success

Note1: Type –remove-service=http to deny the http service.
Note2: The firewall-cmd –reload command is necessary to activate the change. Contrary to the –complete-reload option, current connections are not stopped.
Note3: If you only want to temporarily add a service, don’t use the –permanent option and don’t reload the firewall configuration. If you reload the firewall configuration, you cancel all the operation.

If you want to temporary add several services (here http, https, and dns) at the same time in the internal zone, type:

# firewall-cmd --zone=internal --add-service={http,https,dns}
success

To get the list of services in the default zone, type:

# firewall-cmd --list-services
dhcpv6-client ssh

Note: To get the list of the services in a particular zone, add the –zone= option.

With RHEL 7.3, a new option called –info-service is available.
To get some information about the ftp service, type:

# firewall-cmd --info-service=ftp
ftp
  ports: 21/tcp
  protocols:
  source-ports:
  modules: nf_conntrack_ftp
  destination:

Note: You can also add the –permanent option.

Firewall Services Configuration

With the Firewalld package, the firewall configuration of the main services (ftp, httpd, etc) comes in the /usr/lib/firewalld/services directory. But it is still possible to add new ones in the /etc/firewalld/services directory. Also, if files exist at both locations for the same service, the file in the /etc/firewalld/services directory takes precedence.

For example, it is the case of the HAProxy service. There is no firewall configuration associated.
Create the /etc/firewalld/services/haproxy.xml and paste the following lines:

<?xml version="1.0" encoding="utf-8"?>
<service>
 <short>HAProxy</short>
 <description>HAProxy load-balancer</description>
 <port protocol="tcp" port="80"/>
</service>

Note: You can use the firewall-cmd –permanent –new-service=haproxy command to quickly create a configuration file skeleton.

Assign the correct SELinux context and file permissions to the haproxy.xml file:

# cd /etc/firewalld/services
# restorecon haproxy.xml
# chmod 640 haproxy.xml

Add the HAProxy service to the default zone permanently and reload the firewall configuration:

# firewall-cmd --permanent --add-service=haproxy
success
# firewall-cmd --reload
success

Note: According to Bert Van Vreckem, it is possible to go quicker by using the command history (see details here):

# firewall-cmd --add-service=haproxy
success
# firewall-cmd --add-service=haproxy --permanent
success

In RHEL 7.0 (Firewalld v0.3.9.7), there were 47 firewall services configured: amanda-client, bacula, bacula-client, dhcp, dhcpv6, dhcpv6-client, dns, ftp, high-availability, http, https, imaps, ipp, ipp-client, ipsec, kerberos, kpasswd, ldap, ldaps, libvirt, libvirt-tls, mdns, mountd, ms-wbt, mysql, nfs, ntp, openvpn, pmcd, pmproxy, pmwebapi, pmwebapis, pop3s, postgresql, proxy-dhcp, radius, rpc-bind, samba, samba-client, smtp, ssh, telnet, tftp, tftp-client, transmission-client, vnc-server, wbem-https.
In RHEL 7.1 (Firewalld v0.3.9.11), the RH-Satellite-6 service was added.
In RHEL 7.2 (Firewalld v0.3.9.14), the freeipa-ldaps, freeipa-ldap, freeipa-replication, iscsi-target, rsyncd and vdsm services were added.
In RHEL 7.3 (Firewalld v0.4.3.2), the amanda-k5-client, ceph, ceph-mon, docker-registry, dropbox-lansync, imap, kadmin, mosh, pop3, privoxy, ptp, pulseaudio, puppetmaster, sane, smtps, snmp, snmptrap, squid, synergy, syslog, syslog-tls, tinc, tor-socks, xmpp-bosh, xmpp-client, xmpp-local and xmpp-server services have been added for a total of 81 services.

Port Management

Port management follows the same model as service management.

To allow the 443/tcp port temporarily in the internal zone, type:

# firewall-cmd --zone=internal --add-port=443/tcp
success

Note1: To make the configuration permanent, add the –permanent option and reload the firewall configuration.
Note2: Type –remove-port=443/tcp to deny the port.

To get the list of ports currently open in the internal zone, type:

# firewall-cmd --zone=internal --list-ports
443/tcp

Note: To only get the list of ports permanently open, add the –permanent option. Here, you will not get anything.

Rich Rules

As the syntax used by the rich rules are somehow difficult to remember, keep in mind the man firewalld.richlanguage command and the Example section at the end.

Here is the format of a rich rule:

# firewall-cmd --add-rich-rule 'rule ...'

To allow all connections from 192.168.2.2, type:

# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="192.168.2.2" log accept'

Note1: The log option writes coming packets into the /var/log/messages file.
Note2: Use the –remove-rich-rule option instead of the –add-rich-rule option if you want to delete an already existing rule.

To list the rich rules set in the default zone, type:

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="192.168.2.2" log accept

Direct Rules

It is still possible to set specific rules by using the direct mode (here to open the tcp port 9000) that by-passes the Firewalld interface:

# firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 9000 -j ACCEPT
success

Note1: This example has been borrowed from Khosro Taraghi’s blog.
Note2: Use the same command with the –remove-rule instead of –add-rule to delete the rule.
Note3: The configuration is temporary except if you add the –permanent option just after the –direct option.
Note4: It is not necessary to reload the firewall configuration, all commands are directly activated.

To display all the direct rules added, type:

# firewall-cmd --direct --get-all-rules

Note1: For information, the configuration is written into the /etc/firewalld/direct.xml file.
Note2: Direct rules are not part of the RHCSA/RHCE exam objectives.

IP Set Management

With the RHEL 7.3 comes the ability to create ipsets. An ipset is a set of IP addresses or networks. The different categories belong to hash:ip or hash:net.

To create a permanent IPv4 ipset containing two IP addresses and drop packets coming from these addresses, type:

# firewall-cmd --permanent --new-ipset=blacklist --type=hash:ip
success
# firewall-cmd --reload
success
# firewall-cmd --ipset=blacklist --add-entry=192.168.1.11
success
# firewall-cmd --ipset=blacklist --add-entry=192.168.1.12
success
# firewall-cmd --add-rich-rule='rule source ipset=blacklist drop'
success

Note: Add –option=family=inet6 to create an IPv6 ipset.

To get the content of the blacklist ipset, type:

# firewall-cmd --info-ipset=blacklist
blacklist
type: hash:ip
options:
entries: 192.168.1.11 192.168.1.12

To remove the 192.168.1.12 entry from the blacklist ipset, type:

# firewall-cmd --ipset=blacklist --remove-entry=192.168.1.12
success
# firewall-cmd --ipset=blacklist --get-entries
192.168.1.11

To create a permanent IPv4 ipset containing two networks, type:

# firewall-cmd --permanent --new-ipset=netlist
success
# firewall-cmd --reload
success
# firewall-cmd --ipset=netlist --add-entry=192.168.1.0/24
success
# firewall-cmd --ipset=netlist --add-entry=192.168.2.0/24
success
# firewall-cmd --info-ipset=netlist
netlist
 type: hash:net
 options: 
 entries: 192.168.1.0/24 192.168.2.0/24

To remove the netlist ipset, type: 
# firewall-cmd --permanent --delete-ipset=netlist
success
# firewall-cmd --reload
success
# firewall-cmd --get-ipsets
blacklist

It is also possible to download the content of an ipset from a file (--add-entries-from-file=file option) or store it with the name ipset in the /etc/firewalld/ipsets/ipset.xml
or /usr/lib/firewalld/ipsets/ipset.xml files according to the following format:
<?xml version="1.0" encoding="utf-8"?>
<ipset type="hash:ip">
  <short>My Ipset</short>
  <description>description</description>
  <entry>192.168.1.11</entry>
  <entry>192.168.1.12</entry>
</ipset>

To load this ipset, type:

# firewall-cmd --reload

Masquerading

If your firewall is your network gateway and you don’t want everybody to know your internal addresses, you can set up two zones, one called internal, the other external, and configure masquerading on the external zone. This way, all packets will get your firewall ip address as source address.

To set up masquerading on the external zone in a temporary way, type:

# firewall-cmd --zone=external --add-masquerade
success

Note1: To remove masquerading, use the –remove-masquerade option.
Note2: To know if masquerading is active in a zone, use the –query-masquerade option.
Note3: To get the configuration permanent, add the –permanent option and reload the firewall configuration.

Port Forwarding

Port forwarding is a way to forward inbound network traffic for a specific port to another internal address or an alternative port.

Caution: Port forwarding requires masquerading (source). This point is a classical mistake made during the RHCE exam.

So, you need to enable masquerading before anything else:

# firewall-cmd --zone=external --add-masquerade
success

If you want all packets intended for port 22 to be now forwarded to port tcp 3753 temporarily, type:

# firewall-cmd --zone=external --add-forward-port=port=22:proto=tcp:toport=3753
success

Note1: To remove port forwarding, use the –remove-forward-port option.
Note2: To know if port forwarding is active in a zone, use the –query-forward-port option.
Note3: If you want to make the configuration permanent, add the –permanent option and reload the firewall configuration.

Also, if you want to define the destination ip address, this time in a permanent way, type:

# firewall-cmd --permanent --zone=external --add-forward-port=port=22:proto=tcp:toport=3753:toaddr=10.0.0.1
success
# firewall-cmd --reload
success

Special Modules

Sometimes it is required to download specific modules. Instead of using a rc.local file, it is better to notify Firewalld through the /etc/modules-load.d directory.
In this example we want to add the ip_nat_ftp and ip_conntrack_ftp modules to follow ftp connections.
We only need to choose a filename (here firewall_ftp.conf) and type these instructions:

# echo ip_nat_ftp > /etc/modules-load.d/firewall_ftp.conf
# echo ip_conntrack_ftp >> /etc/modules-load.d/firewall_ftp.conf

Source: StackExchange website.

Offline Configuration

In some cases (installations through Anaconda or Kickstart for example), you need to set up firewall rules when Firewalld is not running. The firewall-offline-cmd command has just been created for this purpose.
For instance, to open the tcp port 22, you would type in the /etc/sysconfig/iptables file:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Instead, you can now execute the following command:

# firewall-offline-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Configuration Backup

To store the current configuration into files, type:

# iptables -S > firewalld_rules_ipv4
# ip6tables -S > firewalld_rules_ipv6

Debugging Tips

To better understand how Firewalld works, assign the ‘–debug’ value to the FIREWALLD_ARGS variable in the /etc/sysconfig/firewalld file:

# firewalld command line args
# possile values: --debug
FIREWALLD_ARGS='--debug'

Restart the Firewalld daemon:

# systemctl restart firewalld

Note: Messages will be written into the /var/log/firewalld file.

Also, with the RHEL 7.3 release comes the LogDenied directive in the /etc/firewalld/firewalld.conf file.
This directive adds logging rules right before reject and drop rules in the INPUT, FORWARD and OUTPUT chains for the default rules and also final reject and drop rules in zones.
Possible values are: all, unicast, broadcast, multicast and off (value by default).

Reload the Firewalld configuration:

# firewall-cmd --reload

Note: Messages will be written into the /var/log/messages file. If you also want messages to be written in a file called /var/log/custom.log, edit the /etc/rsyslog.conf file, add the line kern.warning /var/log/custom.log and restart the rsyslog configuration with # systemctl restart rsyslog

Additional Resources

In addition, you can:

Sources: RHEL7 Security Guide, wiki Fedora project.

Test yourself!

Well, it`s time to write a common app press here for information transfer essay.

1 Star2 Stars3 Stars4 Stars5 Stars (8 votes, average: 5.00 out of 5)
Loading...
79 comments on “RHEL7: How to get started with Firewalld.
  1. algorisms says:

    I started studying with RHEL 6 in April and switched over to 7 – As a result, I spent a lot of time honing iptables skills only to have firewalld take over (similar to sysvinit and systemd).

    I honestly prefer iptables as I am much more comfortable with it on the fly and the exam requirement states that you can still use iptables to fulfill any firewall requirements. Therefore, I think it might be helpful to some to show how to disable firewalld in favor of iptables.

    > systemctl disable firewalld
    > systemctl stop firewalld
    > yum -y install iptables-services
    > touch /etc/sysconfig/iptables
    > touch /etc/sysconfig/iptables6
    > systemctl start iptables
    > systemctl start ip6tables
    > systemctl enable iptables
    > systemctl enable ip6tables

    This will make it so that iptables is the preferred firewall service. You can then add firewall rules to /etc/sysconfig/iptables manually or use iptables -a [RULE YOU WANT] to append a rule to the chain you specify.

    Also, in learning firewall-cmd, it helped me to visualize the concepts of zoning better by first using the gui tool firewall-config (Applications | Sundry | Firewall) and then going back and learning the command line equivalents.

  2. ike says:

    Okay I have a few questions. They are as follows:
    1: Has red Hat cancelled RHCE 6 and only has RHCE7 or can on still take RHCE6 for now?
    2: I also prefer iptables but funny enough the manually configured iptables information did not persist reboot but I guess I may have to use system-config-firewall to make my modifications.

    I look forward to your response.

    Thanks in advance.

    • CertDepot says:

      Concerning RHCE6, according to Red Hat training department (see the comment associated with my last post “RHCSA & RHCE 6 last call”), you could take the exam in its kiosk version until Feb 28, 2016 if you purchase the vouncher before Feb 28, 2015.
      Concerning the iptables information, you should be able to persist your modifications whatever the way (manual/automatic, gui/cli).

  3. mellowjoni says:

    I don’t understand the relationship between iptables and firewalld. They seem to reference each other, but are two different firewalls, each with their own config files. Can you explain how the two are related, and how to remove iptables completely and work solely with firewalld?

    • CertDepot says:

      The iptables and firewalld services use the iptables userland component that talks to the netfilter kernel component.
      The iptables and firewalld services are mutually exclusive, they can’t run at the same time.
      The iptables service is a pseudo service: it relies on the /etc/sysconfig/iptables file to set up the firewall configuration but doesn’t run permanently.
      To remove the iptables service, you can use the instructions given for disabling the firewalld service (http://www.certdepot.net/rhel7-disable-firewalld-use-iptables/) and apply opposite commands (enable -> disable, disable -> enable, start -> stop, stop -> start).

  4. jerky_rs says:

    Personally i think firewalld is overally complicated for most server environments, it is probably more useful for graphical users. Setting up a chain for a device (or assigning a zone to an interface in firewalld) is fairly simple in iptables directly, most servers have a single interface(or bonded single) so really the usercase is small. The addition of rich rules appears more complex then one directly in iptables. Not really sure what other Administrators do but I always insert iptables and save, this does not require a reload of iptables like they make you think is an advantage with firewalld (but then again I have never used graphical ui to do iptables). Do people really run servers in graphical?

    I don’t think unfortunately you can disable firewalld for RHEL7 RHCE as it is listed specifically in the objectives. So I guess learn to love it and don’t take RHCE until you are comfortable with it.

    • CertDepot says:

      The RHCSA objective about firewalling is pretty clear: Configure firewall settings using firewall-config, firewall-cmd, or iptables. If you don’t like Firewalld, Red Hat allows you to use Iptables and you can perfectly disable Firewalld.

  5. jerky_rs says:

    For the RHCE exam it is however specifically listed as an objective.

    “Use firewalld and associated mechanisms such as rich rules, zones and custom rules, to implement packet filtering and configure network address translation (NAT)”

    You may very well be able to disable it in RHCSA exam but then they probably want you to do something far simpler with it so probably not much point.

  6. Shikaz says:

    There is something which really confuses me, when doing a port forward like the command below you mentioned:

    # firewall-cmd –zone=external –add-forward-port=port=22:proto=tcp:toport=3753

    I know that I have to use the –add-masquerade, but do I need also to do the sysctl.conf and add the net.ipv4.ip_forward=1 or in which case I do this?

    • CertDepot says:

      From what I understand (I didn’t test it), if you don’t specify the toaddr=10.0.0.1 part, you are doing a port forwarding to the localhost, so you don’t need to set up ip_forwarding=1.
      ip_forwarding=1 is needed when you allow a packet coming from one network interface to go through another network interface, not when it’s a local port redirection.
      On the other hand, when you add the toaddr=10.0.0.1 part, it’s clear that you need to set up ip_forwarding=1.

  7. salvador says:

    Under “Port management” you ran “–add-port” temporarily. You should remove the “–reload”, otherwise “–remove-port” fails.

  8. timlee says:

    Can direct rules be added and seen on the firewall GUI?

  9. alamahant says:

    I am trying to use a spare router as a gateway for the internal zone.No internet access just to create an intranet of all my servers so as to practice then port forwarding between the internal zone and the public zone..Would you please post a link on how to do that..
    Also for some unexplained reason firewalld keeps assigning all my interfaces to the default zone.I assign them to other zones (–remove-interface and then –add-interface permanent etc and –reload)and although it is ok after a reboot they are all again stacked together in the default zone..I am furious beyond words….:)
    Thanks a lot…
    Your site is like nectar from Heaven 🙂

    • CertDepot says:

      Depending on the RHEL/CentOS 7 version that you used, there are several known bugs about zones in Firewalld (1239326, 1273888, etc). Don’t give up!

    • soulbrat says:

      Hi!

      Interfaces will always revert to the default zone if they do not have an alternative zone defined within their configuration. Just add in
      /etc/sysconfig/network-scripts/ifcfg-eth0 “zone=internal”

      after that:

      systemctl restart network.service
      systemctl restart firewalld.service

      and zone internal will be active with interface eth0

      • CertDepot says:

        Zone management is still a work in progress in Firewalld. Thanks.

      • tron says:

        I would say that the RedHat way should be to both place the interface in the given zone using firewall-cmd AND set the zone in the connection by using nmcli connection.zone.
        ifup scripts reset the if zone no matter what you set in the firewall config. Ugly state of affairs.

        BTW, I was bitten by the default ACCEPT target of the trusted zone. You don’t need to add services to trusted (no brainer) but some port forwarding does not work either there. Case in point, I had httpd listening on both 80 and 82, and added a port forward from port 80 to 82 in trusted. Expecting to go to 82 when client requested 80… no, it went to 80. On other zones this works.

  10. rogerhughs says:

    Maybe it’s right under my nose and I just don’t see it. What are the equivalent firewalld CLI commands to list the firewall rules?

    Something like iptables -L.

  11. jey says:

    Can somebody help in case they know ? I’m unable to implement 1) and 3) rules using rich-rules and zones. Think you need to use direct rules

    Create a permanent rich rule configuration in the DMZ that matches the following requirements:
    1) All packets coming in from the 10.0.1.0/24 network should be blocked.
    2) All packets that are addressed to the SSH services should be logged with a maximum of two packets per minute. The messages should be logged with the “debug” log level, and the prefix “SSH:“.
    3) If packets are coming from the host with IP address 10.0.1.1 and are addressed to port 80 or 22, they should be accepted.

  12. aussie4beer says:

    I’m configuring firewalld for a project, where NetworkManager is disabled for our standard RHEL7/CentOS7 build, and nearly followed your advice to disable firewalld and migrate to iptables:

    “Caution: To get this feature, Firewalld relies on NetworkManager (see reference). This means that if you plan to stop NetworkManager for any reason (for example when building a KVM host), you will have to stop Firewalld and use Iptables instead!”

    The RHEL7 reference actually advises to use the –permanent –add-interface option:

    “IMPORTANT
    The –permanent –add-interface option is supposed to be used only for interfaces that are not managed by the NetworkManager utility. This is because NetworkManager, or the legacy network service, adds interfaces into zones automatically according to the ZONE= directive in the ifcfg interface configuration file. See the Red Hat Enterprise Linux 7 Networking Guide for information on NetworkManager and working with ifcfg files.”

    Otherwise, this is a great reference, thanks!

    • CertDepot says:

      I was not aware of this. Red Hat documentation regularly receives updates and the NetworkManager component evolves too. It is difficult to follow everything.
      I personally find the writing not very clear. After reading it several times, which shouldn’t normally be necessary, I understand a specific role of the –add-interface option. But there is currently nothing about this supposed link between the –add-interface option and the NetworkManager component in the firewall-cmd man page.
      Concerning the ZONE directive, it is one of the weakest features of Firewalld. Zones are supposed to be central to Firewalld and I haven’t found any firewall-cmd command to set them! You have to execute a NetworkManager command or write it directly into an ifcfg file.
      Let me know if what you try to do, using Firewalld without NetworkManager, works as you expect because this combination seems weird. Also, it is almost official that deactivate NetworkManager won’t be possible in the next main RHEL release.

      • redhat0329 says:

        Hi CertDepot,

        Do we need to be expert in firewall configuration on the exam? Since I’m new to RHEL I only know the basics config like add services, port, zone, etc. But with regards to port forwarding and masquerading as of this writing I’m still trying to get the concept.

        • CertDepot says:

          Port forwarding and masquerading are not very complicated concepts.
          Port forwarding consists in listening on a port and redirecting on another one.
          Masquerading involves a server used as a gateway with NAT (Network Address Translation).

          • redhat0329 says:

            Thanks CertDepot, Is there a way I cannot be concerned about this “net.ipv4.ip_forward=1”?

            I might forget this one. I don’t see any examples of this on the sysctl manual page. Do you have any idea where I can find examples? Thanks

          • CertDepot says:

            This is pretty simple. Each time you want to take packets from one interface and put them on another interface (act like a router), you need to set up IP Forwarding with net.ipv4.ip_forward=1 in the /etc/sysctl.conf file.

          • redhat0329 says:

            Thanks CertDepot.

          • redhat0329 says:

            Hi CertDepot,

            I’ve tried to concatenate this file
            # cat /proc/sys/net/ipv4/ip_forward

            Is it related to net.ipv4.ip_forward=1? Can I use this also instead of adding net.ipv4.ip_forward=1 on /etc/sysctl.conf file?

          • CertDepot says:

            The answer is there.

          • redhat0329 says:

            Thanks CertDepot!

  13. redhat0329 says:

    command ‘sysctl -a |grep forward’ can give you information if ip forwarding is enabled or not. 🙂

  14. Lisenet says:

    I’ve got a question about routing with firewalld. I managed to get routing working between two network interfaces, eth0 and eth1, by using direct (–direct)rules.

    However, I read that direct options should be used only as a last resort when it’s not possible to use for example –add-rich-rule=’rule’.

    Does anyone know a way of configuring routing between eth0 and eth1 interfaces with rich rules?

    For example, the direct rule I have to allow VMs on a dmz (eth1) to access public network (eth0) on SSH port:

    # firewall-cmd –direct -add-rule ipv4 filter FORWARD 0 -i eth1 -o eth0 -p tcp –dport 22 -j ACCEPT

    How would one do this with rich rules? I read the man pages for richlanguage, not much of a help.

    • Lisenet says:

      It turns out that I only need to enable masquerading on the public interface, and enable ip_forward. No other config is required to make routing work basically.

  15. krisp1506@gmail.com says:

    Hello CertDepot, How do I query default FORWARD policy using firewall-cmd?

  16. twostep says:

    I am not familiar yet with firewalld, and now I know why, because it is completely not intuitive.
    In my opinion, when you have got the router, based on the linux system, you should still choose iptables.
    Firewalld still looks like a beta version, and you still write the direct rules if you want to do something more complicated 🙁
    I do not completely understand the idea of preconfig 9 zones (why not 7 maybe 11), the better way is to give the option to create the new zones by admin, how many he need.

    1. Is it possible to create completely new zone?
    2. you write that the order of processing packets is:
    a) zone with source definition
    b) zone with interface definition
    c) zone default
    What if I have 2 zones with similar source which are different by mask, which zone will be first to process?

    • CertDepot says:

      I agree with you, Firewalld is not very intuitive.
      1. Yes, it is possible to create new zones: # firewall-cmd –permanent –new-zone=test
      I’m sure you then need to edit a xml file to complete the configuration.
      2. Your example is a corner case not supposed to happen in normal life. I don’t know the answer.

  17. hunter86_bg says:

    I’ve tried to backup and restore the firewalld configuration via “iptables -S” and “iptables-save” and restoring via “iptables-restore” , but it didn’t work.

    The only solution I have found to do the trick is to backup via “cp -a /etc/firewalld /some_location/” and later restore via “cp -a /some_location/firewalld/ /etc” and reloading via “firewall-cmd –reload”

    And if you want to test something you can always prevent locking yourself via:
    1.Set atd to reload the firewall in some time in advance
    2.”firewall-cmd ” without permanent
    3.And if you like it “firewall-cmd –runtime-to-permanent”

  18. reaz_mahmood says:

    When asked to configure a firewall in exam which allows so and so service.. are we supposed to create a new zone or editing any of the preconfigured zones will be ok?
    Thanks.

    • CertDepot says:

      In the RHCSA exam, from my knowledge, there was never a question about setting up a new zone or modifying the content of an existing zone. This is not part of the exam objectives.

      • reaz_mahmood says:

        I am confused …so what does “Configure firewall settings using firewall-config, firewall-cmd, or iptables.” means? I mean when they ask for any setting change regarding firewall like allow http service or allow these host… don’t we have to do them in a zone.
        Thanks.

        • CertDepot says:

          To my knowledge, zones are not used in the exams.
          When they ask any firewalld configuration, everything is done in the default zone.

          • Lisenet says:

            Agreed. If not explicitly asked, all firewall configuration should be done in the default zone independently of what zone is set as the default on a server (public, dmz etc) during the exam.

            I’d only change the default zone to something else if there is a task to do so.

          • reaz_mahmood says:

            Thanks for the clarification.

  19. Joe_Wulf says:

    An important, albeit missing, component, is how to get the firewalld logs, in RHEL7/CentOS7 to the central rsyslog host.

  20. number 6 says:

    Greetings mr certdepot & thanks again for being the best rh exam website.

    About block/reject, lets say that we’ve been given a domain and not an IP that must be blocked – is there any option to block/reject a specific domain name (to ensure it will be blocked even if it gets a different ip) or just dig @ its ip and block it?

  21. quovadisnp says:

    Renewing my RHCE to 7 on Friday and wondered what releases folks seeing in the US? Not too worried, between this site and Jang’s book, topics are well covered (and practiced). Would just be nice to do a last round of practice labs on the (potentially) current exam release. 7.0, 7.1, …?

  22. gurugreen says:

    Thanks Man Great Work

  23. samuel.sappa says:

    Hi Certdepot,
    regarding the need to enable the ip forwarding that requires masquerading in my lab (using rhel7.0) it’s seem already enable by default when I’m running the command it’s display
    Warning: ALREADY_ENABLED
    maybe in the exam we must check it first before configuring port forwarding. Nice info for me considering already failed 2 times on my exam 🙁

    • CertDepot says:

      This point requires some verifications: enabling ip forwarding may be needed depending on versions of Firewalld or RHEL, or even of level of patches.
      It seems to be a good idea to check as you propose.
      Good luck for your next attempt.

      • samuel.sappa says:

        hi Certdepot
        so, masquerading we need to enable it in the external zone or in the zone we are currently working (default)

        • CertDepot says:

          You need to enable masquerading in the external zone.

        • Tariq says:

          If for example you want to forward from 192.168.1.12:2020 to [someIP]:443 then there are two options:
          1.if you don’t provide someIP (firewalld will forward it to 127.0.0.1) or someIP belongs to the same machine then you do not need enable masquerade.
          2.if someIP belongs to some other machine then you must enable masquerade (and of course IP_forwarding via sysctl) in the zone which applies to 192.168.1.12 (zone with source address binding or zone with NIC binding).
          I hope it will help to understand masquerading (aka NAT).

          • Lisenet says:

            That sounds about right. You don’t need masquerading if you don’t do NAT, which is the case if you want to forward to 127.0.0.1 (no NAT involved).

  24. asifshabir says:

    # firewall-cmd –zone=internal –add-service=ssh –permanent
    success
    # firewall-cmd –zone=internal –add-source=1.2.3.4/32 –permanent
    success
    # firewall-cmd –zone=public –remove-service=ssh –permanent
    success
    # firewall-cmd –reload
    success

    I have tried this example. it does not work.

    I have tried with –zone=public …

    firewall-cmd –add-source=192.168.1.241/32 –perm
    firewall-cmd –reload

    It does not block access from other IPs. (ssh is already added to this zone)

  25. asifshabir says:

    How to Test this scenarios ??

    # firewall-cmd –permanent –zone=external –add-forward-port=port=22:proto=tcp:toport=3753:toaddr=10.0.0.1
    success
    # firewall-cmd –reload
    success

    can you please explain ??
    I have set it up on server1 and from server1 try to ssh on port 22.
    server1 and server2 both are in same ip range/subnet

  26. maikeu says:

    Hi CertDepot

    I really appreciate your effort here

    I want to clarify on masquerading, because a) I’ve found a bunch of sources that seem to make it more complicated than you, and b) I’m not convinced that I’ve been able to create the correct behaviour on my VMs.

    From your explanation, and Michael Jang’s, I’ve deduced that if I am asked to configure masquarading on a specific zone, it should be essentially as simple as “–permanent –zone=($zone) –add-masquarade , where $zone is most likely to be dmz or external or whatever zone you don’t want to be able to directly address hosts in the internal networks. Furthermore, with a rich rule you can enable this behaviour to be only when the request is coming from a specified IP or IP range, with anything else following whatever routing logic is configured?

    And, after as simple a command as above (plus –reload), I should be able to verify this as working by showing that I can only ping, or ssh, in one direction between hosts in different zones, e.g. my internal server can ping or ssh my external server, but my external server cannot ping my internal server (unless the port-forward is configured specifically). That’s the part where I’ve had issues- I keep feeling this is configured correctly, but then I keep being able to ping in either directions.

    I keep running into other sources which specify a direct rule to be added as well, can you confirm this should not be necessary? e.g. https://www.server-world.info/en/note?os=CentOS_7&p=firewalld&f=2

    The essential source of my angst is that my lab isn’t behaving the way I think it should, so if you reassure me…it’s time for me to rebuild my lab, I think!

    Cheers

    • Sam says:

      Sounds like this is set up correctly. I suspect what you are looking for is a deeper understanding and control of the masquarade (NAT). Take a closer look at the rich rules and try and implement a few.

  27. alexpoilt says:

    Hi,

    I am studying for the EX300 exam, but I have doubts about Rich Rules and Port Forwarding

    The Port Forwarding I understood

    to redirect ssh to port 6000
    $ firewall-cmd –add-forward-port=port=6000:proto=tcp:toport=22:toaddr=192.168.122.197

    # ssh -p 6000 192.168.122.197 – it’s ok

    Now to do the same using the rich rules I’m not getting

    $ firewall-cmd –add-rich-rule ‘rule family=ipv4 source address=192.168.122.197 forward-port port=80 protocol=tcp to-port=8080’

    $ elinks http://192.168.122.197:8080

    The “connection refused” error occurs

    # firewall-cmd –list-all
    public (default, active)
    interfaces: eth0 eth1 team0
    sources:
    services: dhcpv6-client http https ssh
    ports: 3260/tcp
    masquerade: yes
    forward-ports:
    icmp-blocks:
    rich rules:
    rule family=”ipv4″ source address=”192.168.122.197″ forward-port port=”80″ protocol=”tcp” to-port=”8080″

    What am I doing wrong?

    Thank you

    • Lisenet says:

      In the second example you seem to use IP 192.168.122.197 as the source address, however, in the first example the same IP address is used as the destination address.

  28. muhammad.shakeeb says:

    Hi,
    I am unable to understand how add-sources attributes works. My Firewalld version is 0.4.3.2. Public is my default zone and zone red have source 192.168.0.107/24. By the below configuration if any one comes from (192.168.0.107) the request would succeed because the source zone (red) is applied first, and it allows ssh access. If someone attempts to ssh from somewhere else, say 192.168.0.112, there wouldn’t be a source zone, because no zones match that source. Therefore, the request would pass directly to the interface zone (public), which does not explicitly handle ssh. Since public’s target is default, the request passes to the firewalld default action, which is to reject it.
    Now the problem is 192.168.0.112 ip can also access the server.So what is the benefit of add-source in firewalld.

    [root@sanserver services]# firewall-cmd –version
    0.4.3.2

    ———————————————————
    [root@sanserver services]# firewall-cmd –list-all –zone=public ; firewall-cmd –list-all –zone=red;
    public (active)
    target: default
    icmp-block-inversion: no
    interfaces: ens33
    sources:
    services: dhcpv6-client
    ports:
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:

    red (active)
    target: default
    icmp-block-inversion: no
    interfaces:
    sources: 192.168.0.107/24
    services: dns smtp ssh
    ports: 2223/tcp
    protocols:
    masquerade: no
    forward-ports:
    sourceports:
    icmp-blocks:
    rich rules:
    ——————————————————
    [root@node11 ~]# ifconfig
    ens33: flags=4163 mtu 1500
    inet 192.168.0.112 netmask 255.255.255.0 broadcast 192.168.0.255

    [root@node11 ~]# ssh 192.168.0.110
    root@192.168.0.110‘s password:
    Last login: Sun Nov 11 09:18:25 2018 from 192.168.0.112
    [root@sanserver ~]#

    • Sam says:

      The Ip address 192.168.0.112 is within the range of 192.168.0.107/24, and hence will be accepted through your firewall. There may be other issues with the firewall I didn’t look too closely at it.

      To calculate a proper net mask look up IP calculator.

      I got these results from a random IP calculator.
      Address: 192.168.0.107
      Netmask: 255.255.255.0 = 24
      Wildcard: 0.0.0.255
      Network: 192.168.0.0/24 (Class C)
      Broadcast: 192.168.0.255
      HostMin: 192.168.0.1
      HostMax: 192.168.0.254
      Hosts/Net: 254

    • Lisenet says:

      Use 192.168.0.107/32 to restrict access to a specific IP rather than the whole subnet.

Leave a Reply

Upcoming Events (Local Time)

There are no events.

RHCSA7: Task of the day

Allowed time: 5 minutes.
Create a user called tom. Create a directory named /private. Use an acl to only allow access (rwx) to tom to the private directory.

RHCE7: Task of the day

Allowed time: 10 minutes.
Configure a httpd server that executes a Perl script in the /var/www/cgi-bin directory displaying "Hello!".

Follow me on Twitter

Poll for favorite RHEL 7 book

What is your favorite RHEL 7 book to prepare RHCSA & RHCE exams?

View Results

Loading ... Loading ...

Poll for most difficult RHCSA 7 topic

What do you think is the most difficult RHCSA 7 topic?

View Results

Loading ... Loading ...

Poll for most difficult RHCE 7 topic

What do you think is the most difficult RHCE 7 topic?

View Results

Loading ... Loading ...