Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Use Linux Server Firewall with NFTables
Transcript
- Lucas: If you've been managing Linux servers for a while, you've probably heard that iptables is being replaced by nftables. But maybe you haven't made the switch yet because you're not sure what's actually different, or whether it's worth the migration effort. Luna: And honestly, iptables still works. So why bother? What does nftables give you that iptables doesn't? Lucas: Great question. Let's start with the big picture. Nftables is the modern framework for packet filtering and classification in the Linux kernel. It's been the default since Debian Buster, RHEL 8, and Ubuntu 20.04. The old iptables tools are still there for backward compatibility, but the kernel subsystem underneath is actually nftables now. Luna: So even if you're running iptables commands, they're being translated to nftables in the background? Lucas: Exactly. The iptables-nft compatibility layer translates the old syntax into nftables rules. But you're leaving performance and flexibility on the table if you don't use the native nftables syntax. Luna: Performance? Isn't the kernel doing the same filtering regardless? Lucas: The kernel's netfilter engine is the same, but nftables gives you a single unified framework instead of separate tools for IPv4, IPv6, ARP, and bridge. That means one rule set, one syntax. And because nftables compiles rules into bytecode before loading them into the kernel, it can be more efficient, especially with large rule sets. Luna: Okay, so let's get practical. How does nftables syntax look compared to iptables? Lucas: Let me show you a concrete example. In iptables, to allow SSH on port 22 from a specific subnet, you'd write: iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT. In nftables, you define a table and a chain first, then add a rule like: nft add rule inet filter input tcp dport 22 ip saddr 10.0.0.0/24 accept. Luna: Right, so in nftables you have to explicitly create the table and chain. That's a bit more upfront work. Lucas: Yes, but it also gives you better organisation. You can have multiple tables for different purposes — one for the host firewall, one for Docker, one for Kubernetes — and they all live in the same namespace without conflicting. In iptables, everything was in one flat table. Luna: So let's say you want to migrate an existing iptables rule set. What's the best approach? Lucas: The safest way is to use the iptables-translate tool. It takes an iptables command and outputs the equivalent nftables command. For example, iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT gives you: nft add rule inet filter INPUT tcp dport 22 accept. Luna: Does it handle all iptables options? Lucas: Most of the common ones. There's also a tool called iptables restore translate that converts entire iptables-save outputs. But the real power of nftables comes when you stop thinking in iptables terms and start using native nftables features like sets and maps. Luna: Tell me about sets. That sounds useful. Lucas: Sets are like named groups of IP addresses, ports, or interfaces. Instead of writing one rule per IP, you define a set and reference it in a single rule. For instance, you can create a set called 'whitelist' containing a bunch of IPs, then write: nft add rule inet filter input ip saddr @whitelist accept. Luna: So if that set contains ten thousand IPs, the kernel still only evaluates one rule? Lucas: That's right. The kernel can use efficient data structures like hash tables or bitmaps depending on the set type. With iptables, you'd have ten thousand rules, each evaluated sequentially. So performance can be dramatically better. Luna: What about maps? How are they different from sets? Lucas: Maps let you associate a value with a key. For example, you could have a map that maps a source IP to a specific action or a specific logging prefix. So you could write: nft add rule inet filter input ip saddr vmap @mymap, where mymap is a map of IPs to verdicts like accept or drop. Luna: That's clever. It's almost like a programmable firewall rule set. Lucas: Exactly. And you can update sets and maps at runtime without flushing everything. That's huge for dynamic environments like cloud or container orchestration. Luna: Let's talk about logging. In iptables, you'd use the LOG target. How does logging work in nftables? Lucas: In nftables, logging is a statement that can be added to a rule. For example: nft add rule inet filter input tcp dport 22 log prefix 'SSH attempt: ' accept. That logs each SSH connection attempt. You can also use the 'limit' statement to rate-limit logging so you don't fill up your logs. Luna: That's cleaner than having a separate LOG rule followed by a separate ACCEPT rule. Lucas: Right. And nftables supports 'meta' rules for matching on things like packet marks, CPU, or cgroup. So you can do very fine-grained filtering. Luna: One thing that comes up a lot with iptables is the learning curve for the syntax. Is nftables easier? Lucas: I'd say it's more consistent. iptables had a lot of command-line flags that varied between targets and matches. nftables uses a more structured, space-separated syntax that reads almost like a configuration language. And the error messages are actually helpful — they tell you exactly where you made a syntax mistake. Luna: But if you already have a massive iptables rule set, is it worth migrating? Lucas: I'd say yes, but do it incrementally. Start by running both in parallel for a while. Use nftables for new rules, keep iptables for legacy ones. Then gradually migrate the old rules. The kernel can run both frameworks simultaneously via the iptables-nft compatibility layer. Luna: What about tools like firewalld? Does that use nftables now? Lucas: Yes, firewalld on RHEL 8 and later uses nftables as its backend by default. So if you're using firewalld, you're already using nftables under the hood. But if you want direct control, you can bypass firewalld and write nftables rules directly — just be aware that firewalld might overwrite them if you don't configure it correctly. Luna: That's a good point. So what's the one command you'd run to check if nftables is active on your server? Lucas: You can run 'nft list ruleset' to see all active rules. If it shows output, nftables is running. If it returns nothing or gives an error, you might still be using legacy iptables. Also check if the kernel module 'nf_tables' is loaded with 'lsmod | grep nf_tables'. Luna: Let's do a quick example migration. Say I have an iptables rule that drops incoming traffic on port 3306 from all except a management subnet. How would that look in nftables? Lucas: In iptables, you'd have: iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.0/24 -j ACCEPT followed by iptables -A INPUT -p tcp --dport 3306 -j DROP. In nftables, you could use a set for the allowed subnet and a counter for the drops. Something like: add set inet filter mgmt_subsets { type ipv4_addr; elements { 10.0.0.0/24 };} and then add rule inet filter input tcp dport 3306 ip saddr @mgmt_subsets accept and add rule inet filter input tcp dport 3306 counter drop. Luna: The counter is interesting. You can count packets without a separate rule? Lucas: Exactly. 'Counter' is a statement you can add to any rule. And you can retrieve the counts with 'nft list ruleset' or 'nft list counter inet filter drop_counter' if you name it. Luna: Naming counters — that makes monitoring easier. You could have a counter for each type of blocked traffic. Lucas: Exactly. And you can combine counters with logging to get both packet counts and log entries. That's one of those features that makes nftables feel like a modern tool. Luna: I've also heard about 'nftables' support for connection tracking. How does that differ from iptables? Lucas: Connection tracking is similar — you use 'ct state' to match on connection states. For example: nft add rule inet filter input ct state established,related accept. That's almost identical to iptables. But in nftables, you can also use 'ct mark' or 'ct label' for more advanced stateful filtering. Luna: So for most sysadmins, the migration is more about learning the new syntax than about conceptual changes. Lucas: Exactly. The concepts are the same: chains, tables, rules, matches, actions. The syntax is cleaner and more powerful, but it's not a completely different paradigm. Luna: What about performance benchmarks? Have you seen significant improvements? Lucas: The biggest improvement comes when you use sets and maps to reduce rule count. I've seen cases where a rule set with 10,000 iptables rules was reduced to 50 nftables rules using sets, and the firewall throughput improved by 30 to 40 percent. But if you just translate iptables rules one-to-one, the performance gain is modest. Luna: So the real win is in redesigning the rule set to take advantage of nftables' features. Lucas: Absolutely. Think of it as an opportunity to clean up your firewall. Most iptables rule sets accumulate cruft over the years. Migrating is a good time to audit what you actually need. Luna: That's probably the best advice. Don't just migrate; refactor. Lucas: Right. And speaking of things that are worth doing — you know, we spend a lot of time on this show digging into tools that make your day-to-day work easier. And we keep the show completely free of ads, because we think that makes the conversation more honest and useful. Luna: Yeah, that's something we hear from listeners a lot — they appreciate not having a mid-roll ad break right when things get technical. Lucas: If you've gotten something useful out of today's episode or any of the previous 74, and you want to help keep it ad-free, there's a simple way. You can support the show at buy me a coffee dot com slash fexingo. No pressure, just an option if the content's been valuable to you. Luna: It genuinely helps. And it means we don't have to think about sponsors or advertisers — we just think about what's actually useful for sysadmins. Lucas: So back to nftables — one more thing I want to touch on is automation. If you're using Ansible or Puppet to manage your servers, how do you handle nftables rules? Luna: I've seen Ansible modules for nftables. Do they work well? Lucas: The 'ansible.builtin.nftables' module is good for managing rules. You can define your rules in a variable file and apply them idempotently. The key is to use 'nft list ruleset' as the check command so Ansible knows if the rules have changed. Luna: And you can template the rules with Jinja2 to handle different environments. Lucas: Exactly. For example, you might have a base rule set that allows SSH and monitoring, and then environment-specific sets for application ports. That keeps your automation clean. Luna: What about troubleshooting when something breaks? If a rule isn't working as expected, how do you debug it? Lucas: Nftables has a trace mechanism. You can add 'meta nftrace set 1' to a rule, and then run 'nft monitor trace' to see which rules are matching and in what order. That's much more powerful than iptables' LOG approach because you get real-time visibility into the packet flow. Luna: That sounds like a game-changer for debugging complex rule sets. Lucas: It really is. You can see exactly which rule matched, the verdict, and the packet metadata. Combined with counters, you can quickly identify if a rule is too broad or not matching as intended. Luna: So if someone is still on iptables and they're doing complex filtering, nftables might be worth the switch just for the debugging features alone. Lucas: I'd say that's a strong argument. The tooling around nftables is mature now. The nft command-line tool has good completion, and the man pages are comprehensive. Plus, there's a growing number of community resources and example rule sets. Luna: What about the future? Are we going to see further development of nftables? Lucas: Absolutely. Nftables is actively maintained by the kernel netfilter team. There are ongoing improvements in performance, new features like support for tunnel encapsulation and BPF integration. The iptables compatibility layer is maintained but will eventually be deprecated. So learning nftables now is future-proofing your skills. Luna: Good. So for anyone listening who's been putting off the migration, what's the first step? Lucas: Install the nftables package on a test server, run 'iptables-save' to dump your current rules, then use 'iptables restore translate' to convert the whole set to nftables format. Review the output, fix any issues, and test it in a non-production environment. Once it works, deploy it gradually. And remember, you can always fall back to iptables-nft if something goes wrong. Luna: That's a solid plan. It doesn't have to be a big bang migration. Lucas: Exactly. Start small, test thoroughly, and you'll be surprised how quickly nftables becomes second nature.