Confirm firewalld is the intended rule manager and record existing active zones. Identify the management port and source network, and keep console recovery available. Avoid changing panel-managed firewall policy outside that panel's supported workflow.

1. Inspect firewall-cmd --get-active-zones and the selected zone's complete settings. Check interface and source assignments rather than assuming the default zone controls every connection.
2. Review the service definition or exact port/protocol needed. Add a scoped runtime rule to the intended zone during a controlled test; use source restrictions for administrative services where appropriate.
3. Test a fresh connection and application behavior. Confirm unrelated ports have not become exposed through a broadly trusted zone.
4. Save the accepted policy permanently using the intended firewalld workflow. If copying runtime configuration to permanent, review all runtime changes first so unrelated temporary allowances are not saved accidentally.
5. Reload through the supported mechanism and retest. Verify NetworkManager interface-zone settings remain consistent with the intended policy.

On a Linux server managed by firewalld, start with the active-zone list. Replace public in the following two commands with the zone attached to the actual network interface or source address. Run as an administrator; all three commands only display policy.

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

Read the result: The second command shows the running rules and the third shows the saved rules used after a reload or restart. An allowed service in another zone does not necessarily apply to your connection. A rule present only at runtime can disappear later, while a saved rule may not yet be active.

Record both states before planning a change. Also check the provider network firewall and the actual service listener. Opening a port in firewalld cannot start a stopped application or bypass an upstream restriction.

A runtime-only change is not necessarily saved permanently. Review and persist the intended rule, then verify the runtime result after reload rather than assuming both configurations match.

Compare runtime and permanent rules, active zone assignments and external test results. Check both address families and any provider firewall. Confirm management access survives a new connection after reload.

If a rule appears ineffective, inspect which zone receives the traffic and whether the service is actually listening. Do not place an internet-facing interface into trusted merely to make a connection work. Restore the previous scoped rule through the console if a reload blocks access.

• Changing an AlmaLinux or Rocky Linux address with NetworkManager
• Finding which process listens on a Linux network port
• Recovering from an SSH lockout using the server console
• Applying Ubuntu Server security updates with a restart plan

• firewalld.org: Open A Port Or Service
• firewalld.org: Runtime Versus Permanent
• firewalld.org: Zone

• firewalld command reference