LFCE 76 🐧 iptables — Persistence and Best Practices - KandZ

⏱️ Estimated read: 12 min | |

The previous chapters configured rules in the running kernel. Those rules exist only in memory, and a reboot removes them. The firewall that protected the server before the reboot is gone after it, and the server comes back with the default policies and no rules—which, if the default policy is DROP, means the server is unreachable. Persistence is the mechanism that saves the rules to a file and restores them at boot. The LFCE exam expects the candidate to know how to make the firewall survive a restart, and the method differs between Debian and RHEL families.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The best practices are the patterns that prevent the most common firewall failures: the lockout, the unreachable service, and the rule that is never evaluated because a more general rule precedes it. The order of the rules is the first defense, and the default policy is the second. The persistence layer is the third, and it is the one that determines whether the firewall is still there after the next reboot.

Key point: On Debian and Ubuntu, the iptables-persistent package provides the netfilter-persistent service that restores the rules from /etc/iptables/rules.v4 and /etc/iptables/rules.v6 at boot . On RHEL and its derivatives, the iptables-services package provides the iptables service that restores the rules from /etc/sysconfig/iptables . The rules must be saved explicitly after every change, or the saved file is stale.

Why persistence requires distribution-specific configuration

The Debian problem.

The iptables-persistent package installs a systemd service called netfilter-persistent that reads the saved rule files and applies them at boot . The package prompts for whether to save the current rules during installation, but the administrator must run netfilter-persistent save after every subsequent change. The saved files are /etc/iptables/rules.v4 and /etc/iptables/rules.v6 . The iptables-save > /etc/iptables/rules.v4 command writes the file directly, and the netfilter-persistent save command is the wrapper that writes both the IPv4 and IPv6 files .

The RHEL problem.

The iptables-services package provides the iptables service that reads the rules from /etc/sysconfig/iptables . The service iptables save command writes the current rules to that file, and the iptables-save > /etc/sysconfig/iptables command does the same thing directly . The service must be enabled with systemctl enable iptables so that it starts at boot, and firewalld must be disabled or masked if it is installed, because the two firewall managers conflict .

The lockout problem.

The most common firewall failure is the lockout: the administrator sets the default policy to DROP, forgets to allow SSH, and the remote session is terminated. The rules are in memory, so the session cannot reconnect, and the server must be accessed through a console or a rescue mode. The best practice is to allow SSH and the established connections before setting the DROP policy, and to keep a second SSH session open while making the changes . The iptables-apply command provides a timeout-based rollback: it applies the rules, prompts the administrator to confirm that the session is still alive, and reverts to the previous rules if the confirmation does not arrive within the timeout .

a. Persisting rules on Debian and Ubuntu

The iptables-persistent package is the standard method. It installs the netfilter-persistent service and creates the rule files.

# Install the package
sudo apt update
sudo apt install iptables-persistent

# Save the current rules
sudo netfilter-persistent save

# Verify the saved files
sudo cat /etc/iptables/rules.v4
sudo cat /etc/iptables/rules.v6

The installation prompts for whether to save the current IPv4 and IPv6 rules, and the netfilter-persistent save command writes the current rules to the files . The service is enabled automatically, and it restores the rules at boot. The netfilter-persistent reload command re-applies the saved rules without a reboot .

The iptables-save command can also write the file directly.

# Direct save
sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6

The direct command is useful when the administrator wants to control the file path or when the netfilter-persistent wrapper is not available. The iptables-restore command applies the file manually, which is useful for testing the saved rules before the reboot.

b. Persisting rules on RHEL and its derivatives

The iptables-services package provides the iptables service and the /etc/sysconfig/iptables file.

# Install the package
sudo dnf install iptables-services

# Disable firewalld and enable iptables
sudo systemctl mask firewalld
sudo systemctl enable iptables
sudo systemctl start iptables

# Save the current rules
sudo service iptables save
# Or: sudo iptables-save > /etc/sysconfig/iptables

The systemctl mask firewalld command prevents firewalld from starting, which is necessary because the two firewall managers conflict . The service iptables save command writes the current rules to /etc/sysconfig/iptables, and the iptables service reads that file at boot . The systemctl enable iptables command configures the service to start at boot.

The iptables-save command can write the file directly, and the iptables-restore command applies it manually.

# Direct save
sudo iptables-save > /etc/sysconfig/iptables

# Restore manually
sudo iptables-restore < /etc/sysconfig/iptables

The direct command is the same as the service iptables save command, but it gives the administrator more control over the file path.

c. Best practices and the lockout prevention

The best practices are the patterns that keep the firewall functional and the administrator connected.

# Allow loopback first
sudo iptables -A INPUT -i lo -j ACCEPT

# Allow established and related connections
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH before setting the DROP policy
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Set the default policy
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Save the rules
sudo netfilter-persistent save    # Debian
sudo service iptables save        # RHEL

The loopback and established-connection rules must come before the DROP policy, or the administrator’s own session is dropped . The SSH rule must be in place before the policy is changed, or the remote session is terminated and the server is unreachable. The iptables-apply command provides a safety net: it applies the rules, asks the administrator to confirm, and reverts if the confirmation does not arrive .

# Apply rules with a timeout-based rollback
sudo iptables-apply -t 30 /etc/iptables/rules.v4

The -t 30 option sets the timeout to thirty seconds. The command applies the rules, prompts for confirmation, and reverts if the administrator does not confirm within the timeout. This is the safest way to apply a new rule set on a remote server.

Complete Example Session

# ============================================
# PART 1: BUILD THE RULESET
# ============================================
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# ============================================
# PART 2: VERIFY THE RULES
# ============================================
sudo iptables -L INPUT -n -v --line-numbers
# Output shows the rules in order

# ============================================
# PART 3: SAVE THE RULES (DEBIAN)
# ============================================
sudo netfilter-persistent save
# Output: Rules saved to /etc/iptables/rules.v4 and rules.v6

# ============================================
# PART 4: VERIFY THE SAVED FILE
# ============================================
sudo cat /etc/iptables/rules.v4
# Output shows the saved rules in iptables-save format

# ============================================
# PART 5: TEST THE RESTORE
# ============================================
sudo netfilter-persistent reload
sudo iptables -L INPUT -n -v
# The rules are re-applied

# ============================================
# PART 6: SAVE THE RULES (RHEL)
# ============================================
sudo service iptables save
# Output: iptables: Saving firewall rules to /etc/sysconfig/iptables

# ============================================
# PART 7: VERIFY THE RHEL SAVED FILE
# ============================================
sudo cat /etc/sysconfig/iptables
# Output shows the saved rules

# ============================================
# PART 8: ENABLE THE SERVICE AT BOOT
# ============================================
sudo systemctl enable netfilter-persistent    # Debian
sudo systemctl enable iptables                # RHEL

# ============================================
# PART 9: USE iptables-apply FOR REMOTE CHANGES
# ============================================
sudo iptables-apply -t 30 /etc/iptables/rules.v4
# The command applies the rules and prompts for confirmation

# ============================================
# PART 10: VERIFY AFTER REBOOT
# ============================================
# After reboot:
sudo iptables -L INPUT -n -v
# The rules are restored from the saved file

The ten parts demonstrate the persistence workflow: building the rules, verifying, saving on Debian, verifying the file, testing the restore, saving on RHEL, verifying the RHEL file, enabling the service, using iptables-apply for remote changes, and verifying after reboot. The critical step is Part 9: iptables-apply provides the rollback safety net that prevents a lockout.

Quick Reference

Persistence Methods

Distribution	Package	Save Command	Restore File
Debian / Ubuntu	`iptables-persistent`	`netfilter-persistent save`	`/etc/iptables/rules.v4`
RHEL / Rocky	`iptables-services`	`service iptables save`	`/etc/sysconfig/iptables`

Manual Commands

Command	Purpose
`iptables-save > file`	Save current rules
`iptables-restore < file`	Apply saved rules
`ip6tables-save > file`	Save IPv6 rules
`iptables-apply -t N file`	Apply with timeout rollback

Best Practices

Practice	Reason
Allow loopback first	Local services need it
Allow established/related	Replies to outgoing connections
Allow SSH before `DROP`	Prevents lockout
Use `iptables-apply` for remote changes	Rollback on lockout
Save after every change	Persistence is explicit

Service Management

System	Enable Service	Disable Conflict
Debian	`systemctl enable netfilter-persistent`	—
RHEL	`systemctl enable iptables`	`systemctl mask firewalld`

Best Practices

✅ Do This:

# Allow loopback and established first
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # ✅

# Allow SSH before the DROP policy
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT # ✅

# Save after every change
netfilter-persistent save    # Debian
service iptables save        # RHEL                                     # ✅

# Use iptables-apply for remote changes
iptables-apply -t 30 /etc/iptables/rules.v4                             # ✅

# Disable firewalld on RHEL
systemctl mask firewalld                                                 # ✅

❌ Don’t Do This:

# Set DROP policy before allowing SSH
iptables -P INPUT DROP    # Locks out remote access                  # ❌

# Forget to save
# The rules are lost on reboot                                       # ❌

# Run firewalld and iptables-services together
# They conflict and produce unpredictable results                    # ❌

# Apply rules remotely without a rollback mechanism
# A mistake cannot be undone without console access                  # ❌

# Flush rules without considering the default policy
iptables -F    # DROP policy remains with no ACCEPT rules             # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Rules lost after reboot	Not saved	`netfilter-persistent save` or `service iptables save`
Locked out of SSH	`DROP` policy without SSH allow	Allow SSH first; use `iptables-apply`
Service not starting	`firewalld` conflict on RHEL	`systemctl mask firewalld`
Saved file stale	Changed rules after last save	Save after every change
`iptables-apply` not found	Package not installed	Install `iptables` or `iptables-utils`

Real-World Examples

1. Save on Debian

sudo netfilter-persistent save

2. Save on RHEL

sudo service iptables save

3. Direct save

sudo iptables-save > /etc/iptables/rules.v4

4. Restore manually

sudo iptables-restore < /etc/iptables/rules.v4

5. Enable Debian service

sudo systemctl enable netfilter-persistent

6. Enable RHEL service

sudo systemctl enable iptables

7. Disable firewalld

sudo systemctl mask firewalld

8. Apply with rollback

sudo iptables-apply -t 30 /etc/iptables/rules.v4

9. Allow SSH before DROP

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT && sudo iptables -P INPUT DROP

10. Verify after reboot

sudo iptables -L -n -v

Visual

Persistence Flow

┌──────────────────────────────────────────────────────────────┐
│  RULES IN MEMORY → SAVED FILE → RESTORED AT BOOT             │
│                                                              │
│  iptables -A ... (add rules)                                 │
│       │                                                      │
│       ▼                                                      │
│  Rules in kernel memory                                      │
│       │                                                      │
│       ▼                                                      │
│  netfilter-persistent save (Debian)                          │
│  service iptables save (RHEL)                                │
│       │                                                      │
│       ▼                                                      │
│  Saved file:                                                 │
│  /etc/iptables/rules.v4 (Debian)                             │
│  /etc/sysconfig/iptables (RHEL)                              │
│       │                                                      │
│       ▼                                                      │
│  At boot: netfilter-persistent / iptables service            │
│       │                                                      │
│       ▼                                                      │
│  iptables-restore < saved file                               │
│       │                                                      │
│       ▼                                                      │
│  Rules restored                                              │
└──────────────────────────────────────────────────────────────┘

Lockout Prevention

┌──────────────────────────────────────────────────────────────┐
│  ALLOW SSH BEFORE SETTING THE DROP POLICY                    │
│                                                              │
│  ❌ Incorrect:                                               │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ iptables -P INPUT DROP                                 │  │
│  │ # No SSH rule → session dropped                        │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  ✅ Correct:                                                 │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ iptables -A INPUT -p tcp --dport 22 -j ACCEPT          │  │
│  │ iptables -A INPUT -m conntrack --ctstate ESTABLISHED,  │  │
│  │   RELATED -j ACCEPT                                    │  │
│  │ iptables -P INPUT DROP                                 │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Use iptables-apply for remote changes:                      │
│  it reverts after a timeout if you lose the session.         │
└──────────────────────────────────────────────────────────────┘

iptables-apply Rollback

┌──────────────────────────────────────────────────────────────┐
│  iptables-apply PROVIDES A SAFETY NET                        │
│                                                              │
│  1. Save current rules to a temporary file                   │
│  2. Apply the new rules                                      │
│  3. Prompt: "Can you still connect?"                         │
│       │                                                      │
│       ├── Yes → keep the new rules                           │
│       │                                                      │
│       └── No answer within timeout → revert to old rules     │
│                                                              │
│  The default timeout is 10 seconds; use -t 30 for more.      │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Debian package	`iptables-persistent`
Debian service	`netfilter-persistent`
Debian save	`netfilter-persistent save`
Debian file	`/etc/iptables/rules.v4`
RHEL package	`iptables-services`
RHEL service	`iptables`
RHEL save	`service iptables save`
RHEL file	`/etc/sysconfig/iptables`
Manual save	`iptables-save > file`
Manual restore	`iptables-restore < file`
Rollback tool	`iptables-apply -t N file`
RHEL conflict	`systemctl mask firewalld`

Key takeaways:

The rules are not persistent by default. They exist in the kernel memory and are lost on reboot. The Debian iptables-persistent package and the RHEL iptables-services package provide the service and the file that restore them at boot .
The save command differs by distribution. On Debian, netfilter-persistent save writes /etc/iptables/rules.v4. On RHEL, service iptables save writes /etc/sysconfig/iptables. The iptables-save > file command works on both, but the file path determines which service reads it .
The loopback and established-connection rules must come first. The DROP policy applies to everything that is not explicitly allowed, including the replies to outgoing connections and the local loopback traffic. The rules for these must be in place before the policy is changed .
The SSH rule must be in place before the DROP policy. Setting the policy to DROP without allowing SSH terminates the remote session, and the server becomes unreachable. The iptables-apply command provides a timeout-based rollback for this case .
firewalld must be disabled on RHEL when using iptables-services. The two firewall managers conflict, and running both produces unpredictable results. The systemctl mask firewalld command prevents firewalld from starting .
Save after every change. The saved file is a snapshot, and it does not update automatically. A change that is not followed by a save is lost on the next reboot.

Remember: Persistence is the layer that makes the firewall survive the reboot. The rules are built in memory, saved to a file, and restored by a service at boot. The Debian and RHEL families use different packages and different file paths, but the principle is the same. The best practices are the patterns that prevent the lockout: allow loopback and established connections first, allow SSH before the DROP policy, and use iptables-apply for remote changes. The firewall is only as good as its persistence; a rule set that disappears on reboot is not a firewall, it is a temporary configuration.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!