How to Install Firewalld on Fedora 44

Fedora uses Firewalld as its default firewall manager, so the real task is often confirming that the daemon is present, running, and protecting the network zone attached to your current connection. When you need to install Firewalld on Fedora manually, DNF provides the package from Fedora’s standard repositories, then systemd keeps the firewall active across reboots.

Firewalld manages nftables rules through zones, services, ports, rich rules, and ipsets. Workstation installs commonly start with the FedoraWorkstation zone, while server and minimal systems may use a different zone or may not have the package installed yet.

Install Firewalld on Fedora

Start with the install and service checks before editing firewall rules. Fedora Workstation often already has Firewalld installed and enabled, but minimal images, custom server builds, and containers can differ.

Check Whether Firewalld Is Installed

Check the installed RPM package first. This avoids a privileged Firewalld command on systems where the daemon is not available yet:

rpm -q firewalld

A Fedora 44 Workstation system returns a package name and build similar to this; later updates may show a newer build:

firewalld-2.4.0-2.fc44.noarch

If the command reports that the package is not installed, continue with the DNF install step. If the package is already present, skip to the service enablement and verification commands.

Update Fedora Before Installing Firewalld

Refresh Fedora’s package metadata and apply pending updates before installing system security components. Review the transaction before confirming, especially on remote systems where network, OpenSSH, or firewall updates could affect an active session.

sudo dnf upgrade --refresh

These commands use sudo for package and firewall changes. If your account cannot run sudo yet, add it to Fedora’s wheel group with the guide on how to add a user to sudoers on Fedora before continuing.

Install Firewalld with DNF

Install the Firewalld daemon and its Python command client from Fedora’s repositories:

sudo dnf install firewalld

DNF may report that Firewalld is already installed. That is normal on Fedora Workstation and many Fedora Server installs. The package that provides the command-line client is the same Firewalld package:

rpm -qf /usr/bin/firewall-cmd

Expected output shows Firewalld as the package owner:

firewalld-2.4.0-2.fc44.noarch

For more DNF examples, including package searches and install checks, use the DNF5 install command guide for Fedora.

Enable and Start the Firewalld Service

Enable Firewalld for future boots and start it immediately:

sudo systemctl enable --now firewalld

Keep an existing SSH session open while enabling or changing firewall rules on a remote machine. After Firewalld starts, verify that the active zone allows the SSH service or your custom SSH port before closing your current session.

Verify Firewalld on Fedora

Use narrow service checks for the boot and runtime state:

systemctl is-active firewalld
systemctl is-enabled firewalld

Expected output for a running, boot-enabled service is:

active
enabled

Then confirm that the Firewalld command client can reach the daemon:

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

Relevant output includes the running state and the installed Firewalld version:

running
2.4.0

Manage Firewalld Zones and Rules on Fedora

Firewalld rules apply to zones. A zone can represent a network interface, a source address range, or a default policy for new connections. Always confirm the zone you are editing before opening services or ports.

Find the Active Firewalld Zone

List the active zones and the interfaces attached to them:

sudo firewall-cmd --get-active-zones

Example output on Fedora Workstation can look like this:

FedoraWorkstation (default)
  interfaces: ens160

The interface name varies by system. Use the zone shown beside the interface that carries the traffic you are configuring. A bare --query-service or --query-port checks the default zone, which may not be the active zone for your network path.

Check the default zone separately when you need to know where new interfaces land:

sudo firewall-cmd --get-default-zone

FedoraWorkstation

Check Rules in a Zone

Inspect one zone before changing it. Replace FedoraWorkstation with the active zone name from your system:

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

Relevant output includes the target, services, ports, and any rich rules:

FedoraWorkstation (default)
  target: default
  services: dhcpv6-client http https samba-client ssh
  ports: 1025-65535/udp 1025-65535/tcp
  rich rules:

Because zone contents can change by edition and local configuration, treat this as an example shape. The stable lesson is to verify the zone that owns your interface before assuming a rule is present.

Allow a Service Through Firewalld

Use named services when Firewalld already has a definition for the protocol. For example, allow HTTP and HTTPS in the public zone for a web server:

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

The reload applies the permanent rules to the runtime configuration without restarting the daemon. Verify one service after reloading:

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

yes

If you are preparing a web stack, the same Firewalld service names pair with the guides to install Apache HTTP Server on Fedora or install Nginx on Fedora.

Open and Close a Custom Port

Use a port rule when no service definition exists for the application. Always include the protocol, usually tcp or udp:

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

Verify that the port landed in the intended zone:

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

yes

Close the port when the application no longer needs it:

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

Avoid broad public access for admin panels, databases, and development servers. Prefer a source-limited rule, VPN, SSH tunnel, or private zone when only trusted clients should connect.

Remove a Service Rule

Remove a service from a zone when you no longer want that traffic allowed. This example removes HTTP from the public zone and reloads the rules:

sudo firewall-cmd --permanent --zone=public --remove-service=http
sudo firewall-cmd --reload

A removed service returns no when queried:

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

no

Firewalld Zone Reference for Fedora

Zones are policy containers. The right zone depends on trust level, exposed services, and whether the host moves between networks or stays in one server role.

Zone	Trust Level	Typical Use	Notes
drop	Zero	Hostile networks	Silently drops unsolicited inbound packets.
block	Zero	Untrusted networks needing rejection replies	Rejects rather than silently dropping.
public	Low	Cloud servers, public Wi-Fi, exposed hosts	Allow only services you explicitly need.
external	Low	Routers, VPN gateways, NAT hosts	Designed for forwarding and masquerading.
dmz	Low	Public-facing services isolated from private networks	Useful when a host bridges public and internal roles.
work	Medium	Office networks	Assumes more trust than public, but not full trust.
home	Medium	Trusted home LANs	Often fits local discovery and file-sharing workflows.
internal	High	Private server, backup, or management networks	Use for networks you control closely.
trusted	Full	VPN tunnels or fully trusted links	Accepts all traffic, so use it sparingly.

FedoraWorkstation and FedoraServer Zones

Fedora also ships edition-oriented zone definitions. FedoraWorkstation is common on Workstation installs and opens high TCP and UDP ports for desktop workflows. FedoraServer includes SSH and Cockpit-oriented server access. Inspect them directly before relying on a default:

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

If you manage servers remotely, the SSH on Fedora guide is the right companion for confirming the daemon, port, and access path before tightening firewall rules.

Create Custom Firewalld Services and Rules on Fedora

Custom services, rich rules, and ipsets help when built-in service names are not specific enough. Test complex changes at runtime first when possible, then make the final version permanent once you know the rule behaves correctly.

Create a Custom Service Definition

Create a reusable service definition when the same application port appears in multiple zones or on multiple hosts. This example defines a Node.js dashboard on TCP port 3000:

sudo tee /etc/firewalld/services/nodeapp.xml > /dev/null <<'EOF'
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>nodeapp</short>
  <description>Node.js dashboard on TCP port 3000</description>
  <port protocol="tcp" port="3000"/>
</service>
EOF
sudo firewall-cmd --check-config
sudo firewall-cmd --reload

The config check and reload make Firewalld recognize the new service file. A valid service definition returns:

success
success

Now add the custom service to a zone and verify it:

sudo firewall-cmd --permanent --zone=public --add-service=nodeapp
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=nodeapp

success
success
yes

Create a Custom Zone

Create a custom zone when one interface or source range needs a policy that does not match the built-in zones. This example creates a webservers zone and allows HTTP and HTTPS:

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

Verify the new zone after the reload:

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

Relevant output includes the custom zone name and allowed services:

webservers
  target: default
  services: http https

Assign interfaces through NetworkManager so the setting survives reconnects. First list the active connection names:

nmcli connection show --active

Then replace Wired connection 1 with your connection name:

sudo nmcli connection modify "Wired connection 1" connection.zone webservers
sudo nmcli connection up "Wired connection 1"

Changing the zone on a remote interface can interrupt access if the new zone does not allow SSH or your custom management port. Keep a second session or console path available before applying the connection change.

Block an IP Address with a Rich Rule

Use a rich rule when a simple service or port rule is not enough. This example logs and drops traffic from the documentation address 192.0.2.50 in the public zone:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.50" log prefix="firewalld-block" level="info" drop'
sudo firewall-cmd --reload

Query the exact saved rule after the reload:

sudo firewall-cmd --zone=public --query-rich-rule='rule family="ipv4" source address="192.0.2.50" log prefix="firewalld-block" level="info" drop'

yes

After matching traffic reaches the host, recent kernel log entries can include the configured prefix:

sudo journalctl -k -g 'firewalld-block' --since '1 hour ago'

For automated login bans, pair Firewalld with Fail2ban with Firewalld on Fedora instead of maintaining block rules by hand.

Block Network Ranges with an Ipset

Ipsets handle large address lists more cleanly than many individual rich rules. This example creates an ipset for the documentation network 203.0.113.0/24 and drops traffic from that set:

sudo firewall-cmd --permanent --new-ipset=blocked_ranges --type=hash:net
sudo firewall-cmd --permanent --ipset=blocked_ranges --add-entry=203.0.113.0/24
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="blocked_ranges" drop'
sudo firewall-cmd --reload

Verify that Firewalld saved the rich rule that references the ipset:

sudo firewall-cmd --zone=public --query-rich-rule='rule family="ipv4" source ipset="blocked_ranges" drop'

yes

Confirm the ipset contains the expected entry:

sudo firewall-cmd --info-ipset=blocked_ranges

Relevant output includes the ipset type and entries:

blocked_ranges
  type: hash:net
  entries: 203.0.113.0/24

Update or Remove Firewalld on Fedora

DNF owns Firewalld updates and package removal. Treat removal carefully because Firewalld often protects SSH, web, database, and management access on the same host.

Update Firewalld

Upgrade Firewalld through Fedora’s normal package workflow:

sudo dnf upgrade firewalld

If DNF upgrades the package while the service is running, verify the daemon state afterward:

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

active
running

Temporarily Stop or Disable Firewalld

Stopping or disabling Firewalld removes the host firewall layer until you start it again or replace it with another policy. Avoid this on remote or public-facing systems unless you have console access, an upstream security group, or another firewall already protecting the host.

For short troubleshooting windows, stop the daemon without changing the boot setting:

sudo systemctl stop firewalld
systemctl is-active firewalld || true

inactive

Start it again before leaving the session:

sudo systemctl start firewalld
systemctl is-active firewalld

active

Disable boot-time startup only when another firewall layer owns the host policy:

sudo systemctl disable --now firewalld
systemctl is-active firewalld || true
systemctl is-enabled firewalld || true

inactive
disabled

Re-enable Firewalld when the troubleshooting or replacement test is complete:

sudo systemctl enable --now firewalld
systemctl is-active firewalld
systemctl is-enabled firewalld

active
enabled

Remove Example Rules

If you used the public-zone examples only for practice, remove those example openings before leaving the system:

sudo firewall-cmd --permanent --zone=public --remove-service=http
sudo firewall-cmd --permanent --zone=public --remove-service=https
sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source address="192.0.2.50" log prefix="firewalld-block" level="info" drop'
sudo firewall-cmd --reload

If you assigned a NetworkManager connection to the example webservers zone, move that connection back to its previous zone before deleting the zone. An empty connection.zone value makes NetworkManager follow Firewalld’s default zone again:

sudo nmcli connection modify "Wired connection 1" connection.zone ""
sudo nmcli connection up "Wired connection 1"

Replace Wired connection 1 with the profile name you changed earlier. After no interfaces or source bindings use the example zone, delete it:

sudo firewall-cmd --permanent --delete-zone=webservers
sudo firewall-cmd --reload

Remove the custom service example if you created it and no longer need it:

sudo firewall-cmd --permanent --zone=public --remove-service=nodeapp
sudo rm -f /etc/firewalld/services/nodeapp.xml
sudo firewall-cmd --reload

Remove the example ipset rule before deleting the ipset itself:

sudo firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source ipset="blocked_ranges" drop'
sudo firewall-cmd --permanent --delete-ipset=blocked_ranges
sudo firewall-cmd --reload

Remove the Firewalld Package

Removing Firewalld can leave the host without the firewall policy you expect. Confirm another firewall, upstream security group, or console recovery path before removing it from a remote or public-facing system.

Stop and disable the service first, then remove the package with DNF:

sudo systemctl disable --now firewalld
sudo dnf remove firewalld

Verify that the main package is no longer installed:

rpm -q firewalld >/dev/null 2>&1 || echo "firewalld is not installed"

firewalld is not installed

DNF may also remove unused Firewalld dependencies, such as python3-firewall, firewalld-filesystem, and ipset, after you review and confirm the transaction.

Remove Custom Firewalld Configuration

Package removal does not always remove custom zone, service, ipset, or policy files under /etc/firewalld/. Inspect that directory before deleting anything:

sudo find /etc/firewalld -mindepth 1 -maxdepth 3 -print 2>/dev/null || echo "No custom Firewalld configuration found"

Deleting /etc/firewalld permanently removes custom zones, services, policies, ipsets, and saved rules. Keep a backup if you might reinstall Firewalld or need to audit the old policy later.

sudo rm -rf /etc/firewalld

Troubleshoot Firewalld on Fedora

Most Firewalld failures come from three places: the daemon is not running, the rule was added to the wrong zone, or the target service is not listening on the port you opened.

Firewalld Is Not Running

When Firewalld is stopped, firewall-cmd cannot manage runtime rules. Check both the service and the command client:

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

A stopped service can return lines like these:

inactive
not running

Start the daemon and enable it for future boots:

sudo systemctl enable --now firewalld

Run the active and state checks again. They should return active and running.

A Rule Was Added to the Wrong Zone

If a port or service looks open but traffic still fails, verify the zone on your active interface:

sudo firewall-cmd --get-active-zones

Then query the rule in that exact zone. This example checks SSH in FedoraWorkstation:

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

yes

A no result means the zone attached to your interface does not allow that service. Add the rule to the active zone or move the connection to the zone that already has the correct policy.

Rules Disappeared After Reboot

Runtime-only rules disappear after reloads and reboots. Compare the runtime and permanent views for the same zone:

sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all

If the rule appears only in the runtime output, add it again with --permanent and reload, or intentionally copy the current runtime configuration to permanent storage:

sudo firewall-cmd --runtime-to-permanent

--runtime-to-permanent saves every current runtime rule, including temporary tests. Review the runtime zone first so you do not preserve a rule you meant to discard.

Port Is Open But the Service Is Unreachable

A Firewalld rule only allows traffic through the firewall. The application must also listen on that port and on the expected address. Check the listener first:

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

Relevant output for a service listening on all IPv4 addresses looks like this:

LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:*

No output means no TCP listener is active on port 8080. Start or reconfigure the application before changing more firewall rules. If the service listens only on 127.0.0.1, remote clients still cannot connect even when Firewalld allows the port.

NetworkManager Overrides a Zone Assignment

When an interface returns to a previous zone after reconnecting, NetworkManager is usually applying the zone stored in the connection profile. Check the active profile name:

nmcli connection show --active

Set the zone on the connection profile, then bring the profile back up:

sudo nmcli connection modify "Wired connection 1" connection.zone home
sudo nmcli connection up "Wired connection 1"

Replace Wired connection 1 with the connection name from your own output.

Panic Mode Blocks All Traffic

Panic mode drops all network traffic immediately. If remote access suddenly disappears after a firewall command, check panic mode from a local console or recovery session:

sudo firewall-cmd --query-panic

A disabled panic mode returns:

no

Disable panic mode when it is active:

sudo firewall-cmd --panic-off

Quick Reference: Common Firewalld Commands on Fedora

Use this table as a reminder after you understand which zone owns the traffic path. Replace public with the active zone when your interface uses a different one.

Task	Command	Notes
Check daemon state	sudo firewall-cmd --state	Returns running when Firewalld is active.
List active zones	sudo firewall-cmd --get-active-zones	Use this before editing rules.
Show default zone	sudo firewall-cmd --get-default-zone	New interfaces use this unless NetworkManager assigns another zone.
List one zone	sudo firewall-cmd --zone=public --list-all	Shows services, ports, sources, and rich rules.
Add service permanently	sudo firewall-cmd --permanent --zone=public --add-service=http	Reload afterward.
Remove service permanently	sudo firewall-cmd --permanent --zone=public --remove-service=http	Reload afterward.
Open a TCP port	sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp	Use the correct protocol.
Close a TCP port	sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcp	Reload afterward.
Apply permanent rules	sudo firewall-cmd --reload	Applies saved rules to runtime.
Save runtime rules	sudo firewall-cmd --runtime-to-permanent	Review runtime rules first.
Create a zone	sudo firewall-cmd --permanent --new-zone=webservers	Assign interfaces separately.
Delete a custom zone	sudo firewall-cmd --permanent --delete-zone=webservers	Works only for custom zones.
Check panic mode	sudo firewall-cmd --query-panic	Returns yes or no.
Disable panic mode	sudo firewall-cmd --panic-off	Use from console if remote access is blocked.

Conclusion

Firewalld is running on Fedora with a verified service state, a known active zone, and a repeatable pattern for adding, checking, and removing rules. For longer-lived servers, the next maintenance step is to install DNF Automatic on Fedora so package security updates do not depend on a manual reminder.