Fix iptables and nftables Coexistence Issues (2026)

iptables is failing to apply rules, or nftables is reporting errors about iptables modules.

This happens because iptables and nftables are fundamentally different packet filtering frameworks that, when running concurrently, can conflict over kernel-level netfilter hooks and data structures. nftables is the modern replacement, designed to be more efficient and flexible, but older systems or specific applications might still rely on iptables’s older rule-writing syntax and kernel module interfaces. When both are active, they can step on each other’s toes, leading to unpredictable behavior or outright failures.

Here are the common causes and how to fix them:

iptables-nft backend running instead of iptables-legacy:
- Diagnosis: Check which iptables backend is active. On systems using nftables as the primary backend for iptables compatibility, iptables commands might be translated into nftables rules. You’ll often see errors related to nftables syntax or "no such file or directory" for iptables modules that don’t map directly. Run iptables -V. If the output includes nft in the version string (e.g., iptables v1.8.7 (nf_tables)), you’re using the iptables-nft backend.
- Fix: If you need to run native iptables rules without nftables translation, you must switch to the iptables-legacy backend. This is typically done by installing the iptables-legacy package and disabling iptables-nft.
  - On Debian/Ubuntu:
```
sudo apt-get update
sudo apt-get install iptables-legacy
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy
```
  - On RHEL/CentOS/Fedora (if iptables-nft is installed, remove it):
```
sudo systemctl stop firewalld # If firewalld is active
sudo systemctl stop iptables
sudo yum remove iptables-nft
sudo yum install iptables-legacy # Or equivalent package name
sudo systemctl start iptables
```
- Why it works: This forces the iptables command to use its original, direct kernel interface instead of translating its commands to nftables syntax. This avoids conflicts arising from the translation layer.
nftables service running and managing rules:
- Diagnosis: Check if the nftables service is active and loaded with rules. Run sudo systemctl status nftables. If it’s active and has rules loaded (e.g., sudo nft list ruleset), it’s actively managing the netfilter hooks. You might see iptables commands failing with messages like iptables: No chain/target/match by that name.
- Fix: Stop and disable the nftables service if you intend to use iptables exclusively.
```
sudo systemctl stop nftables
sudo systemctl disable nftables
```
  Then, ensure your iptables rules are loaded correctly using iptables-save and iptables-restore or by a systemd service that manages iptables.
- Why it works: This removes nftables from actively managing the kernel’s netfilter hooks, preventing it from overwriting or interfering with iptables’s rule set.
firewalld service running and managing rules:
- Diagnosis: firewalld is a dynamic firewall management tool that often uses nftables as its backend but can also interact with iptables. If firewalld is active and configured, it will manage the netfilter rules. Check its status: sudo systemctl status firewalld. You might see iptables commands failing because firewalld has locked or modified the rules.
- Fix: Stop and disable firewalld if you want to manage rules directly with iptables.
```
sudo systemctl stop firewalld
sudo systemctl disable firewalld
```
  Then, load your iptables rules.
- Why it works: firewalld takes control of the netfilter framework. Disabling it allows iptables to manage the rules directly without firewalld intervening.
Conflicting iptables and nftables rule sets in persistence:
- Diagnosis: Even if one service is stopped, its rules might persist in the kernel. If you previously ran iptables and then switched to nftables (or vice-versa) without flushing the rules, the old rules are still active. Check the active ruleset with sudo iptables -L -n -v and sudo nft list ruleset. You might see duplicate or conflicting rules.
- Fix: Before switching between iptables and nftables, flush all existing rules for both.
  - For iptables:
```
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
```
  - For nftables:
```
sudo nft flush ruleset
```
  Then, load the rules for the desired framework.
- Why it works: This ensures that no stale rules from the previously active framework remain in the kernel’s netfilter hooks, preventing conflicts.
Kernel module conflicts (nf_tables vs. iptable_filter):
- Diagnosis: In rare cases, specific kernel modules for packet filtering might conflict. If you see errors like "module iptable_filter not found" when running iptables, or nftables failing to load its modules, it could be a conflict. Check loaded modules with lsmod | grep nf_.
- Fix: Ensure that only one primary filtering mechanism’s modules are loaded and active. If nftables is intended to be the sole manager, ensure iptables modules are not loaded or are managed by iptables-nft. If iptables is primary, ensure nf_tables is not loaded or is handled by iptables-nft. Often, disabling firewalld or nftables services will correctly unload their associated kernel modules. If persistent, you might need to blacklist modules, but this is an advanced step and usually indicates a deeper system configuration issue.
```
# Example: To prevent nf_tables loading if not needed
echo "blacklist nf_tables" | sudo tee /etc/modprobe.d/blacklist-nf_tables.conf
sudo update-initramfs -u # On Debian/Ubuntu
# Or equivalent for your distribution
```
- Why it works: By preventing the conflicting kernel modules from loading, you ensure that the netfilter subsystem is not being managed by competing code paths, reducing the chance of low-level conflicts.
Incorrect iptables command syntax when using iptables-nft:
- Diagnosis: If you are intentionally using iptables-nft (as indicated by iptables -V output), but your iptables commands are failing with errors like iptables: No chain/target/match by that name or syntax errors, it’s because the iptables-nft backend has a slightly different mapping of iptables concepts to nftables. Some older iptables modules or complex syntax might not translate perfectly.
- Fix: Rewrite your iptables rules using nftables syntax directly or simplify them to be compatible with iptables-nft. For example, the REJECT target in iptables might need to be reject in nftables.
  - Old iptables rule: iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable
  - New nftables equivalent: nft add rule ip filter input tcp dport 22 reject with icmp type port-unreachable You can often use iptables-save and then nft --parse --noflush -f <(iptables-save) to see how iptables-nft translates rules, and then adjust.
- Why it works: This ensures your rules are expressed in a format that the iptables-nft backend can correctly translate into the underlying nftables framework, or by using nftables directly, you bypass the translation layer entirely.

After resolving these, the next issue you might encounter is a "port already in use" error if you try to start a service that binds to a port that is now being blocked by a firewall rule, or if iptables commands still fail due to a subtle, un-flushed rule.