All free tools Generated in your browser

iptables Rule Generator

Describe the firewall you want and receive both a runnable iptables command script and an iptables-save ruleset.

FIREWALL SETTINGS

Build an iptables ruleset

iptables
IP version
IPv4 and IPv6 are filtered by two separate rule sets. A server reachable over IPv6 needs both.
Default policies
Applied to arriving traffic that no rule matched.
Traffic routed through the server, for example for containers or a VPN.
Dropping outgoing traffic breaks DNS and package updates unless you add rules for them.
Baseline rules
Use the port your sshd actually listens on, between 1 and 65535.
Firewall rules

The first rule that matches a packet decides its fate, so order matters. Append puts a rule after the baseline rules; insert puts it at the very top of its chain.

A wrong firewall rule applied over SSH can lock you out. Always allow your SSH port first, keep a second SSH session open while you apply the rules, and make sure you have console or VNC access from your provider panel before you start.

We do not store your data. Every port, address, interface and comment you type is validated and turned into rules locally in your browser. Nothing is submitted to VPSLake.

HOW TO USE IT

Generate in four steps

Plan the rules before you touch the server, then apply them from a session you can afford to lose.

  1. 1

    Choose the IP version and the policies

    Pick IPv4, IPv6 or both. Most servers use DROP on INPUT and FORWARD and ACCEPT on OUTPUT. Set the SSH port your server really listens on so the accept rule is generated for the right port.

  2. 2

    Keep the baseline rules

    The loopback, conntrack, invalid, ping and SSH rules are what make a DROP policy usable. Leave the ICMPv6 part enabled on any server with IPv6. Only tick the flush option if you are certain nothing else manages this firewall.

  3. 3

    Add your own rules

    Add one rule per service: the chain, the target, the protocol, the ports, and any source or destination address. Use append for a normal rule and insert only when the rule has to beat one of the baseline rules.

  4. 4

    Apply, verify and persist

    Copy the command script to the server and run sudo sh iptables-rules.sh, or download iptables-rules.v4 and load it with sudo iptables-restore < iptables-rules.v4. Check the result with sudo iptables -S, open a second SSH session, then run sudo netfilter-persistent save so the rules survive a reboot.

Why rule order decides everything

A packet walks a chain from the first rule to the last and stops at the first rule that matches with a terminal target such as ACCEPT, DROP or REJECT. Nothing below that rule is ever consulted, which is why two correct-looking rules can produce a firewall that behaves like neither.

-A appends a rule to the end of the chain, after everything already there. -I inserts it at position one, above everything, including the rules the generator emitted before it. Use -A for ordinary service rules. Use -I only when a rule must be evaluated before a baseline rule, for example a block on one abusive address that would otherwise be accepted by a broad allow rule.

The default policies are applied last in the command script on purpose. Setting -P INPUT DROP before the accept rules exist would cut the connection you are working from, so the script builds the chain first and switches the policy at the end.

What the two tabs contain

The Commands tab is a shell script of complete sudo iptables and sudo ip6tables commands with numbered comments, which you can run line by line while you watch what each one does. The iptables-save tab is the same firewall in the format iptables-restore reads, which loads the whole ruleset in one atomic step.

  • Optional flush of the filter table, with the policies set to ACCEPT first
  • Loopback, conntrack and invalid-packet baselines
  • Ping handling, correct for IPv4 and for ICMPv6
  • The SSH accept rule, with optional -m recent rate limiting
  • Your own rules, appended or inserted as you chose
  • A rate limited LOG rule in every chain that drops by default
  • The default policies, applied last in the command script

Comments are written with -m comment --comment "text" and accept letters, numbers, spaces and a small set of punctuation only, so nothing you type can close the quoted string and become a second shell command.

Test the firewall before you trust it

This output is a reviewed starting point, not an audited or guaranteed-safe configuration. Read every line against the services your server actually runs, apply it while a second SSH session is open, and confirm you can open a fresh connection afterwards. If you lose access, use the console or VNC session in your hosting panel and run sudo iptables -P INPUT ACCEPT followed by sudo iptables -F. Flushing the filter table also removes rules that Docker, Kubernetes, libvirt, fail2ban, UFW and firewalld manage, so check what else is filtering on the machine first, and remember that nothing here is saved across a reboot until you run sudo netfilter-persistent save.

FREQUENTLY ASKED QUESTIONS

iptables Rule Generator FAQ

The syntax is standard iptables and works on Debian 10 and later, Ubuntu 18.04 and later, and the RHEL family, using the conntrack, multiport, recent, limit and comment matches that ship with the standard package. On current Debian and Ubuntu the iptables command is really iptables-nft, a translation layer that writes into nftables; the commands are identical and the rules appear under sudo nft list ruleset as well.
Use the Commands tab when you want to apply the rules one at a time and watch the effect, or when you are adding to a firewall that already exists. Use the iptables-save tab when you want the whole ruleset replaced in one atomic operation with sudo iptables-restore < iptables-rules.v4, which is also the file format iptables-persistent stores in /etc/iptables/rules.v4. The two describe the same firewall; the copy and download buttons act on whichever tab is showing.
Three rules are emitted. The first uses -m recent --set --name SSH to record the source address of every new connection to the SSH port in a kernel list; it has no target, so the packet carries on. The second uses -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP, which drops the packet when that address already has five entries in the last 60 seconds, and refreshes the timestamp so a host that keeps trying stays blocked. The third accepts everything else on the port. Existing sessions are unaffected, but an automation host opening many short-lived sessions from one address can trip the limit; give it its own inserted accept rule if that happens.
IPv6 has no ARP. Hosts find each other and learn the router through ICMPv6 neighbour discovery, and path MTU discovery depends on the packet-too-big message. Blocking ICMPv6 wholesale leaves an address that resolves but never connects, or a connection that stalls on large transfers. The ping baseline therefore rate limits IPv4 echo requests but accepts ICMPv6, which is the usual recommendation for a host firewall.
DROP discards the packet silently, so the client waits until it times out. REJECT sends an ICMP error, so the client fails at once. The generator writes --reject-with icmp-port-unreachable for IPv4 and --reject-with icmp6-adm-prohibited for IPv6, because the two binaries take different reject types. Dropping is the usual choice for traffic from the public internet; rejecting is friendlier on an internal network where a fast failure is more useful than a hidden port.
Plain --dport takes one port or one range such as 8000:8100. Matching several unrelated ports in a single rule needs the multiport match, written as -m multiport --dports 80,443, which accepts at most fifteen ports and only works with -p tcp or -p udp. The generator picks the right form for what you typed and reports the limit before you run anything, rather than letting the command fail on the server.
iptables rules live in the running kernel only. Nothing writes them to disk unless you ask. On Debian and Ubuntu install sudo apt install iptables-persistent and run sudo netfilter-persistent save, which stores the current rules in /etc/iptables/rules.v4 and /etc/iptables/rules.v6 and reloads them at boot. On the RHEL family the equivalent package is iptables-services with sudo service iptables save. Deliberately not saving is also a safety net: if a rule locks you out, a reboot restores the previous state.
Only when you are sure nothing else manages this firewall. -F and -X remove every rule and custom chain in the filter table, including the chains Docker, Kubernetes, libvirt, fail2ban, UFW and firewalld create, and those services will not notice until they are restarted. The script sets all three policies to ACCEPT immediately before flushing so the machine is never left with an empty chain and a DROP policy, which would drop your own session. The NAT and mangle tables are not touched.
Comments are written into a shell command inside double quotes. Allowing a quote, semicolon, backtick, dollar sign or ampersand would let a pasted string end the quoted text and become a separate command. The field therefore accepts letters, numbers, spaces and the characters . _ - / : + # ( ) only, and the same restriction applies to every value that reaches a command line, including addresses and interface names.
No. The page makes no network request for your input, stores nothing in the browser and has no upload. Validation and rule generation run entirely in your browser, and both downloads are produced from text your browser already holds.
It writes filter-table rules only. It does not generate NAT, masquerade or port forwarding, mangle or raw rules, custom user chains, ipset references, TCP flag or string matches, or connection-rate limits beyond the SSH one, and it does not read the firewall you already have. Anything it is not certain of is left out rather than guessed at, so the output stays short enough to read in full.