Open a Firewalld Service or Port with firewall-cmd

Firewall-cmd is the command that tells you, in seconds, whether the firewall is the reason a service will not answer. This guide opens one named service or port right now, tests it from a real client, then saves the working rule so it survives a restart, with the exact command to undo it again. The examples match firewalld 2.1.1, supplied here by package firewalld 2.1.1-1.

Allow about ten minutes. You need shell access and a service managed by firewalld. Commands that query the firewall are normally unprivileged, but changing firewall state usually needs sudo or a root shell. Keep an existing SSH session open while changing a remote host: a bad rule is a lot less funny when it is the rule that locked you out.

1. Check the daemon and identify the active zone

Start with read-only checks. They do not change firewall rules:

$ firewall-cmd --state
$ firewall-cmd --get-default-zone
$ firewall-cmd --get-active-zones

• A healthy first command prints running. The default zone is used when you omit --zone.
• Active zones show which interfaces or sources are bound right now. On this machine, the installed client reports not running, so rule changes cannot work until the firewalld service is started by the system administrator.

2. Inspect the target zone before changing it

Replace public with the zone you selected. The command below is read-only and shows services, ports, interfaces and other settings:

$ firewall-cmd --zone=public --list-all

If you need to check an interface directly, use:

$ firewall-cmd --get-zone-of-interface=INTERFACE_NAME

Replace INTERFACE_NAME with a real interface such as enp1s0. A result of no zone means the interface is not directly bound to a zone; it does not tell you which zone a connection manager may select later.

3. Choose a service or an exact port

Prefer a predefined service when one describes the application. The http service, for example, represents web traffic without making you remember its port number:

$ firewall-cmd --get-services | tr ' ' '\n' | grep '^http$'

• The command prints http when that service is available. For an application-specific listener, use a port and protocol pair such as 8443/tcp instead.
• A port rule is not the same as starting a service. It only changes whether firewalld permits matching traffic; it will not make anything listen.
• Use the narrowest protocol and port the application needs. Opening both TCP and UDP, or a wide port range, increases exposure and makes later troubleshooting harder.

4. Apply a runtime change first

Runtime rules take effect now but are not retained after firewalld restarts. Use one of these examples, with elevated privileges:

$ sudo firewall-cmd --zone=public --add-service=http
success

$ sudo firewall-cmd --zone=public --add-port=8443/tcp
success

Do not run both examples unless the application really needs both. Both options can be repeated, and the port format is port, port-port, followed by /tcp, /udp or another supported protocol.

$ firewall-cmd --zone=public --query-service=http
$ firewall-cmd --zone=public --query-port=8443/tcp

A successful query exits with status 0. A valid query for a rule that is absent exits with status 1. To see the complete current zone, run firewall-cmd --zone=public --list-all again.

5. Test the application before saving the rule

Use a client from the intended network, not only a local process. For HTTP, for example:

$ curl --fail --connect-timeout 5 http://SERVER_ADDRESS/

Replace SERVER_ADDRESS with the host name or address that clients use. A successful connection proves that the path you tested is working; it does not prove that every source network or protocol is permitted.

If the test fails, inspect the listener and the selected zone before adding more rules:

$ ss -ltnp
$ firewall-cmd --zone=public --list-all

• Check for a listener bound only to 127.0.0.1. That is the classic culprit: the firewall was never the problem.
• Check the rule landed in the right zone. A rule in the wrong zone does nothing for the traffic you care about.
• Check for a host or cloud firewall outside firewalld. Do not keep opening ports to compensate for an application that is not listening.

6. Save only the tested runtime configuration

Once the application works and the rule is correct, make the same rule permanent. This explicit two-command pattern keeps the difference between immediate and persistent state easy to review:

$ sudo firewall-cmd --permanent --zone=public --add-port=8443/tcp
success
$ sudo firewall-cmd --check-config
success

The --permanent change is written to firewalld's permanent configuration but does not change the current runtime rules. Because you already added the runtime rule, clients keep working while you reload. A reload replaces runtime configuration with the permanent configuration, so the new rule then has to exist in both places.

7. Remove the rule when it is no longer needed

Removing a runtime rule does not remove its permanent counterpart. Remove both deliberately, and verify after each operation:

$ sudo firewall-cmd --zone=public --remove-port=8443/tcp
success
$ sudo firewall-cmd --permanent --zone=public --remove-port=8443/tcp
success
$ firewall-cmd --zone=public --query-port=8443/tcp
$ firewall-cmd --permanent --zone=public --query-port=8443/tcp

The two final queries should each return exit status 1. If a rule was added as a service, substitute --remove-service=http and --query-service=http.

8. Avoid the dangerous reload options

• Use --reload only when you mean to replace runtime rules with the permanent configuration. Any runtime-only changes not also saved permanently are lost.
• Keep --complete-reload for severe firewall problems. The manpage warns that it can terminate active connections because connection state is lost.
• Do not use --reset-to-defaults as a troubleshooting shortcut. It resets firewalld's configuration and can remove deliberate access controls.
• Treat the direct interface as a last resort. It is deprecated in firewalld 2.1.1; use services, ports, rich rules or policies where they fit.