All free tools Generated in your browser

nftables Rule Generator

Describe the firewall you want and receive a complete /etc/nftables.conf ruleset with input, forward and output chains.

RULESET SETTINGS

Build an nftables ruleset

nft
Table
An inet table filters IPv4 and IPv6 with one set of rules, so most servers need nothing else.
Letters, digits and underscores, starting with a letter or underscore. filter is the usual name.
Chain 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.
Named address sets

A set groups addresses under one name so a rule can match them all with @name. Sets are optional.

Firewall rules

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 load the ruleset, 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 a ruleset locally in your browser. Nothing is submitted to VPSLake.

HOW TO USE IT

Generate in four steps

Plan the ruleset before you touch the server, then load it from a session you can afford to lose.

  1. 1

    Choose the table and the chain policies

    Keep the inet family unless you have a reason to filter one protocol only. Most servers use drop on input and forward and accept on output. Set the SSH port your server really listens on.

  2. 2

    Keep the baseline rules

    The conntrack, loopback, ICMP, SYN and logging rules are what make a drop policy usable. Leave the ICMPv6 rule enabled on any server with IPv6, because neighbour discovery stops working without it.

  3. 3

    Add your sets and rules

    Group office or monitoring addresses into a named set, then add one rule per service: pick the chain, the verdict, the protocol, the destination ports and, when it should be restricted, a source address or @set.

  4. 4

    Check the file, then load it

    Download nftables.conf, upload it to the server and run sudo nft -c -f nftables.conf first. If it parses, copy it to /etc/nftables.conf, run sudo systemctl enable --now nftables, then open a second SSH session before you close the one you are using.

How an nftables ruleset is put together

nftables replaces the fixed tables and chains of iptables with ones you declare yourself. A table holds chains and sets for one address family; a base chain attaches to a netfilter hook and carries the policy applied when no rule matches. The generator writes one table with three base chains, all at priority 0, which is where the old filter table sat.

Inside a chain the rules are read top to bottom and the first terminal verdict wins, so the conntrack rules come first, your own rules follow, and the logging rule is last. A rule is a list of matches followed by a verdict: tcp dport { 80, 443 } ct state new accept matches new TCP connections to either port and accepts them.

A named set is declared once in the table and referenced as @name. Sets containing a CIDR block are declared with flags interval, which is what lets nftables store a prefix rather than a single address. Rule order matters within a chain but sets are unordered, so a set is the cheaper way to list many sources for one service.

What the generated file contains

The output is a complete replacement ruleset, not a fragment. It starts with #!/usr/sbin/nft -f and flush ruleset, so loading it removes everything nftables currently holds, including rules that another tool such as Docker or firewalld may have added.

  • One table in the family you chose, with your table name
  • Any named address sets, typed and marked as intervals
  • An input chain with the conntrack, loopback, ICMP, SYN and SSH baselines
  • A forward chain, with conntrack rules when its policy is drop
  • An output chain, with conntrack and loopback rules when its policy is drop
  • Your own rules, in the order you listed them, with optional comments
  • A rate limited log rule at the end of every chain that drops by default

Comments are written as comment "text" and accept letters, numbers, spaces and a small set of punctuation only, so nothing you type can close the quoted string or reach a shell.

Test the ruleset before you trust it

This file is a reviewed starting point, not an audited or guaranteed-safe configuration. Read every line against the services your server actually runs, check it with sudo nft -c -f nftables.conf, and load it while a second SSH session is open so you can still reach the machine if a rule is wrong. If you lose access, use the console or VNC session in your hosting panel and run sudo nft flush ruleset to clear the firewall. Because the file begins with flush ruleset, loading it also removes rules that Docker, Kubernetes, libvirt, fail2ban or firewalld manage, so check what else is filtering on the machine before you apply it.

FREQUENTLY ASKED QUESTIONS

nftables Rule Generator FAQ

The syntax is standard nftables and works on Debian 10 and later, Ubuntu 20.04 and later, and the current RHEL, Rocky, AlmaLinux and Fedora releases, where the package is nftables and the service is nftables.service. Install it with sudo apt install nftables or sudo dnf install nftables if nft is missing. Chain priorities are written as the number 0 rather than the named filter keyword so the file also parses on older nft builds.
Without it, loading the file a second time would add a duplicate table or fail because the table already exists. flush ruleset makes the file describe the complete firewall state, which is how /etc/nftables.conf is normally written. The cost is that it also deletes rules other software added at runtime, so on a machine running Docker or firewalld you should manage the firewall through that software instead.
IPv6 has no ARP. Hosts find each other and learn the router with the neighbour discovery messages nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit and nd-router-advert, and path MTU discovery depends on packet-too-big. Dropping ICMPv6 wholesale leaves an address that resolves but never connects, or a connection that stalls on large transfers. The ICMP baseline includes those types for that reason.
Two rules are emitted. The first drops new connections to the SSH port once they arrive faster than 10/minute with a burst of five packets; the second accepts everything else on that port, including packets belonging to sessions that are already open. An existing session is therefore never cut off by the limit, but a host opening many short-lived SSH sessions, such as a backup or automation runner, can be slowed down. Give that host its own accept rule above the limit if it happens.
drop discards the packet silently, so the client waits until it times out. reject sends an ICMP error, so the client fails at once. In an inet table the generator writes reject with icmpx type port-unreachable, which produces the right message for whichever protocol the packet used. In an ip or ip6 table icmpx is not available, so it writes reject with icmp type port-unreachable or reject with icmpv6 type port-unreachable instead.
Whenever more than one address needs the same treatment. One rule matching ip saddr @admin replaces a rule per address, and you can then edit the membership at runtime with sudo nft add element inet filter admin { 203.0.113.9 } without reloading the file. A set holds one family only, so IPv4 and IPv6 admin addresses need one set each. A set containing any CIDR block is declared with flags interval; the generator adds that automatically.
The log rule sends entries to the kernel log, so they appear in sudo journalctl -k and usually in /var/log/kern.log, each prefixed with nft-drop:. The rate is capped at five messages a minute so a scan cannot fill the disk, which does mean the log is a sample rather than a complete record. The rule is added only to chains whose policy is drop, because a log-what-was-dropped rule in a chain that accepts everything would never be useful.
The kernel will run both, and the result is confusing to debug because each maintains its own chains and a packet has to survive all of them. On current Debian and Ubuntu the iptables command is usually iptables-nft, a translation layer writing into nftables, and UFW and firewalld sit on top of it. Pick one manager. If you load this file, stop and disable ufw, firewalld and netfilter-persistent first.
Comments are written into the ruleset inside double quotes, and the same text may be pasted into a shell command. Allowing a quote, semicolon, backtick, dollar sign or ampersand would let a pasted string end the comment and become a separate statement. The field therefore accepts letters, numbers, spaces and the characters . _ - / : + # ( ) only, and the same restriction applies to every value written into the file.
No. The page makes no network request for your input, stores nothing in the browser and has no upload. Validation and file generation run entirely in your browser, and the download is produced from text your browser already holds.
It writes a filter ruleset only. It does not generate NAT or masquerade chains, port forwarding, mangle or raw hooks, flowtable offload, verdict maps, counters, quotas or netdev ingress rules, and it does not read the ruleset you already have. Anything it is not certain of is left out rather than guessed at, so the file stays small enough to read in full.