Configuring the Firewall with firewalld

Let us start with the absolute basics. A firewall is a software or hardware barrier that sits between your computer (or internal network) and the outside world (the internet). Its job is to examine every piece of network traffic — every "packet" of data — and decide whether to let it through or block it. Think of a packet as a tiny envelope containing a message, with a source address (where it came from) and a destination address (where it is going). The firewall checks each envelope against a list of rules. If the envelope matches a "permit" rule, it passes. If it matches a "deny" rule, it is dropped (thrown away). If no rule matches, the default action is usually to deny the packet.

On Red Hat Enterprise Linux (RHEL), the firewall is managed by a service called firewalld. The "d" at the end stands for "daemon", which is a background process that runs continuously. firewalld replaced the older system called iptables. The big difference is that iptables made you reload the entire set of rules after any change, which could break active connections. firewalld allows you to make changes without interrupting existing connections, because it uses a concept called "dynamic zones".

A zone is a logical grouping of network interfaces (like your ethernet port or WiFi adapter) with a predefined set of rules. RHEL comes with several default zones: public (for untrusted networks like a coffee shop WiFi), internal (for your trusted home or office network), dmz (for servers that must be accessible from the internet but separated from your internal network), and trusted (for networks you fully trust, like a dedicated management LAN). By default, all your network interfaces are assigned to the "public" zone, which is the most restrictive.

When you enable a service through firewalld, you are telling the firewall to allow traffic that matches that service's port number and protocol. For example, HTTP web traffic uses TCP port 80, so running the command "firewall-cmd --add-service=http" tells firewalld to allow incoming connections on port 80. The system immediately opens that door, and it stays open until you remove the rule.

Port forwarding is a feature where you tell the firewall: "when a packet arrives at this port on the server, send it to a different port on a different machine." This is extremely common in business environments. For instance, you might have a web server running on port 8080 inside your office, but you want people on the internet to reach it by typing port 80 in their browser. Using firewalld port forwarding, you can redirect incoming traffic from port 80 (on your firewall's public IP) to port 8080 (on the internal server).

The three essential commands you will use with firewalld are: firewall-cmd (the command-line tool), firewall-config (a graphical interface you will rarely use in the exam), and firewall-cmd --list-all (which shows you all the current rules). The most common flags are: --add-service (allow a known service), --add-port (allow a specific port number), --remove-service (block a previously allowed service), --permanent (make the change survive a reboot), and --reload (apply all pending permanent changes without restarting the entire firewall service).

One critical concept is the difference between runtime and permanent configuration. When you run a firewall-cmd command without the --permanent flag, the change takes effect immediately but is lost when the server reboots. This is called the "runtime" configuration, and it is useful for testing. To make a change permanent, you add --permanent to the command. But here is the trap: if you only use --permanent, the change does not take effect until you either run firewall-cmd --reload or reboot the server. In an exam question, they might ask you to add a service permanently AND make it active immediately. The correct pattern is to run two separate commands: one without --permanent (for immediate effect), and one with --permanent (to survive a reboot). Alternatively, you can run the command with --permanent and then reload.

Zones also have a concept called "target". The target zone defines what happens to packets that do not match any rule. The default target for most zones is "default", which means reject packets. You can change the target to "ACCEPT" (allow all traffic) or "DROP" (silently discard packets). Changing the target is rarely done in the exam but could appear in trick questions.

Finally, note that firewalld stores its permanent configuration in XML files located in /etc/firewalld/zones/. You can edit these files directly, but the recommended method is always to use the firewall-cmd command-line tool, which is what EX200 tests.

Imagine you are the sole IT administrator for a small company called GreenLeaf Books, which has one physical office and a single RHEL server that hosts both a company website (port 80 and 443) and an internal inventory application (port 8443) used only by employees in the office. Your boss tells you, "We got complaints that nobody can see the website from outside, and also the inventory app just stopped working." You immediately suspect the firewall.

Your first step is to SSH into the server and run "sudo firewall-cmd --list-all". This command prints the current firewall configuration for the default zone (public). You see that only the "ssh" service is listed, with no mention of http or https. That explains why the website is unreachable — the firewall is blocking incoming web traffic. You also notice that the server has two network interfaces: eth0 (connected to the internet) and eth1 (connected to the internal office switch). The public zone applies to both; that is why the inventory app on eth1 is also blocked.

To fix the website, you need to add the http and https services to the firewall. You run:

Then you verify by running --list-all again. Now http and https appear. But the inventory app is still blocked. You cannot add a standard service for port 8443 because it is not a well-known service. So you must add the custom port directly:

Now the inventory app works. But your boss also wants the company's internal webcam system (which only uses eth1) to be completely accessible, so you decide to move eth1 to the "trusted" zone, which has no restrictions. You run:

Now eth1 is in the trusted zone with all traffic allowed. eth0 remains in the public zone with only ssh, http, https, and port 8443 open.

Later, you learn that the company is moving to a new office and wants to set up a remote access system. They have an internal accounting server at 192.168.1.50 that listens on port 3030, but they want employees outside the office to reach it by typing the company's public IP address on port 3030. This is a classic port forwarding scenario. You run:

Now any packet arriving at your server's public IP on port 3030 gets forwarded to that internal machine. You also need to ensure IP forwarding is enabled on the server (otherwise the forwarding will not work), but that is a separate kernel parameter.

This scenario exactly mirrors exam questions where you must configure services, open custom ports, change zones, and set up port forwarding using firewalld.