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.

1. Confirm that firewalld is running before changing zone rules.

   $ sudo firewall-cmd --state
   running

   Related: Enable and start the firewalld service

2. 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

3. 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

4. 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.

5. Add the service to the permanent zone configuration.

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

6. Verify that the runtime zone includes the service.

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

7. Verify that the permanent zone configuration includes the same service.

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

8. 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.

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

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

10. 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

11. 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.