iptables List All Rules on Linux

To run an iptables list all rules check, start with sudo iptables -L -n -v --line-numbers for a readable view of the default table, then use sudo iptables -S for command-style rules and sudo iptables-save for a complete parseable dump. If you use NAT or mangle rules, list those tables explicitly.

Firewall rules are easy to misread. A server can have rules in multiple tables, default policies on chains, nft-backed compatibility layers, and provider-level firewalls outside the VPS. This guide shows practical commands and how to interpret them without changing the firewall.

Key takeaways

• Use sudo iptables -L -n -v --line-numbers for a readable rule list with counters and rule numbers.
• Use sudo iptables -S to print rules in a command-like format.
• Use sudo iptables-save when you need a full export-style view.
• Add -t nat, -t mangle, or another table name when rules are not in the default filter table.
• Use -n to avoid slow DNS and service-name lookups.
• For related firewall reading, see the Virtarix guides to iptables port forwarding, VPS security, Fail2ban basics, and systemctl basics.

Before you inspect iptables rules

Listing rules is normally a read-only operation, but you still need appropriate privileges to read the kernel firewall state. On most systems, use sudo. If a command returns permission errors in a container, restricted VPS, or managed environment, test on the actual server or use the provider’s console and firewall tools.

Also remember that iptables may be only one layer. A cloud firewall, hosting panel, load balancer, security group, application firewall, or nftables configuration can affect traffic before or after iptables.

Step 1: list rules in the default filter table

Run:

“`bash title="List filter rules with counters and line numbers" sudo iptables -L -n -v –line-numbers

This lists chains in the default filter table. The common chains are `INPUT`, `FORWARD`, and `OUTPUT`. The options make the output more useful:

- `-L` lists rules.
- `-n` keeps addresses and ports numeric.
- `-v` adds packet and byte counters.
- `--line-numbers` shows rule numbers for each chain.

Line numbers are especially useful before deleting or inserting a rule. Do not delete by line number until you have confirmed the table and chain, because numbering is per chain and can change after edits.

## Step 2: print rules in command format

Run:

```bash title="Print filter rules in command format"
sudo iptables -S

This prints rules in a format closer to commands, with chain policies and append-style rules. It is easier to copy into notes, compare between servers, or read during a review. The -S view is often clearer than the table view when you want to understand rule logic.

For example, a rule that appears as columns in -L output may appear as a direct -A INPUT ... -j ACCEPT style line in -S output.

Step 3: dump all rules with iptables-save

Run:

“`bash title="Export the active iptables ruleset" sudo iptables-save

This prints the rules in a complete save-style format. It includes table headers, chains, policies, rules, and commit markers. It is useful for backups, audits, diffs, and support tickets because it preserves more structure than a screenshot or partial list.

Do not paste a save output into restore commands unless you understand the effect. Listing and saving are safe inspection steps; restoring can replace active rules.

## Step 4: list NAT rules

The default `iptables -L` view does not show every table. NAT rules live in the `nat` table, so list them explicitly:

```bash title="List NAT rules with counters and line numbers"
sudo iptables -t nat -L -n -v --line-numbers

Use this when investigating port forwarding, masquerading, Docker networking, reverse proxy paths, or outbound translation. NAT rules can explain why packets are redirected even when the filter table looks simple.

For command-style NAT output, run:

“`bash title="Print NAT rules in command format" sudo iptables -t nat -S

## Step 5: list other tables when needed

Linux iptables can use multiple tables. The most common are:

- `filter`: regular allow/drop firewall rules.
- `nat`: address translation and port forwarding.
- `mangle`: packet alteration and marking.
- `raw`: connection-tracking exemptions.
- `security`: security framework integration on systems that use it.

List a specific table with:

```bash title="List mangle rules with counters and line numbers"
sudo iptables -t mangle -L -n -v --line-numbers

If you are auditing a server, check each table that is relevant to the issue instead of assuming all rules are in filter.

Step 6: understand counters and policies

In -L -v output, counters show packets and bytes that matched a chain or rule since the counters were last reset. High counters can identify active rules, but a zero counter does not always mean a rule is useless. The relevant traffic may not have occurred during the current counter window.

Chain policies matter too. A chain with policy DROP behaves differently from a chain with policy ACCEPT, even if the visible rules look similar. Always read the chain policy before interpreting individual rules.

Step 7: be aware of legacy and nft variants

Modern Linux distributions may provide iptables commands backed by nftables, while older systems may use legacy iptables. The command names can look the same even when the backend differs. Check the version output and the distribution’s firewall tooling if behavior looks inconsistent.

This matters when you compare servers. A rule dump from one backend may not tell the full story on another system. In mixed environments, record the command output and the version when you document firewall state.

Common mistakes

Listing only the filter table

NAT, mangle, and raw rules can affect traffic. If the problem involves forwarding, translation, containers, or routing, inspect more than the default table.

Omitting numeric output

Without -n, listing can trigger name lookups and make output slower or less clear. Numeric output is usually better for firewall reviews.

Deleting by line number after another change

Line numbers can change after rule edits. List the chain again immediately before deleting by number.

Assuming iptables is the only firewall

Provider firewalls, UFW, nftables, Docker rules, and application-level controls can all affect traffic. iptables output is important, but it may not be the whole path.

VPS firewall review checklist

Before changing a rule, capture:

1. sudo iptables -L -n -v --line-numbers.
2. sudo iptables -S.
3. sudo iptables-save.
4. NAT table output if forwarding or Docker is involved.
5. Version and backend details.
6. Provider firewall or panel firewall state.
7. A rollback note for the change you intend to make.

That evidence helps you avoid accidental lockouts and gives another administrator enough context to review the firewall safely.

FAQ

What command lists all iptables rules?

Use sudo iptables -L -n -v --line-numbers for a readable view, and sudo iptables-save for a fuller save-style dump.

How do I list NAT rules in iptables?

Use sudo iptables -t nat -L -n -v --line-numbers or sudo iptables -t nat -S.

What is the difference between iptables -L and iptables -S?

iptables -L shows a table-style listing. iptables -S prints rules in a command-style format that is often easier to compare or copy into notes.

Why does iptables show no rules but traffic is blocked?

You may be looking at the wrong table, the wrong backend, a provider firewall, UFW/nftables rules, Docker networking, or an application-level firewall.

Summary

For an iptables list all rules review, use more than one view. Start with sudo iptables -L -n -v --line-numbers, add sudo iptables -S, and capture sudo iptables-save for a complete reference. Check table-specific output when NAT, forwarding, or packet marking is involved.

Read firewall output before changing it. On a VPS, the safest rule change is one made after you understand the table, chain, policy, backend, and rollback path. Keep the original SSH session open during remote firewall work, and avoid making several rule changes at once. Small, documented changes are easier to audit, review, test, and reverse safely later during incidents.