{"id":534,"date":"2026-06-28T03:12:18","date_gmt":"2026-06-28T03:12:18","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=534"},"modified":"2026-08-17T22:13:20","modified_gmt":"2026-08-17T22:13:20","slug":"vps-firewall-configuration-guide-ufw-iptables-nftables-2026","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-firewall-configuration-guide-ufw-iptables-nftables-2026\/","title":{"rendered":"iptables vs nftables on a VPS: Which to Run and How to Migrate"},"content":{"rendered":"\n

iptables and nftables are not two competing firewalls so much as two generations of the same one. If you still write rules with the classic iptables<\/code> commands, there is a good chance they are being executed through a translation layer on top of nftables without you knowing it. Before you tune either, make sure the underlying host is worth the effort: compare managed and unmanaged plans on our VPS comparison table<\/a>, because no firewall setting can compensate for an oversold or rate-limited server.<\/p>\n\n\n\n

Why nftables Is the Default on Modern Distros<\/h2>\n\n\n\n

nftables has been in the kernel since 3.13 (2014), and every major distribution now ships it as the firewall backend. On Debian 10+, Ubuntu 18.04+, and recent RHEL releases, the iptables<\/code> binary you type at the shell is almost certainly iptables-nft<\/code> \u2014 a compatibility shim that translates legacy syntax into nftables netlink calls. You can confirm this in seconds:<\/p>\n\n\n\n

# On any modern distro this prints \"(nf_tables)\"\niptables --version\n\n# And nftables itself is present\nnft --version<\/code><\/pre>\n\n\n\n
That has two practical consequences. First, legacy iptables rules still work, so there is no emergency migration pressure. Second, mixing both tools on one host is asking for confusion: the iptables<\/code> shim and native nft<\/code> manage the same kernel ruleset but expose different views of it, and rules you add with one can silently surprise you when you inspect with the other. Pick one interface and standardize on it.<\/p>\n\n\n\n
What Actually Differs Under the Hood<\/h2>\n\n\n\n
Aspect<\/th>iptables (legacy)<\/th>nftables<\/th><\/tr><\/thead>
Rule storage<\/td>Four hardcoded tables (filter, nat, mangle, raw)<\/td>Named tables and chains, your own structure<\/td><\/tr>
Atomic updates<\/td>Per-rule append\/insert; full reload via iptables-restore<\/td>nft -f<\/code> applies an entire ruleset atomically<\/td><\/tr>
Complex matches<\/td>Repeated -m modules, verbose flags<\/td>Sets, maps, and concatenations in one rule<\/td><\/tr>
Rule count performance<\/td>Linear walk per packet<\/td>Set\/hash lookups scale better with many rules<\/td><\/tr>
Tooling<\/td>iptables, ip6tables, arptables, ebtables<\/td>One nft<\/code> binary, plus the compat shims<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The differences that matter on a small VPS are atomic reloads and sets. Atomic reloads mean you can stage a full ruleset and swap it in without a window where a rule is missing mid-apply \u2014 exactly what you want when you are firewalling the port you are SSH’d into. Sets let you express “allow these 20 ports” as one rule instead of twenty.<\/p>\n\n\n\n
Same Policy, Both Syntaxes<\/h2>\n\n\n\n
A typical single-VPS policy is: allow loopback, established traffic, SSH, and HTTP\/S; drop everything else. In classic iptables that looks like:<\/p>\n\n\n\n
iptables -A INPUT -i lo -j ACCEPT\niptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\niptables -A INPUT -p tcp --dport 22 -j ACCEPT\niptables -A INPUT -p tcp --dport 80 -j ACCEPT\niptables -A INPUT -p tcp --dport 443 -j ACCEPT\niptables -P INPUT DROP<\/code><\/pre>\n\n\n\n
The same policy in native nftables fits in one file:<\/p>\n\n\n\n
table 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    tcp dport { 22, 80, 443 } accept\n  }\n}<\/code><\/pre>\n\n\n\n
Load it with nft -f \/etc\/nftables.conf<\/code> and enable the service so it survives reboots: systemctl enable --now nftables<\/code>. Note the inet<\/code> family \u2014 one table covers both IPv4 and IPv6, which the legacy syntax never did without a second set of ip6tables rules.<\/p>\n\n\n\n
Migrating Without Locking Yourself Out<\/h2>\n\n\n\n
If you have an existing iptables ruleset, let the tooling do the translation instead of hand-converting every line:<\/p>\n\n\n\n
# Dump current rules\niptables-save > \/tmp\/rules.v4\n\n# Translate to nft syntax\niptables-restore-translate -f \/tmp\/rules.v4 > \/tmp\/rules.nft\n\n# Review, then test-apply without touching the live ruleset\nnft -c -f \/tmp\/rules.nft<\/code><\/pre>\n\n\n\n
The -c<\/code> flag performs a dry run: it parses and validates the file without loading it. Review the generated rules.nft<\/code> \u2014 the translator is mechanical, so comments and some compound matches will need manual cleanup. Then apply in a way that lets you bail out: keep your current SSH session open, load the new ruleset, and only close the session after confirming from a second terminal that ssh<\/code> still connects and nft list ruleset<\/code> shows what you expect.<\/p>\n\n\n\n
Verifying the Firewall Is Actually Doing Something<\/h2>\n\n\n\n