What is a chain in firewall terms?

A **chain** is an ordered list of rules. When a packet enters the kernel, the firewall walks the right chain top to bottom and applies the first rule that matches. The three built-in chains in the filter table are the ones this builder handles: **INPUT** (packets destined for this machine), **OUTPUT** (packets leaving this machine), **FORWARD** (packets passing through this machine, like a router). If you reach the end with no match, the chain's **default policy** kicks in. Chains can also have **custom names** for organizing rules, but the built-ins are where every ruleset starts.

What is the difference between INPUT, OUTPUT and FORWARD?

These are the three traffic directions a Linux box deals with. The **INPUT chain** sees packets **addressed to the local machine**: someone connecting to your SSH, your web server, your DNS resolver. This is the chain that protects your services. The **OUTPUT chain** sees packets your machine **sends out**: outbound HTTP, DNS lookups, API calls. Usually left wide open with policy ACCEPT because you trust your own software. The **FORWARD chain** sees packets that **arrive on one interface and leave on another**, without being addressed to the local machine. Only routers, gateways, NAT boxes and Docker hosts need FORWARD rules. On a regular server, FORWARD should be policy DROP and stay empty.

Why put ESTABLISHED,RELATED at the top?

Because the first rule a packet matches is the rule that wins, and **every reply packet** of every connection you allowed should match this single rule. Without it, you would need to write a reverse rule for every service: "allow incoming on 80" AND "allow outgoing reply from 80", which doubles the ruleset and breaks if you forget. Put this rule at position **1** of INPUT and FORWARD: `iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT` It matches packets that belong to a connection the kernel already tracks (ESTABLISHED) or a related one like an FTP data channel (RELATED). Result: you only need rules for **new** connections, the firewall handles the replies automatically.

What does conntrack actually do?

**Conntrack** is the kernel's connection tracker. For every TCP, UDP and ICMP flow it sees, conntrack records the source IP, destination IP, source port, destination port and current state (NEW, ESTABLISHED, RELATED, INVALID). The firewall can then match on **state** instead of having to write two rules per service. This is what makes a firewall **stateful**: the kernel knows "this packet is the reply to a connection I allowed five seconds ago" and decides accordingly. Modern firewalls use `-m conntrack --ctstate` (iptables) or `ct state` (nftables). The older `-m state --state` syntax still works for backwards compatibility but conntrack is the canonical one.

Stateful vs stateless, what is the practical difference?

A **stateless firewall** looks at each packet in isolation: source, destination, protocol, ports. To allow a website to reply to your request, you need an explicit rule for the reply. Ruleset doubles in size and you can leak responses you did not intend to allow. A **stateful firewall** remembers active connections in a table. To allow replies, one rule is enough: "anything that is part of an existing connection, accept". This is what `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT` does. The kernel knows the connection table; you write rules for **new** flows only. **Always use stateful matching** unless you are writing rules for a router that handles millions of packets per second and conntrack overhead is measurable.

Why set default policy to DROP?

**Deny by default** is the safe stance. With policy ACCEPT, you have to enumerate everything bad you want to block, which is an infinite list. With policy DROP, you enumerate the few things you want to allow, which is a short list (SSH, HTTP, HTTPS, return traffic). Anything you forgot is blocked, which is exactly what you want on a firewall. **Always lock yourself a way back in first**: write the ACCEPT rule for SSH on port 22 (or whatever you use), test it, then flip the policy to DROP. If you flip first you will be kicked out of your own server.

How do I persist firewall rules across reboots?

Rules added with `iptables` or `nft` live in memory and **disappear on reboot**. To make them survive: **Debian / Ubuntu (iptables)**: install `iptables-persistent`, then `sudo netfilter-persistent save`. Rules are written to `/etc/iptables/rules.v4` and `rules.v6` and reloaded on boot. **RHEL / CentOS (iptables)**: `sudo service iptables save` writes to `/etc/sysconfig/iptables`. **Any modern distro (nftables)**: save the output of `sudo nft list ruleset` to `/etc/nftables.conf` and enable the service: `sudo systemctl enable nftables`. On boot the service runs `nft -f /etc/nftables.conf` and the ruleset is restored. **Recommended workflow**: keep `/etc/nftables.conf` (or the iptables-save output) in version control. Treat the firewall like any other config file.

Does rule order matter?

**Yes, order matters a lot in iptables**. Rules in a chain are evaluated **top to bottom** and the **first match wins**. Subsequent rules are not checked. So this works: rule 1 = "ACCEPT SSH from 1.2.3.4", rule 2 = "DROP all SSH". And this is broken: rule 1 = "DROP all SSH", rule 2 = "ACCEPT SSH from 1.2.3.4" (the DROP wins, nobody gets in). **nftables is the same**: rules in a chain run top to bottom. Always put specific allows **before** broad drops. The builder lets you reorder rules with the up/down arrows on each row.

How do I test rules without locking myself out?

Three classic tricks. **1. Run a kill switch in another terminal**: `sudo nohup sh -c 'sleep 300; iptables -F; iptables -P INPUT ACCEPT' &`. If you mess up, the firewall flushes itself in 5 minutes. Open a second terminal before applying the new rules. **2. Schedule a flush with `at`**: `echo "iptables -F; iptables -P INPUT ACCEPT" | sudo at now + 10 minutes`. Same idea, cleaner. **3. Use `iptables-apply` (Debian) or `nft -c -f rules.conf`**: the apply tool requires you to confirm in 10 seconds or it rolls back. `nft -c` does a dry-run check on syntax. **Always have console / IPMI / KVM access** to your server before touching firewall rules on a remote box. SSH is the **only** thing keeping you connected; one wrong DROP and you are walking to the datacenter.

iptables / nftables Builder - free

Firewall builder

Preview syntax

Both panes on the right are always up to date, this toggle only highlights the active one.

PresetsClick to replace the active ruleset

Default chain policies

What happens when no rule matches

INPUT (traffic to this machine)

FORWARD (transit traffic)

OUTPUT (traffic from this machine)

Use conntrack instead of state (recommended)-m conntrack --ctstate is the modern way to match connection state. Old -m state --state still works.

Rules

Order matters. First matching rule wins.

1Rule 1

ChainAction

Protocol

Source IP (optional)Destination IP (optional)

Source port (optional)Destination port (optional)

Connection state

ESTABLISHED + RELATED lets return traffic of active connections through. NEW matches new attempts.

Comment (optional)

iptableslegacy

# iptables-legacy ruleset
# Flush existing rules before applying
iptables -F
iptables -X

# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Rules
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -m comment --comment "allow return traffic"

# Save (Debian/Ubuntu): netfilter-persistent save
# Save (RHEL/CentOS):   service iptables save

nftablesmodern

# nftables ruleset (save as /etc/nftables.conf)
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state { established, related } accept comment "allow return traffic"
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

# Apply: sudo nft -f /etc/nftables.conf
# Persist on boot: sudo systemctl enable nftables

Safety tip: before applying rules on a remote box, open a second SSH session and set a kill switch (e.g. sleep 300 && iptables -F). If you lock yourself out, you still have a way back in.

What is this iptables / nftables rule builder?

A Linux firewall keeps unwanted traffic off your server. The two tools that ship with the kernel are iptables (the classic one, around since 1998) and nftables (the modern replacement, default on Debian 11+, Ubuntu 22.04+, RHEL 9+ and most current distros).

This builder lets you write firewall rules in a friendly form and produces both syntaxes at the same time. Pick a chain (INPUT, OUTPUT, FORWARD), pick an action (ACCEPT, DROP, REJECT, LOG), set the protocol, source, destination, ports and connection state, and you get a paste-ready ruleset.

Everything runs in your browser: no rules are applied, no server is contacted, nothing is uploaded. You copy the output, open your terminal, read it carefully, and run it yourself. The tool is a builder, not a runner.

A few things worth knowing before you start:

The default policy of a chain is what happens when no rule matches. Setting INPUT to DROP plus a few targeted ACCEPT rules is the classic "deny by default" stance.
Order matters in iptables: rules are evaluated top to bottom, first match wins. Put your return traffic rule (ESTABLISHED, RELATED) first to avoid breaking existing connections.
nftables is declarative (the whole table is one document); iptables is imperative (each `-A` line appends one rule).

How to use it

Start with a preset if you can: "Basic webserver", "Locked-down SSH", "Allow LAN, deny WAN", "Docker forward chain", or "Rate limit SSH". Each one fills in sensible defaults you can tweak.

Set the default policy per chain. The safe stance is INPUT=DROP, FORWARD=DROP, OUTPUT=ACCEPT. The OUTPUT policy is usually ACCEPT because you trust your own server to talk out.

Add rules in order. The very first INPUT rule should be: protocol=any, state=ESTABLISHED+RELATED, action=ACCEPT. This keeps existing connections alive when you reload the firewall.

For each rule pick the chain, action, protocol, optional source IP (or CIDR like 192.168.1.0/24), optional destination IP, optional source/destination port, and a connection state if you need stateful matching.

Use the conntrack toggle to choose between the modern `-m conntrack --ctstate` and the legacy `-m state --state`. Modern kernels default to conntrack; keep it on unless your distro is ancient.

Watch the live preview on the right. The top pane is iptables, the bottom pane is nftables. Both are kept in sync from the same model and both have a Copy button.

Test before you commit. Copy the iptables block, paste it on the server, run it. If you lock yourself out, the rules will not survive a reboot (they live in memory only). After 5 minutes of testing, persist them with `netfilter-persistent save` (Debian/Ubuntu) or save the nftables block into `/etc/nftables.conf`.

When this is useful

Five concrete situations where building rules in a form beats writing them by hand:

You set up a fresh VPS and need a starting firewall. The "Basic webserver" preset opens ports 22 (SSH), 80 (HTTP), 443 (HTTPS) and drops everything else. It is the canonical first step after installing a server, and the builder writes it once for both syntaxes so you can pick whichever your distro uses.
You are migrating from iptables to nftables. Many distros (Debian 11+, RHEL 9+) made nftables the default and the legacy `iptables` command is a wrapper. Paste your existing iptables rules into the form, switch the preview to nftables, and you have a ready-to-save `/etc/nftables.conf`.
You want to lock SSH to one IP. The "Locked-down SSH" preset shows the pattern: ACCEPT from your office IP, LOG and DROP everything else. Three rules, in the right order, with state matching included.
You manage a Docker host and the FORWARD chain is a mess. Docker rewrites the FORWARD chain on every restart, which is fine, but you still need to know what good FORWARD rules look like. The "Docker forward chain" preset is a clean baseline you can adapt.
You are teaching someone Linux networking. The side-by-side iptables vs nftables view is the fastest way to show the equivalence: same model, two syntaxes. Toggle a state, watch both panes update, and the relationship between `-m conntrack --ctstate` and `ct state` clicks instantly.

Questions and answers

nftables is the current default and the future. It replaced iptables in the Linux kernel networking stack and is the system tool on Debian 11+, Ubuntu 22.04+, RHEL 9+, Fedora 32+, Arch, and openSUSE. iptables is officially in long-term maintenance mode: it still works (and the `iptables` command on modern distros is usually a wrapper around nftables), but no new features are coming. Learn nftables for new work. Learn enough iptables to read old documentation and existing servers. This builder shows both so you can translate between them.

# iptables-legacy ruleset # Flush existing rules before applying iptables -F iptables -X # Default policies iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Rules iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -m comment --comment "allow return traffic" # Save (Debian/Ubuntu): netfilter-persistent save # Save (RHEL/CentOS): service iptables save

# nftables ruleset (save as /etc/nftables.conf) #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; ct state { established, related } accept comment "allow return traffic" } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } # Apply: sudo nft -f /etc/nftables.conf # Persist on boot: sudo systemctl enable nftables

What is this iptables / nftables rule builder?

A few things worth knowing before you start:

The default policy of a chain is what happens when no rule matches. Setting INPUT to DROP plus a few targeted ACCEPT rules is the classic "deny by default" stance.
Order matters in iptables: rules are evaluated top to bottom, first match wins. Put your return traffic rule (ESTABLISHED, RELATED) first to avoid breaking existing connections.
nftables is declarative (the whole table is one document); iptables is imperative (each `-A` line appends one rule).

How to use it

Start with a preset if you can: "Basic webserver", "Locked-down SSH", "Allow LAN, deny WAN", "Docker forward chain", or "Rate limit SSH". Each one fills in sensible defaults you can tweak.

Set the default policy per chain. The safe stance is INPUT=DROP, FORWARD=DROP, OUTPUT=ACCEPT. The OUTPUT policy is usually ACCEPT because you trust your own server to talk out.

Add rules in order. The very first INPUT rule should be: protocol=any, state=ESTABLISHED+RELATED, action=ACCEPT. This keeps existing connections alive when you reload the firewall.

Use the conntrack toggle to choose between the modern `-m conntrack --ctstate` and the legacy `-m state --state`. Modern kernels default to conntrack; keep it on unless your distro is ancient.

Watch the live preview on the right. The top pane is iptables, the bottom pane is nftables. Both are kept in sync from the same model and both have a Copy button.

When this is useful

Five concrete situations where building rules in a form beats writing them by hand:

You set up a fresh VPS and need a starting firewall. The "Basic webserver" preset opens ports 22 (SSH), 80 (HTTP), 443 (HTTPS) and drops everything else. It is the canonical first step after installing a server, and the builder writes it once for both syntaxes so you can pick whichever your distro uses.
You are migrating from iptables to nftables. Many distros (Debian 11+, RHEL 9+) made nftables the default and the legacy `iptables` command is a wrapper. Paste your existing iptables rules into the form, switch the preview to nftables, and you have a ready-to-save `/etc/nftables.conf`.
You want to lock SSH to one IP. The "Locked-down SSH" preset shows the pattern: ACCEPT from your office IP, LOG and DROP everything else. Three rules, in the right order, with state matching included.
You manage a Docker host and the FORWARD chain is a mess. Docker rewrites the FORWARD chain on every restart, which is fine, but you still need to know what good FORWARD rules look like. The "Docker forward chain" preset is a clean baseline you can adapt.
You are teaching someone Linux networking. The side-by-side iptables vs nftables view is the fastest way to show the equivalence: same model, two syntaxes. Toggle a state, watch both panes update, and the relationship between `-m conntrack --ctstate` and `ct state` clicks instantly.

Questions and answers

iptables / nftables Builder

What is this iptables / nftables rule builder?

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

Port Reachability Check

Nginx Config Snippet Builder

systemd Unit Builder

iptables / nftables Builder

What is this iptables / nftables rule builder?

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

Port Reachability Check

Nginx Config Snippet Builder

systemd Unit Builder