On Rocky Linux 9, open a port in the firewalld zone that handles the incoming connection. Apply the rule to both runtime and permanent configuration if it must work immediately and survive a reboot.
The example below opens TCP port 8080 on a host where firewalld is already running. Replace the zone and port with your actual requirements. On a remote server, keep your existing SSH session and console recovery access available while changing firewall rules.
On this page
Identify the active zone and listening application
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo ss -lntpIf firewalld reports that it is not running, inspect the current firewall design before enabling another firewall manager. In the active-zone output, identify the incoming interface or source assignment. The default zone alone does not prove which zone will handle a particular client.
In ss, find the application port and bind address. A process listening only on 127.0.0.1:8080 will not become remotely reachable just because a firewall rule is added.
Add the runtime and permanent rules
The following example assumes the appropriate zone is public. Opening a port without a source restriction permits matching traffic from any source covered by that zone, subject to other applicable rules. For an internal application, consider a narrower source-specific policy.
sudo firewall-cmd --zone=public --add-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --add-port=8080/tcpThe first command changes the running configuration. The second saves the rule for future reloads and boots. Both are applied here, so a reload is unnecessary for this addition. For a UDP service, use the required /udp rule; TCP and UDP permissions are separate.
Verify both configurations and a real connection
sudo firewall-cmd --zone=public --query-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --query-port=8080/tcp
sudo firewall-cmd --zone=public --list-allA yes result confirms that the queried port entry exists in that configuration. It does not confirm the application is healthy or the full network path is open. From an authorized remote client, test the service with its own protocol; for an HTTP application, replace the example address below with the server address.
curl --connect-timeout 5 http://SERVER_ADDRESS:8080/| Result | What to inspect |
|---|---|
| HTTP response, including an application error | The service answered; investigate application behavior if the response is unexpected. |
| Connection refused | Listener, bind address, port, and any rejecting rule along the path. |
| Timeout | Routing, selected zone, host rules, upstream firewall, and cloud security policy. |
Use a named service when appropriate
For a standard service, inspect its firewalld definition before using it. This HTTPS example is an alternative for an application actually listening on the ports in that definition; it is not an additional requirement for TCP 8080.
sudo firewall-cmd --info-service=https
sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --add-service=httpsIf the application still fails with the network path confirmed, inspect its logs and relevant SELinux denials. Opening a firewall port does not change SELinux policy. Choose the service-specific correction supported by the evidence.
Remove an unneeded rule
sudo firewall-cmd --zone=public --remove-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --remove-port=8080/tcpRemove the same entry type you added. An independently enabled service definition or rich rule may still allow the port. If you use --reload, firewalld replaces runtime configuration with permanent configuration; review unrelated runtime-only changes first.
References checked on October 23, 2026. These commands follow firewalld documentation; no production firewall was changed to validate this article.
References
firewalld: opening a port or service
firewalld: runtime versus permanent configuration
