Nftables 1.0.0 Released | Hacker News Reader

Nftables 1.0.0 Released

marc.info

52 pointsporjo23 comments

Yay.

I learned ipfw. Then ipchains. Then iptables. I got quite good with handcrafting firewalls with all of those at some point. The machines they ran on (for me) range from 80486 to date.

This laptop has a ... (fumbles with various commands and searches) ...

  $ sudo nft list rules

firewalld and its GUI generates a nftables based firewall.

I generally use ufw on servers because it is easy for a simple host based firewall and that is iptables based still. A server host based firewall is generally all about ingress filtering. Egress can be covered more effectively at the edge and at switches/internal routers.

My laptop needs a far more complicated setup and the ruleset that is dumped by nft is almost legible in the first read. I do use a GUI but it's nice to think that I can sit down and spend some time and decide whether my stated policy is what I get at the firewall itself.

I don't yet use nft at the edge but it feels as though it might do nicely.

Your firewalling choice is not something that happens overnight. I'll mull over it for at least two more years.

Just going to put this here to save some clicks for people thinking nftables may have anything to do with NFTs:

> nftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames

and I believe it is a meant to be a replacement of iptables.

But because the Linux kernel is developed separately from user-space, and never breaks user-space, iptables (at least the API) will never go away

I believe no. As far as I understand RedHat already provides user space "iptables" utility which simply converts any input/output to/from nftables, so there is no kernel iptables in latest RedHat.

Many distro default to iptables-nft, RHEL 8 went further and is not providing iptables-legacy binary at all. RHEL 8 still has iptables in the kernel, I think to allow container sidecars to still work with iptables-legacy.

APIs get removed from Linux all the time. Off the top of my head, here's one: https://man7.org/linux/man-pages/man2/sysctl.2.html

> This system call no longer exists on current kernels! See NOTES.

Before iptables there was ipchains, and before ipchains there was ipfwadm.

I don't think you can still use all of them.

Are you sure?

As far as I understand, it may happen that everybody stops using the old interface (the distros choose what they compile into their kernels, I guess), and after a few years of that the kernel maintainers may decide to remove the old code, assuming it wouldn't be too much work. Don't know how likely it for this to happen in the near future, though.

This scenario isn't impossible, but 'a few years' would be more like 'decades'.

This is huge. The hash based approach makes speed improvements over complex iptables usage very impressive, in its most common implementations

I'm a big fan of nftables, but anyone using iptables with a large ruleset is (or should be) using ipset, which is just as fast.

That hasn’t been my experience with large enterprises, but my experience is simply anecdotal so you may be right.

Is there still a chance of an eBPF based effort (bpfilter) making nftables unnecessary in the near future?

You mean like this?

[1] http://rmind.github.io/npf/intro.html

[2] https://man.netbsd.org/npf.7

Or conveniently integrated into Linux like in

[3] https://therouter.net/ and

[4] https://github.com/alexk99/the_router ?

Are there plans to move k8s to nft? Seems like more flexible back-end compared to iptables.

This depends on the CNI plugin you're using. In particular, Cilium implements the entire firewall in eBPF.

CNI plugins is one thing, while k8s subsystems itself still use iptables for KUBE-FIREWALL, KUBE-FORWARD, KUBE-NODE-PORT. At least that how I understand the k8s internals.

cillium reimplements kube-proxy's functionality. There may still be a couple of features missing, but it can definitely take over service routing more efficiently. I haven't checked in a bit but I'm pretty sure it covers NodePort too

Could you elaborate the benefit of doing it that way?

Disclaimer: I'm not an expert in Cilium! Only recently got into reading about it because of Jessie Frazelle's tweet about it. Still planning on deploying it into my small homelab.

It's my understanding that Cilium chose to do it this way because it allows low-level control of each network namespace that containers launch in, in addition to a high-level view of the system from the k8s API. This allows Cilium to build firewalling features that operate at a different level -- iptables/nftables filters on IP addresses and ports, but Cilium can filter on k8s resources and L7 protocols.

nft and iptables are both packet filters. What is your use case?

Kubernetes implements load balancing via iptables probability rules. It creates "magic" static IPs on all kube nodes for ClusterIP services and makes iptables randomly select backend pods, making for a highly efficient zero-userspace load balancer. That gets less efficient with more rules due to the linearity of iptables. It also has an alternative implementation using ipvs, which is theoretically more efficient but has faced a number of issues over the years.

Kubernetes also has network security policy features for firewalling, that piece is implemented by plugins which do whatever they want though.

At this time, kubernetes requires you to be using iptables instead of nftables for all of this, so it will be interesting to see it running on iptables-free servers in the future.

It's a more operational question. In a year or two I plan to have all newly deployed servers with nft instead of iptables. So I would naturally expect to use the same nft commands to troubleshoot 'classic' servers and k8s nodes what sit on the same 'classic' servers - we run k8s on bare hardware.

Reply on news.ycombinator.com