How to allow a service in firewalld

A packaged service can listen successfully while firewalld still blocks clients because the zone has no matching allow rule. A predefined firewalld service, such as http or https, opens the ports and helpers defined by the service profile instead of relying on a hand-entered port list.

firewall-cmd applies zone changes to either runtime state or permanent configuration. Adding the service without --permanent opens it immediately but loses the rule after a reload or restart; adding the same service with --permanent saves the rule that firewalld loads later.

The steps use the http service in the public zone and a client request to an HTTP listener as the smoke test. Replace the service and zone with the active traffic path on the host, especially on multi-interface servers where the default zone may not handle the application network.

Steps to allow a firewalld service:

Confirm that firewalld is running before changing zone rules.
```
$ sudo firewall-cmd --state
running
```
Related: Enable and start the firewalld service
Identify the zone that handles the application traffic.
```
$ sudo firewall-cmd --get-active-zones
public (default)
  interfaces: eth0
```
If no interface or source is listed, check the fallback zone with sudo firewall-cmd --get-default-zone before adding the service. Related: Check active firewalld zones
Inspect the predefined service profile.
```
$ sudo firewall-cmd --info-service=http
http
  ports: 80/tcp
  protocols: 
  source-ports: 
  modules: 
  destination: 
  includes: 
  helpers: 
```
Use sudo firewall-cmd --get-services when the service name is not known. If the application has no suitable predefined profile, create a custom service instead of opening unrelated raw ports. Related: Create a custom firewalld service
Add the service to runtime rules for immediate access.
```
$ sudo firewall-cmd --zone=public --add-service=http
success
```
Adding a service to the wrong zone can expose the application on an unintended network or leave the intended client path blocked.

Add the service to the permanent zone configuration.

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

Verify that the runtime zone includes the service.

$ sudo firewall-cmd --zone=public --list-services
dhcpv6-client http ssh

Verify that the permanent zone configuration includes the same service.

$ sudo firewall-cmd --permanent --zone=public --list-services
dhcpv6-client http ssh

Reload firewalld so the permanent configuration becomes the active runtime configuration.
```
$ sudo firewall-cmd --reload
success
```
A reload replaces runtime-only changes with the permanent configuration. If the permanent command was missed, the service disappears from the live rules after this step.

Confirm the service still appears in runtime rules after the reload.

$ sudo firewall-cmd --zone=public --list-services
dhcpv6-client http ssh

Query the permanent service rule when a yes or no result is clearer than a service list.
```
$ sudo firewall-cmd --permanent --zone=public --query-service=http
yes
```
Test the application from a client path that reaches the host through the same zone.
```
$ curl -sS http://web01.example.net/
firewalld service allow ok
```
The application must already be listening on the ports defined by the service profile. If the firewalld rule is present but the request still fails, check the service listener, routing, and upstream firewalls before widening the host rule.