iptables Rule Generator

Rule output:

Primary rule output stays visible for the normal firewall-rule workflow.

{{ result.valid ? 'Run the check command and confirm persistence before applying.' : 'Resolve validation issues before copying.' }}

Rule preset:

Start from a narrow allow or deny pattern, then adjust the exact match below.

Address family:

Dual-stack output requires source and destination to be any; generate separate rules when each family needs different CIDRs.

Backend profile:

Use system default when you do not know the host alternatives; pick nft or legacy when the fleet standard is explicit.

Distribution target:

This does not contact the host; it changes the review and persistence artifacts you export with the rule.

Persistence target:

Runtime-only output is useful for tests; production strictness requires a non-runtime persistence target.

Rule-review strictness:

Use production strictness before exporting a command for a change window or remote host.

Chain:

Use INPUT for traffic to this host, OUTPUT for traffic from this host, and FORWARD for routed traffic.

Target action:

ACCEPT and DROP are terminal decisions; LOG records a match and then evaluation continues.

Protocol:

Choose TCP or UDP for service ports, ICMP for ping-style rules, or All for address/interface rules.

Port match:

Use values like 22, 80,443, or 8000-8080; leave blank only when the rule must match every port.

ICMP type:

Echo-request is the usual inbound ping match; Any leaves ICMP type unrestricted.

Source CIDR or IP:

Use the narrowest source you can, for example 203.0.113.0/24 or 198.51.100.10/32.

Destination CIDR or IP:

Destination is usually any for INPUT rules and a host or subnet for OUTPUT/FORWARD rules.

Input interface:

Optional; examples include eth0, ens3, wg0, or br-lan.

Output interface:

Optional; useful on OUTPUT, FORWARD, gateway, and VPN rules.

Fix before applying

{{ error }}

Rule operation:

Append is safest for review; Insert changes order-sensitive behavior.

Insert position:

Use 1 only when the rule must outrank the current chain entries.

position

Port direction:

Destination is the normal service-port match for inbound or outbound allows.

Conntrack state:

NEW,ESTABLISHED is common for a service allow; Any omits conntrack matching.

Reject response:

tcp-reset is only valid with TCP; ICMP reject types fit non-TCP IPv4 rules.

Prefix sudo:

Turn off when pasting into a root shell or automation that already runs as root.

Rule comment:

Keep it short and specific; long comments may not fit older iptables comment limits.

{{ result.commandText }}

{{ header }}	Copy
{{ cell }} {{ cell }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A Linux firewall rule is a precise packet decision written in a compact command: match these conditions, then take this action. That compactness is useful during a change window, but it also hides risk. A single source address, chain, port, or target can separate a narrow service allow from an exposed management port.

iptables rules are evaluated inside ordered chains. INPUT covers packets addressed to the local host, OUTPUT covers packets created by the host, and FORWARD covers routed traffic passing through the host. If a packet misses a rule, evaluation moves to the next rule. If it matches a target such as ACCEPT, DROP, REJECT, or LOG, that target controls what happens next.

Match: The address family, protocol, CIDR, port, interface, and connection state tests that narrow which packets a rule catches.
Target: The action reached after all match tests pass, such as accepting, dropping, rejecting, logging, or returning to a caller chain.
Backend: The command family used on the host, which may be legacy xtables, iptables-nft compatibility, or a distribution default alternative.
Persistence: The host-specific method that makes runtime firewall changes survive reboot or service reload.

iptables packet decision flow through chain, match tests, and target action.

Common host-firewall changes are small and specific: allow HTTPS from an office CIDR, permit SSH from one administrator address, allow outbound DNS to a resolver, drop one noisy source, or let a monitoring subnet send ping. Each change raises the same review questions. Which chain sees the packet? Which address family is in use? Is a service port required? Should connection tracking narrow the match? Which firewall manager owns durable policy on the host?

A syntactically valid iptables command is not the same as a safe firewall change. Existing rule order, default chain policy, remote access, backend ownership, and reboot persistence can all change the real outcome. Treat any generated command as a reviewable specimen that still needs duplicate checks, chain listing, and a rollback plan before it reaches a production shell.

How to Use This Tool:

Start with the host context, then narrow the packet match until the command matches the intended change and review standard.

Choose a Rule preset such as HTTPS from an office CIDR, SSH from one admin IP, outbound DNS, one noisy source drop, monitoring ping, IPv6 HTTPS, or dual-stack HTTPS. The preset only seeds the fields; every match remains editable.
Set Address family. IPv4 emits iptables, IPv6 emits ip6tables, and dual-stack emits paired IPv4 and IPv6 commands only when source and destination are any.
Set Backend profile, Distribution target, Persistence target, and Rule-review strictness. These choices shape compatibility and persistence review rows without inspecting the target host.
Pick Chain, Target action, and Protocol. For TCP or UDP, enter numeric ports, comma-separated numeric ports, or one inclusive range. For ICMP, choose a type or leave it unrestricted.
Enter Source CIDR or IP and Destination CIDR or IP as any, a host address, or a CIDR matching the selected address family. Add Input interface or Output interface only when the rule must bind to a named device.
Open Advanced for append, insert, check, or delete operation, insert position, port direction, conntrack state, reject response, sudo prefix, and rule comment.
Fix validation errors before copying. Production strictness turns ambiguous backend selection, runtime-only persistence, missing comments, broad ACCEPT source scope, missing TCP/UDP service ports, and ACCEPT rules without conntrack state into blockers.
Review Rule Output, Rule Audit Ledger, Compatibility Review, and Persistence Notes together. Copy or download the command only after the duplicate check, chain listing, and persistence notes make sense for the host.

Interpreting Results:

iptables command ready means the visible fields produced command text and no blocking validation error remains. It does not prove that the rule belongs on the host. iptables rule needs review means command generation is blocked until the listed errors are fixed.

iptables result tabs and review meaning
Result tab	What to read first	What to verify before use
Rule Output	The generated command or paired family commands.	Run the generated check command before an append or insert change, and confirm the command belongs in the current change window.
Rule Audit Ledger	The selected chain, operation, family, backend, ports, CIDRs, conntrack state, target, and comment.	Confirm every flag maps to the intended packet path. A wrong chain can make a correct-looking command ineffective.
Compatibility Review	Ready, Review, Blocked, Strict, and Info rows for syntax, source scope, service scope, conntrack, persistence, audit trail, backend, and warnings.	Resolve broad ACCEPT scope, runtime-only persistence, missing comments, and backend ambiguity before remote or production changes.
Persistence Notes	Duplicate checks, apply command, chain listing, save or restore hints, and manager-handoff reminders.	Verify which service or firewall manager reloads rules after reboot. Runtime changes can disappear.
JSON	The same command, warnings, errors, parameters, review rows, and persistence notes in structured form.	Use it for review records or automation handoff, not as proof that the target host accepted the command.

The strongest warning signs are broad ACCEPT rules, broad DROP rules, unknown backend ownership, and runtime-only persistence. They can be syntactically valid while still exposing a service, blocking remote access, or disappearing after reboot.

Technical Details:

iptables and ip6tables maintain packet-filter rules in the Linux kernel. The generated command model focuses on the filter-table workflow with the built-in INPUT, OUTPUT, and FORWARD chains. Append places a rule at the end, insert can place it near the head of a chain, check tests whether the same rule specification already exists, and delete removes a matching rule specification.

A rule specification combines match clauses with one target. Address matches use -s and -d, service matches use TCP or UDP port flags, stateful matches use conntrack state, and comments add a reviewable note to later chain listings. When validation passes, the command is assembled in the order a shell user would expect to review it: binary, operation, chain, match clauses, comment, and target.

Rule Core:

iptables command construction map
Command part	Generated when	Meaning
`iptables`, `ip6tables`, `iptables-nft`, or legacy variant	Always, when validation passes.	Selects the address family and backend profile used by the command.
`-A`, `-I`, `-C`, or `-D`	Selected by `Rule operation`.	Appends, inserts, checks, or deletes the rule specification in the selected chain.
`-p`	Any protocol except `All protocols`.	Limits matching to TCP, UDP, ICMP, or IPv6 ICMP syntax.
`-s` and `-d`	Source or destination is not `any`.	Restricts matching to a host address or CIDR block.
`--dport`, `--sport`, `--dports`, or `--sports`	TCP or UDP has one or more numeric port values.	Matches one port, one inclusive range, or a compact multiport list.
`-m conntrack --ctstate`	Conntrack state is not `Any state`.	Matches connection state such as `NEW`, `ESTABLISHED`, `RELATED`, or `INVALID`.
`-m comment --comment`	A rule comment is present.	Adds an audit note that can be checked later with chain listings.
`-j`	Always, when validation passes.	Sets the target reached when every match clause succeeds.

Validation and Review Rules:

Validation checks for generated iptables rules
Area	Accepted shape	Blocked or warned case
Ports	Numeric ports from 1 to 65535, comma-separated ports, or one inclusive range such as `8000-8080`.	Service names are blocked. More than 15 comma-separated entries are blocked before command output.
Source and destination	`any`, an IPv4 address or CIDR for IPv4, or an IPv6 address or CIDR for IPv6.	Dual-stack output blocks family-specific CIDRs and asks for separate IPv4 and IPv6 rules.
Interfaces	Up to 32 characters using letters, numbers, underscore, dot, colon, plus, or hyphen.	Unexpected characters are blocked to prevent malformed command text.
Reject response	Default response, selected ICMP reject types, or `tcp-reset`.	`tcp-reset` is blocked unless the protocol is TCP.
Rule comment	Up to 256 characters.	Longer comments are blocked. Production strictness also blocks missing comments.
Production strictness	Explicit backend, durable persistence target, comment, narrow ACCEPT source, service port for TCP or UDP, and conntrack on ACCEPT.	Any missing production guardrail becomes a blocker instead of a warning.

Modern distributions can route iptables syntax through iptables-nft compatibility or a firewall manager, while older systems may still use legacy xtables. Backend and persistence selections make that review visible, but the target host remains the authority for installed binaries, active managers, loaded rules, and reboot behavior.

Limitations and Responsible Use:

The command is generated from visible parameters in the browser. It does not contact the target host, inspect existing rules, detect loaded firewall managers, test remote access, or save policy after reboot.

Run the generated duplicate check before applying an append or insert rule.
List the target chain after applying so rule order, target, and comment can be verified.
Keep a rollback path and a second administrative session before changing remote access rules.
Do not mix direct runtime iptables commands with firewalld, native nftables, or another manager until policy ownership is clear.

Worked Examples:

Allow HTTPS from an office CIDR

With Rule preset set to HTTPS from office CIDR, Chain set to INPUT, Protocol set to TCP, Port match set to 443, Source CIDR or IP set to 203.0.113.0/24, and Conntrack state set to NEW,ESTABLISHED, Rule Output produces an ACCEPT command for destination port 443. Compatibility Review can still show review rows for system-default backend or runtime-only persistence, so resolve those rows before a durable production change.

Generate a dual-stack service allow

For a public HTTPS service that should accept both IPv4 and IPv6 traffic, set Address family to dual-stack and leave source and destination as any. Rule Output emits sibling iptables and ip6tables commands, and Compatibility Review marks address-family output as informational. If the IPv4 and IPv6 source ranges differ, dual-stack validation blocks the CIDR and asks for separate family-specific rules.

Catch a production strict failure

An ACCEPT rule with Source CIDR or IP set to any, no comment, Backend profile left at system default, and Persistence target left at runtime-only may be valid shell syntax in standard review. After Rule-review strictness is changed to production, the status changes to iptables rule needs review. Narrow the source, choose an explicit backend, pick a persistence target, add a comment, and keep conntrack state on the ACCEPT rule.

FAQ:

Can I paste the command directly into a remote shell?

Only after review. Run the generated check command, confirm the target chain order, and keep a rollback path before changing rules that affect SSH, VPN, or management access.

Why does dual-stack block my CIDR?

A single CIDR cannot represent both IPv4 and IPv6. Dual-stack mode requires source and destination to be any; use separate IPv4 and IPv6 rules when each family needs its own CIDR.

Can I enter service names like https or ssh?

No. Port match accepts numeric ports, comma-separated numeric ports, or one numeric range. Service names are blocked so the command text stays explicit.

Does LOG block matching traffic?

No. LOG records a match and evaluation continues. Add a later ACCEPT, DROP, REJECT, RETURN, or manager policy if logged traffic needs a final decision.

Will the generated command survive reboot?

Not by itself. Runtime-only output changes the live table only. Use Persistence Notes to review save, restore, or manager-handoff steps for the selected distribution target.

Glossary:

Chain: An ordered list of rules such as INPUT, OUTPUT, or FORWARD.
CIDR: A compact IP network format such as 203.0.113.0/24 or 2001:db8:100::/48.
Conntrack: Linux connection tracking state used to match packets as NEW, ESTABLISHED, RELATED, or INVALID.
Target: The action reached after all match conditions pass, such as ACCEPT, DROP, REJECT, LOG, or RETURN.
Backend: The iptables command family active on a host, such as iptables-nft compatibility or legacy xtables.
Persistence: The method that saves or reloads firewall policy so rules do not vanish after reboot or manager refresh.

References:

iptables and ip6tables manual page, Linux man-pages.
iptables-extensions manual page, Linux man-pages.
What is nftables?, nftables wiki.
Main differences with iptables, nftables wiki.
Moving from iptables to nftables, nftables wiki.