Your Fedora 44 computer is exposed to network threats without a firewall. Every open port is a potential entry point for attackers scanning for vulnerabilities. Many users install Fedora Workstation and assume security is automatic, but minimal or server installs often skip the firewall package entirely. Without FirewallD running, your system accepts all incoming traffic by default.

This guide shows you exactly how to install FirewallD on Fedora 44, verify it works, and configure basic rules. You’ll learn why each step matters, not just what commands to run. After completing these steps, your system will block unauthorized access while allowing legitimate services like SSH, HTTP, and HTTPS.

Whether you’re setting up a development server, protecting a workstation on public Wi-Fi, or deploying a cloud instance, FirewallD provides the foundation for Linux network security. Fedora 44 uses nftables as FirewallD’s backend, making it faster and more efficient than the old iptables system.

What Is FirewallD and Why Fedora 44 Uses It

FirewallD is a dynamic firewall management daemon for Linux systems. Unlike traditional iptables that requires restarting the entire service to change rules, FirewallD lets you modify rules instantly without dropping connections. It uses zones and services to organize traffic rules by trust level.

Fedora installs FirewallD by default during OS setup on Workstation editions. The service starts automatically and blocks all access except SSH. However, Fedora Cloud Edition relies on cloud security systems instead, and minimal server installs may not include it. Fedora 44 specifically changed FirewallD’s default backend from iptables to nftables, which uses a single kernel module for better performance.

FirewallD is not the actual packet filter. It’s a management layer that configures nftables (or iptables) through a D-Bus interface. This architecture gives you user-friendly commands while keeping the powerful kernel-level filtering.

FirewallD vs iptables vs nftables: Which Should You Use

Understanding the difference between these tools prevents confusion. Each plays a different role in Linux networking.

iptables is the legacy firewall tool. You manually write rules for every port and service. Changing rules requires restarting the entire firewall, which drops all active connections. It uses multiple kernel modules and consumes more memory.

nftables is the modern kernel backend. It replaces iptables with a single kernel module that handles packet filtering more efficiently. nftables uses less memory, manages rules faster, and supports better scalability for large rule sets.

FirewallD is the management daemon. It sits above nftables and provides dynamic rule management through simple commands. You tell FirewallD to “allow HTTP” and it translates that to the correct nftables rules automatically.

Fedora 44 uses FirewallD with nftables as the default because it combines the performance of nftables with the ease of FirewallD’s zone system. Direct rules still work with iptables syntax for backward compatibility, but new deployments should use nftables.

Prerequisites Before Installing FirewallD on Fedora 44

Before running installation commands, verify you have these requirements. Skipping this step causes installation failures or locks you out of remote systems.

• Fedora 44 installation (Workstation, Server, or Minimal edition)
  • Workstation typically has FirewallD pre-installed
  • Minimal or server builds may lack the package
• Root or sudo privileges on your system
  • All firewall commands require elevated permissions
  • If sudo fails, add your user to the wheel group first
• Active internet connection for package downloads
  • DNF needs network access to reach Fedora repositories
• Open SSH session if working on a remote server
  • Keep your connection open while enabling FirewallD
  • Verify SSH is allowed before closing the session

You need these tools installed and working:

• Terminal access (GNOME Terminal, Ghostty, Kitty, or similar)
• DNF package manager (Fedora’s default, usually pre-installed)
• systemctl for service management (part of systemd)
• firewall-cmd CLI client (installed with FirewallD package)

Step 1: Check if FirewallD Is Already Installed

Don’t install FirewallD blindly. Fedora Workstation includes it by default, so running dnf install shows “already installed” on most workstations. This is normal. Verify the package state first to avoid confusion.

Check the RPM Package

Run this command to see if the FirewallD package exists:

rpm -q firewalld

The -q flag queries the RPM database for the package name. If installed, you’ll see output like this:

firewalld-2.4.0-2.fc44.noarch

If the package is missing, you’ll see:

package firewalld is not installed

This output means you need to install FirewallD. Continue to Step 2.

Verify the CLI Client Exists

Even if the package is installed, confirm the command client works:

rpm -qf /usr/bin/firewall-cmd

The -qf flag queries which package owns a specific file. Expected output:

firewalld-2.4.0-2.fc44.noarch

If this returns “file not in any package,” the package exists but the CLI is missing. Reinstall the package:

sudo dnf reinstall firewalld

Why This Verification Matters

Running installation commands on systems with FirewallD already installed wastes time. DNF will report the package exists and stop. On minimal installs without the package, you need to proceed with installation.

Don’t skip this step. On Fedora Workstation, you’ll see “package is already installed” and that’s normal. Proceed to Step 4 to enable and start the service.

Step 2: Update Fedora Package Metadata

Before installing security software, update your system packages. This ensures you install the latest FirewallD version with current security patches. Old versions may have unpatched vulnerabilities.

Refresh and Upgrade All Packages

Run this command to update Fedora’s package metadata and apply pending updates:

sudo dnf upgrade --refresh

The --refresh flag forces DNF to download fresh metadata from Fedora mirrors. The upgrade command checks for updates to all installed packages.

DNF shows a transaction summary:

Dependencies resolved.
================================================================================
 Package              Version           Arch        Repository          Size
================================================================================
Upgrade:
  kernel             6.11.0-2.fc44     x86_64      fedora              12 MB
  systemd            256.5-1.fc44      x86_64      fedora               2 MB
  openssh-server     9.9p1-3.fc44      x86_64      fedora               1 MB

Transaction Summary
Upgrade: 15 packages
Total download size: 18 MB
Is this ok: yes/no

Review the packages before pressing y. Security updates for OpenSSH or network tools might affect your active session.

Why Updating Before Installation Is Critical

Installing FirewallD with stale package metadata can cause problems:

• You might install an outdated FirewallD version with known bugs
• Dependency conflicts occur if repositories are outdated
• Installation fails if metadata doesn’t match repository state

Fedora 44’s FirewallD version 2.4.0 includes the nftables backend. Updating ensures you get this version instead of an older release.

Skip This Step Only If

You can skip updating if:

• You just installed Fedora 44 today and ran updates already
• You’re on an isolated system without internet access
• You’re installing from a local repository mirror

For most users, always run this update first.

Step 3: Install FirewallD Using DNF

Now install the FirewallD daemon and Python command client from Fedora’s official repositories. DNF handles dependencies automatically.

Install the FirewallD Package

Run this command to install FirewallD:

sudo dnf install firewalld

The install command downloads the package and all required dependencies. DNF shows what it will install:

Dependencies resolved.
================================================================================
 Package                Version           Arch        Repository        Size
================================================================================
Install:
  firewalld            2.4.0-2.fc44      noarch      fedora            1.2 MB
Installing dependencies:
  python3-firewall     2.4.0-2.fc44      noarch      fedora            800 KB
  firewalld-filesystem 2.4.0-2.fc44      noarch      fedora             5 KB
  ipset                14.2-1.fc44       x86_64      fedora            150 KB

Transaction Summary
Install: 15 packages
Total download size: 2.5 MB
Is this ok: yes/no

Type yes to confirm. DNF downloads packages and installs them.

What DNF Installs

The main package firewalld includes:

• The FirewallD daemon service (/usr/lib/systemd/system/firewalld.service)
• The CLI client (/usr/bin/firewall-cmd)
• Zone configuration files (/etc/firewalld/zones/)
• Service definition files (/usr/lib/firewalld/services/)

Dependencies may include:

• python3-firewall (FirewallD’s Python backend)
• firewalld-filesystem (directory structure)
• ipset utilities (for IP set management)

If Package Is Already Installed

On Fedora Workstation, you might see:

Package firewalld-2.4.0-2.fc44.noarch is already installed.
Nothing to do.

This is normal. Skip to Step 4 and enable the service.

Post-Installation Verification

Confirm the package installed correctly:

rpm -q firewalld

Expected output:

firewalld-2.4.0-2.fc44.noarch

If this returns “package not installed,” the installation failed. Check for errors in the DNF output and retry.

Step 4: Enable and Start the FirewallD Service

Now activate FirewallD immediately and configure it to start automatically on future boots. Without this step, FirewallD won’t run and your system stays unprotected.

Enable and Start Together

Run this combined command:

sudo systemctl enable --now firewalld

The enable flag creates systemd symlinks so FirewallD starts on boot. The --now flag starts the service immediately instead of waiting for the next boot. This combines two commands into one:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Using enable --now is faster and ensures the service runs before you configure rules.

What Happens When FirewallD Starts

When the service starts:

1. FirewallD loads zone configurations from /etc/firewalld/
2. It applies nftables rules to the Linux kernel (default in Fedora 44)
3. The daemon blocks all incoming traffic except allowed services
4. By default, only SSH (port 22) is allowed

This means your system is now protected. All other ports are blocked until you explicitly allow them.

Critical Warning for Remote Servers

Keep your SSH session open when enabling FirewallD on remote machines. After FirewallD starts, it blocks all traffic except what’s in allowed services. Fedora defaults to allowing SSH only.

If your SSH port isn’t in the active zone, you’ll lock yourself out. Verify SSH is allowed before closing your session:

sudo firewall-cmd --zone=FedoraWorkstation --query-service=ssh

This returns yes if SSH is allowed. If it returns no, add SSH first:

sudo firewall-cmd --permanent --zone=FedoraWorkstation --add-service=ssh
sudo firewall-cmd --reload

Unmask If Service Was Disabled

Some minimal installs mask FirewallD to prevent it from starting. If enable --now fails, unmask it first:

sudo systemctl unmask firewalld
sudo systemctl enable --now firewalld

The unmask command removes the mask symlink that prevents service startup.

Step 5: Verify FirewallD Is Running Correctly

Before configuring rules, confirm FirewallD is active, enabled, and responding to commands. Skipping verification means you might configure rules on a non-running service.

Check Service State

Run these two commands to check both runtime and boot state:

systemctl is-active firewalld
systemctl is-enabled firewalld

The is-active command checks if the service runs now. The is-enabled command checks if it starts on boot.

Expected output:

active
enabled

If you see inactive or disabled, the service didn’t start properly. Retry Step 4.

Check FirewallD Daemon Status

Verify the FirewallD daemon responds to commands:

sudo firewall-cmd --state
sudo firewall-cmd --version

The --state flag shows the daemon’s runtime status. The --version flag shows the installed version.

Expected output:

running
2.4.0

If --state returns not running, the daemon isn’t responding. Restart the service:

sudo systemctl restart firewalld

View Full Service Status

Get detailed information including PID and logs:

sudo systemctl status firewalld

This shows:

• Main PID (process ID of the daemon)
• Loading path (service file location)
• Active timestamp (when it started)
• Recent log entries

Expected output includes Active: active (running).

Troubleshooting Verification Failures

If is-active returns inactive:

• Check logs: journalctl -u firewalld
• Look for error messages about failed rule loading
• Try sudo systemctl start firewalld manually

If firewall-cmd --state returns not running:

• The daemon crashed or failed to initialize
• Restart with sudo systemctl restart firewalld
• Check for configuration errors in /etc/firewalld/

Understanding FirewallD Zones: The Core Concept

Zones are the foundation of FirewallD. Rules apply to zones, not directly to network interfaces. Always confirm which zone owns your interface before adding rules.

What Is a Zone

A zone is a predefined policy container for network traffic. Each zone represents a trust level:

• public: Low trust (cloud servers, public Wi-Fi)
• home: Medium trust (trusted home LANs)
• work: Medium trust (office networks)
• FedoraWorkstation: Medium trust (Fedora Workstation installs)
• FedoraServer: Medium trust (Fedora Server installs)

Network interfaces and source addresses get assigned to zones. Traffic allowed depends on the network’s assigned security level.

Find Your Active Zone

List interfaces and their assigned zones:

sudo firewall-cmd --get-active-zones

This shows all zones with active interfaces. Example output:

FedoraWorkstation (default) interfaces: ens160

The zone name (FedoraWorkstation) is what you use in commands. The interface (ens160) is your network device.

Check Default Zone

Find the default zone for new interfaces:

sudo firewall-cmd --get-default-zone

Expected output:

FedoraWorkstation

New interfaces without explicit assignment land here.

List All Rules in a Zone

See complete zone configuration before editing:

sudo firewall-cmd --zone=FedoraWorkstation --list-all

This displays:

• target (default action for traffic)
• services (allowed service names)
• ports (allowed port numbers)
• rich rules (complex traffic rules)

Example output:

FedoraWorkstation (default)
  target: default
  icmp-block-inversion: no
  interfaces: ens160
  sources:
  services: ssh mdns kdeconnect
  ports:
  forward: no
  masquerade: no

Notice services: ssh mdns kdeconnect. Only these services are allowed through the firewall.

Why Zones Matter

Rules apply to zones, not interfaces directly. If you add a rule to the public zone but your interface uses FedoraWorkstation, the rule doesn’t work. Always check the active zone first using --get-active-zones.

Configuring Basic Firewall Rules (Services and Ports)

Fresh FirewallD blocks all traffic except SSH. You need to allow legitimate services like HTTP, HTTPS, or custom application ports.

Why Allow Services After Installation

Default FirewallD configuration blocks everything except SSH. Web servers need HTTP and HTTPS open. Database servers need their ports accessible. Applications with custom ports need explicit rules.

The security principle is simple: only allow traffic you explicitly need. This reduces exposure to attacks scanning for vulnerable services.

Method 1: Allow Predefined Services

Use FirewallD’s built-in service definitions for common protocols:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

The --permanent flag makes rules persistent across reboots. The --zone=public flag specifies which zone to modify. The --add-service=http flag adds the HTTP service definition.

The --reload command applies permanent rules to runtime without restarting the service. Without --reload, rules won’t work until you reboot.

Verify Service Was Added

Check if the service is now allowed:

sudo firewall-cmd --zone=public --query-service=http

This returns yes if HTTP is allowed, no if not.

Method 2: Open Custom Ports

When no service definition exists, open ports directly:

sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
sudo firewall-cmd --reload

You must specify the protocol (tcp or udp). HTTP uses TCP, DNS uses UDP.

Verify Port Was Added

Check if the port is open:

sudo firewall-cmd --zone=public --query-port=8080/tcp

Returns yes if the port is allowed.

Remove Rules When No Longer Needed

Close ports you don’t use:

sudo firewall-cmd --permanent --zone=public --remove-service=http
sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcp
sudo firewall-cmd --reload

Removing unnecessary rules reduces security risk.

Common Service Names

Fedora includes definitions for these services:

• ssh (port 22)
• http (port 80)
• https (port 443)
• dhcpv6-client (IPv6 DHCP)
• mdns (service discovery)
• kdeconnect (Fedora KDE integration)

Troubleshooting Common FirewallD Installation Issues

Real problems occur during FirewallD setup. Here are the most common errors and their fixes.

Issue 1: FirewallD Is Not Running

Check service state:

systemctl is-active firewalld
sudo firewall-cmd --state

If you see inactive and not running, the service failed to start.

Fix:

sudo systemctl enable --now firewalld

Check logs for errors:

journalctl -u firewalld

Look for messages about failed rule loading or permission issues.

Issue 2: Rule Added to Wrong Zone

Symptoms: Port looks open but traffic still fails.

Why: You added the rule to a different zone than your interface uses.

Fix:

1. Find active zone: sudo firewall-cmd --get-active-zones
2. Add rule to correct zone:

   sudo firewall-cmd --permanent --zone=FedoraWorkstation --add-service=ssh
   sudo firewall-cmd --reload
   

Issue 3: Rules Disappeared After Reboot

Symptoms: Runtime rules work but disappear after reboot.

Why: You forgot the --permanent flag. Runtime-only rules aren saved.

Fix:

sudo firewall-cmd --runtime-to-permanent

This saves current runtime rules permanently. Review rules first—don’t save temporary test rules.

Issue 4: Port Open But Service Unreachable

Symptoms: Firewall allows port but application doesn’t respond.

Why: The application isn’t listening on that port.

Fix:

Check if service listens on the port:

sudo ss -H -ltn 'sport = :8080'

No output means no TCP listener is active. Start or reconfigure your application.

Issue 5: Panic Mode Blocks All Traffic

Check if panic mode is active:

sudo firewall-cmd --query-panic

If it returns yes, all network traffic is dropped immediately.

Fix:

sudo firewall-cmd --panic-off

Panic mode activates when FirewallD detects configuration errors.

[su_box title=”VPS Manage Service Offer” style=”bubbles” box_color=”#000000″ radius=”10″]If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal![/su_box]