4 ms·
"The Linux kernel currently supports two separate network packet-filtering mechanisms: iptables and nftables. For the last few years, it has been generally assu
by arca_vorago 9y ago
"The Linux kernel currently supports two separate network packet-filtering mechanisms: iptables and nftables. For the last few years, it has been generally assumed that nftables would eventually replace the older iptables implementation; few people expected that the kernel developers would, instead, add a third packet filter. But that would appear to be what is happening with the newly announced bpfilter mechanism. Bpfilter may eventually replace both iptables and nftables, but there are a lot of questions that will need to be answered first."
Goshdarnit. I've been trying to get ahead of the curve and have been learning and implimenting nftables, and now you're telling me I might need to learn something else! Such is the life of a sysadmin I suppose.
"The use of BPF enables the writing of firewall rules in C"
Have you seen the rulesets people write in other firewall languages? This seems scary to me.
"One of the core design features for bpfilter is the ability to translate existing iptables rules into BPF programs."
nftables also does this, but I suggest not using it and writing fresh
"even though it would be likely to supplant nftables relatively quickly. Instead, Miller said in the discussion that nftables failed to address the performance problems in Linux's packet-filtering implementation, driving users toward user-space networking technologies instead. There is a real possibility that nftables could end up being one of those experiments that is able to shed some light on the problem space but never takes over in the real world."
Ok, well I have some questions here. First, show me the benchmarks. Also, nftables is still much faster than iptables in my benchmarks, so it has largely delivered. Of course it's difficult to compete with an asic offload, but I do see how there could be lots of potential with bpf if it offloads to the interface. That said, the real potential I see is for nftables and bpf to coexist in the future as a replacement for iptables or for iptables and bpf. nftables solves a lot of real problems and working with it has been really enjoyable for me compared to years of iptables rules (I always refused to use the layer-on-top-of-iptables abstractions, so I'm talking about pure iptables.) A quick glance at bpf seems like it would be worth it for extremely high requirement cases where the investment would be worth it (just noticed the cloudflare comment for example), but for the rest of us mortals in IT deps with limited budgets, time, and knowledge workers, it seems a bit too heavy to just start implimenting.
I could be wrong, but I really hope nft succeeds despite this.
- marios 9y agoI'd really like it if instead of having "kernel developers add a third packet filter", said developers would sit down a bit and agree on how to manage firewalling at the userspace level. iptables feels like a tool that was developped to test out netfilter rules (that is, the kernel part) but not really for actual use. That would explain why there are so many frontends that attempt to abstract away the ugliness. I've seen too many "firewall setups" that are just a script calling iptables for each rule. While this works, it can be dangerous as well: if you edit the file and mess up a rule, there's a risk that only part of the ruleset is loaded. Hopefully, the operator won't have locked himself out in the process. Of course, there's the iptables-persistent package for atomically loading a ruleset (in Debian at least). The problem is that there's also a netfilter-persistent package. What's the difference between the two ? How is one supposed to pick ? Then, there's also nftables. I've only glanced at it, and it looks promising but it seems there are some things that are missing. A comment in the article says that TCP MSS clamping has been added only recently. By the looks of it, it appears to be "almost there" but not quite ... which is a shame. I'm hoping whatever implementation ends up prevailing will solve the various technical problems (performance, features w.r.t filtering capabilities) but will also provide a sane way to manage it. I feel kind of sad with the current situation. With my developer hat on, I am continuously impressed with the networking features available on Linux (Netfilter, XDP, ...). With my operator hat on, I find the general lack of usable tools as well as the inconsistency maddening.