nftables is the modern replacement for iptables on Linux, and since Debian 10, RHEL 8, and their derivatives, it is the default firewall framework shipped with the kernel. If your VPS still runs an iptables ruleset from 2015, you are maintaining two parallel rule sets \u2014 legacy iptables and the nftables backend that now powers it \u2014 without getting any of nftables’ benefits. This guide walks through a practical nftables setup for a Linux VPS: the syntax you need, a working ruleset you can adapt, and the mistakes that lock people out of their own servers.<\/p>\n\n\n\n
The headline difference is one tool instead of four: where iptables needed separate binaries for IPv4, IPv6, ARP, and bridging, nftables handles all of them through the single Install nftables and enable it on boot:<\/p>\n\n\n\n Then write your ruleset to Apply it with Named sets let you manage allowlists without editing rules. Define Pair this with key-based authentication and fail2ban for defense in depth. Log dropped packets with a rule like Before you apply anything remotely, validate the file: nftables is well worth the syntax shift: one tool, atomic updates, and better performance on the same kernel. If you are coming from iptables, the VPS feature comparison at virtualserversvps.com<\/a> includes notes on which providers give you full kernel-level control for custom firewalls, and the provider list<\/a> helps you find a host with a modern kernel and up-to-date base images where nftables is the default.<\/p>\n\n\n\nnft<\/code> command using an inet<\/code> family table that covers both IP versions. Rules are evaluated more efficiently, and the whole ruleset is replaced atomically \u2014 there is no window where a partially applied chain leaves you exposed.<\/p>\n\n\n\nAspect<\/th> iptables<\/th> nftables<\/th><\/tr><\/thead> Binaries<\/td> iptables, ip6tables, arptables, ebtables<\/td> Single nft<\/code> binary<\/td><\/tr>IPv4 + IPv6<\/td> Separate rulesets, easy to forget one<\/td> One inet<\/code> table covers both<\/td><\/tr>Rule updates<\/td> Per-rule, with partial-apply risk<\/td> Atomic ruleset replacement<\/td><\/tr> Sets and maps<\/td> Require separate ipset tool<\/td> Built-in anonymous and named sets<\/td><\/tr> Persistence<\/td> iptables-save\/restore scripts<\/td> nft -f \/etc\/nftables.conf<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nA Minimal Working Ruleset<\/h2>\n\n\n\n
sudo apt update && sudo apt install -y nftables # Debian\/Ubuntu\nsudo systemctl enable --now nftables<\/code><\/pre>\n\n\n\n\/etc\/nftables.conf<\/code>. A sane default for a web server with SSH management looks like this:<\/p>\n\n\n\n#!\/usr\/sbin\/nft -f\nflush ruleset\n\ntable inet filter {\n chain input {\n type filter hook input priority filter; policy drop\n ct state established,related accept\n iif \"lo\" accept\n ip protocol icmp icmp type echo-request accept\n tcp dport 22 accept\n tcp dport 80 accept\n tcp dport 443 accept\n counter drop\n }\n chain forward {\n type filter hook forward priority filter; policy drop\n }\n chain output {\n type filter hook output priority filter; policy accept\n }\n}<\/code><\/pre>\n\n\n\nsudo nft -f \/etc\/nftables.conf<\/code> and verify with sudo nft list ruleset<\/code>. The ct state established,related accept<\/code> line is what lets return traffic in \u2014 omit it and your server can reach out but never receive replies, which looks exactly like a broken network.<\/p>\n\n\n\nCommon Mistakes (and How to Avoid Them)<\/h2>\n\n\n\n
\n
nft -c -f \/etc\/nftables.conf<\/code> (check-only) before applying, and make sure your SSH port rule comes before any drop policy.<\/li>\niif \"lo\" accept<\/code>, local services talking to each other via 127.0.0.1 get blocked and your database or cache mysteriously “stops working” after a reboot.<\/li>\n-A INPUT -p tcp --dport 22 -j ACCEPT<\/code> is not valid nft syntax. The nft equivalents are tcp dport 22 accept<\/code> \u2014 no dashes, no -j<\/code>.<\/li>\nnft<\/code> at the shell vanish on reboot unless you save them with nft list ruleset > \/etc\/nftables.conf<\/code> (or edit the file directly and enable the service).<\/li>\nGoing Further: Sets and Rate Limiting<\/h2>\n\n\n\n
set admin_ips { type ipv4_addr; elements = { 203.0.113.10, 198.51.100.20 } }<\/code> and then reference ip saddr @admin_ips accept<\/code> in the input chain. For brute-force protection, add a dynamic set that drops sources with more than four new SSH connections per minute:<\/p>\n\n\n\nset ssh_bruteforce {\n type ipv4_addr\n flags dynamic\n timeout 10m\n}\nchain input {\n tcp dport 22 ct state new add @ssh_bruteforce { ip saddr limit rate over 4\/minute } drop\n}<\/code><\/pre>\n\n\n\nlog prefix \"nft-drop: \" counter drop<\/code> at the end of the input chain so you can see what is being blocked in journalctl -u nftables<\/code> or the kernel log.<\/p>\n\n\n\nTesting and Rolling Back Safely<\/h2>\n\n\n\n
sudo nft -c -f \/etc\/nftables.conf<\/code> parses the ruleset without loading it and reports syntax errors on the exact line. If a ruleset does break connectivity, do not panic \u2014 reboot the VPS from the provider panel, and because you enabled the nftables<\/code> service, the kernel reloads the last saved<\/em> file. That is why the golden rule is: edit \/etc\/nftables.conf<\/code> first, validate, then apply from that same file. If you instead type rules interactively at the shell, save them immediately with sudo nft list ruleset > \/etc\/nftables.conf<\/code> so a reboot restores what you tested.<\/p>\n\n\n\n