The iptables NAT table isn’t available because the nf_nat kernel module isn’t loaded, preventing your system from performing network address translation.

Common Causes and Fixes

  1. nf_nat Module Not Loaded (Most Common)

    • Diagnosis: Run lsmod | grep nf_nat. If you see no output, the module is not loaded.
    • Fix: Manually load the module with sudo modprobe nf_nat.
    • Why it works: This command directly instructs the Linux kernel to load the nf_nat module into memory, making the NAT table functionality available.
  2. iptables-legacy vs. iptables-nft Conflicts

    • Diagnosis: Check which iptables backend is in use. Run iptables --version. If it mentions "legacy" and you’re expecting nftables NAT, or vice-versa, this is a conflict. Also, check if nftables service is running with sudo systemctl status nftables. If it is, and you intend to use iptables, it might be interfering.
    • Fix: If using iptables-legacy and need NAT, ensure nf_nat is loaded. If you want to use nftables for NAT (which is the modern approach), disable the iptables-legacy service (sudo systemctl stop iptables-legacy) and enable nftables (sudo systemctl enable nftables --now). If you must use iptables-legacy and nf_nat is loaded but still no NAT table, try reinstalling iptables to reset its configuration: sudo apt-get --reinstall install iptables (Debian/Ubuntu) or sudo dnf reinstall iptables (Fedora/RHEL).
    • Why it works: iptables can operate in either "legacy" (older Netfilter) or "nftables" backend modes. If the nftables service is active, it might be managing the NAT rules, and the iptables-legacy commands will fail to find their expected tables if they’re not configured to use the nftables backend. Forcing a reinstall can reset configurations that might be pointing to the wrong backend.
  3. Kernel Configuration Missing CONFIG_NF_NAT

    • Diagnosis: Examine your kernel configuration file, typically found at /boot/config-$(uname -r). Search for CONFIG_NF_NAT. If it’s commented out (# CONFIG_NF_NAT=m or # CONFIG_NF_NAT=y) or missing entirely, the kernel was compiled without NAT support.
    • Fix: This is a more involved fix requiring kernel recompilation. You would need to reconfigure your kernel to include CONFIG_NF_NAT (usually as a module, m), recompile it, and install the new kernel. After rebooting into the new kernel, sudo modprobe nf_nat should succeed.
    • Why it works: The kernel configuration dictates which features are compiled into the kernel or available as loadable modules. If CONFIG_NF_NAT is not enabled, the kernel simply doesn’t have the code to perform NAT operations, and no amount of module loading or service restarts will help until the kernel itself supports it.
  4. ip_tables Module Not Loaded (for iptables-legacy)

    • Diagnosis: Run lsmod | grep ip_tables. If nf_nat is loaded but you still can’t see the NAT table, the ip_tables module (which provides the core iptables functionality for the legacy backend) might be missing.
    • Fix: Load the ip_tables module with sudo modprobe ip_tables.
    • Why it works: The ip_tables module is fundamental to the iptables-legacy command-line utility. Even if nf_nat is present, without ip_tables, the iptables command won’t be able to interact with the Netfilter framework to manage tables like NAT.
  5. iptables Service Not Running/Enabled (if using a service wrapper)

    • Diagnosis: Check the status of the iptables service: sudo systemctl status iptables. If it’s not active, it might not have loaded its rules, including potentially the NAT table setup.
    • Fix: Start and enable the service: sudo systemctl start iptables and sudo systemctl enable iptables.
    • Why it works: On systems using systemd, services like iptables are responsible for loading predefined rulesets at boot. If this service isn’t running, the NAT table might not be initialized or populated with any rules, leading to perceived unavailability.
  6. Firewall Management Tools Overwriting iptables State

    • Diagnosis: If you use tools like firewalld or ufw, they often manage iptables rules. They might be configured to not use the NAT table or might be actively flushing/resetting it. Check their respective configurations (e.g., sudo firewall-cmd --list-all or sudo ufw status verbose).
    • Fix: If using firewalld and you need NAT, ensure the masquerade feature is enabled for the relevant zone: sudo firewall-cmd --zone=public --add-masquerade --permanent and sudo firewall-cmd --reload. If using ufw, you might need to edit /etc/ufw/before.rules or /etc/ufw/before6.rules to add NAT rules and then sudo ufw disable && sudo ufw enable. If you want iptables to manage NAT directly, disable firewalld or ufw: sudo systemctl stop firewalld && sudo systemctl disable firewalld or sudo ufw disable.
    • Why it works: Tools like firewalld and ufw abstract iptables management. They might have their own internal logic that prevents the NAT table from being used or configured in the way you expect, or they might simply be resetting iptables state to their own desired configuration, overwriting any manual NAT rules you’ve attempted to set.

After fixing these, the next error you might encounter is iptables: No chain/target/match by that name if you try to use a specific NAT target (like MASQUERADE) that isn’t actually defined or available in your current iptables setup, or if your ruleset is malformed.

Want structured learning?

Take the full Iptables course →