SLES 15 – Common Problem 134 – 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

Services become unreachable because the interface ends up in the `public` zone with default-deny rules.

Environment & Reproduction

Occurs on SLES 15 after migrating from SuSEfirewall2 or after wicked changes interface names.

Root Cause Analysis

Interface-to-zone binding is not persisted in `/etc/firewalld/zones/*.xml` or NM connection.

Quick Triage

Check current binding with `firewall-cmd –get-active-zones`.

Step-by-Step Diagnosis

Examine `/etc/firewalld/zones/` and the NetworkManager keyfile for ZONE assignments.

Solution – Primary Fix

Move the interface to the correct zone with `firewall-cmd –zone=internal –change-interface=eth0 –permanent` and reload.

Solution – Alternative Approaches

Set the zone via NetworkManager connection profile to survive reboots.

Verification & Acceptance Criteria

Expected services answer on the correct interface after `firewall-cmd –reload`.

Rollback Plan

Reassign interface to `public` if the change accidentally exposes new ports.

Prevention & Hardening

Manage firewalld policy via Salt or AutoYaST and audit `–list-all-zones` regularly.

Related Errors & Cross-Refs

Pairs with `WARNING: ZONE_CONFLICT` and dropped packets in nftables logs.

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

View all sles-15 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

SUSE firewalld migration and zone administration documentation.