How to Manage firewalld on Rocky Linux: Zones, Services, and Ports

Rocky Linux uses firewalld as its standard firewall management service, and the firewall-cmd command manages zones, services, ports, and source-based rules. On a remote server, the safest workflow is to test a change in the runtime configuration while keeping the current SSH session open, verify a new connection, and only then save the rule permanently.

This guide explains the commands needed for routine Rocky Linux firewall administration and the checks that help prevent an accidental lockout.

Check firewalld status and active zones

sudo firewall-cmd --state
sudo systemctl status firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

A firewalld zone is a collection of rules associated with a level of trust. A zone can be assigned to a network interface, a NetworkManager connection, or a source address. Check the active zones before making changes because omitting --zone may modify the default zone instead of the zone that handles the traffic you intend to control.

If an interface does not appear where you expect, inspect the active NetworkManager connection before adding rules. A correct rule in the wrong zone will not permit the intended traffic.

Start firewalld and enable it at boot

sudo systemctl enable --now firewalld

Verify both the boot setting and the current service state:

systemctl is-enabled firewalld
systemctl is-active firewalld

Do not disable the entire firewall on a production server just to make an application reachable. Permit only the required service, port, protocol, and source. In a cloud environment, remember that a security group, network access control list, or provider firewall can block traffic independently of firewalld.

Understand runtime and permanent configurations

For a remote server, add the rule to the runtime configuration first. Test the application and open a second SSH connection before copying the working runtime configuration to the permanent configuration.

sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --runtime-to-permanent

If you instead make a change with --permanent, review it and reload firewalld to activate it:

sudo firewall-cmd --reload

A reload replaces the runtime configuration with the permanent configuration. Unsaved runtime-only changes are therefore lost.

Allow and remove predefined services

List available service definitions

firewall-cmd --get-services
firewall-cmd --info-service=http

When firewalld already defines a standard service such as HTTP, HTTPS, or SSH, using the service name generally communicates the purpose more clearly than opening individual ports. A service definition can also include more than one port, protocol, or helper.

Allow a service in the runtime configuration

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

Opening the firewall does not start the web server. Confirm that the application is running and listening on the expected address and port:

ss -lntup

Remove an allowed service

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

Before removing SSH access on a remote machine, confirm that another tested access rule and an out-of-band console are available. Keep the existing SSH session open until a new connection succeeds.

Manage custom ports

Allow a TCP or UDP port

sudo firewall-cmd --zone=public --add-port=8443/tcp
sudo firewall-cmd --zone=public --add-port=5000/udp

TCP and UDP require separate rules. Check the application's documentation and open only the protocol and port it actually uses.

Allow a port range

sudo firewall-cmd --zone=public --add-port=6000-6010/tcp

Before opening a broad range, confirm the exact range the application requires. Where possible, also restrict access to known source addresses or a dedicated management network.

Remove and list ports

sudo firewall-cmd --zone=public --remove-port=8443/tcp
sudo firewall-cmd --zone=public --list-ports

Inspect the current rules

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

The first command shows the runtime rules for the specified zone, while the last command shows its permanent rules. If the results differ, the server can behave differently after the next reload or reboot. Compare both configurations before completing a maintenance change.

Restrict access to a source address

Create a rich rule for an SSH source

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" service name="ssh" accept'

192.0.2.10 is a documentation address, not an address to copy into a production rule. Replace it with the administrator's fixed public IP address or a trusted internal network. For IPv6, use an appropriate IPv6 source and family instead of copying the IPv4 example.

Test before removing general SSH access

After adding the source-specific rule, keep the current session open and establish a new SSH connection from the permitted address. Verify console recovery access before removing the broader SSH service rule.

sudo firewall-cmd --zone=public --list-rich-rules
sudo firewall-cmd --zone=public --remove-service=ssh

A source restriction can lock you out when the administrator's public address changes. Use a fixed address, a VPN, or a dedicated management network when stable source-based access is required.

Associate a NetworkManager connection with a zone

nmcli connection show --active
firewall-cmd --get-active-zones

Assigning a zone to a NetworkManager connection profile keeps the network configuration and firewalld zone association together. Replace the example connection name with the exact name shown by nmcli.

sudo nmcli connection modify 'System eth0' connection.zone public
sudo nmcli connection up 'System eth0'

Reactivating a network connection can interrupt remote access. Perform this change during a maintenance window with console access available, especially when the profile supplies the server's primary route.

Troubleshoot blocked connections in a useful order

1. Run systemctl is-active firewalld to confirm that firewalld is active.
2. Use firewall-cmd --get-active-zones to find the zone associated with the relevant interface or source.
3. Compare the runtime and permanent --list-all output for that zone.
4. Run ss -lntup to confirm that the application is listening on the expected address, port, and protocol.
5. Check cloud security groups, provider firewalls, router access control lists, and NAT rules.
6. Review SELinux denials and the application's logs.

An open firewalld port does not guarantee a successful connection. The application must be running and listening on a reachable address, and every other firewall or routing layer in the path must also allow the traffic.

Frequently asked questions

Why did a rule added with --permanent not take effect immediately?

A permanent rule is stored for future use and normally becomes active after firewall-cmd --reload. On a remote server, test the equivalent runtime rule first, confirm access, and then save it with --runtime-to-permanent.

Why is a service unreachable even though its port is open?

Check the active zone, the application's listening address and protocol, upstream cloud or network firewalls, NAT, and SELinux. Firewalld controls only one layer of the connection path.

Should I use a service rule or a port rule?

Use a predefined service when it accurately represents the application because the rule is easier to understand and can include all required protocols. Use an explicit port and protocol for a custom application or a nonstandard port.

Is it safe to stop firewalld for troubleshooting?

Stopping the entire firewall can expose every listening service and is unsafe on a production server. Inspect the active zone, logs, and current rules, then make the smallest temporary runtime change needed for a controlled test.

Summary

A safe Rocky Linux firewalld workflow starts by identifying the active zone, testing the smallest required runtime rule, and saving it only after the connection works. Prefer named services for standard applications, specify both the port and protocol for custom services, and compare runtime with permanent rules before finishing.

For remote SSH administration, preserve the current session and a console recovery path until a second connection succeeds. This precaution matters more than any individual firewall-cmd option.

Official references

• Rocky Linux documentation: firewalld for Beginners
• firewalld documentation: Open a Port or Service
• firewall-cmd manual page