SLES 16 – Common Problem 132 – Diagnosis and Fix

📖 ~1 min read

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution – Primary Fix
7. Solution – Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

Ports opened with `firewall-cmd` are blocked again after the next reboot.

Environment & Reproduction

Happens when admins use `firewall-cmd –add-port` without `–permanent`.

Root Cause Analysis

Runtime changes are not written to the permanent zone configuration.

Quick Triage

Verify current zone: `firewall-cmd –get-active-zones` and `firewall-cmd –list-all`.

Step-by-Step Diagnosis

Diff runtime vs permanent: `firewall-cmd –list-all –permanent`.

Solution – Primary Fix

Re-add rules with `–permanent` then run `firewall-cmd –reload`.

Solution – Alternative Approaches

Manage firewall rules declaratively via Ansible `ansible.posix.firewalld` module.

Verification & Acceptance Criteria

After reboot `firewall-cmd –list-all` matches the documented baseline.

Rollback Plan

Revert to a previous `/etc/firewalld` snapshot if a bad rule blocks management traffic.

Prevention & Hardening

Enforce `–permanent` usage via change-management runbooks and CI checks.

Related Errors & Cross-Refs

Often related to `nftables` rule conflicts when both are toggled.

Related tutorial: View the step-by-step tutorial for sles-16.

View all sles-16 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

firewalld manual and SLES 16 security guide.