Use nftables for normal Linux firewalls, use eBPF when you need programmable packet processing, and treat bpfilter as a historical detour rather than a serious deployment choice. That is the practical answer for most admins, platform teams, and security engineers comparing Linux packet filtering options.
TLDR: bpfilter was meant to modernize iptables by translating rules into BPF, but it never became the replacement people hoped for. nftables is the safer default for host firewalls, NAT, and stateful filtering; for example, a gateway with 2,000 legacy iptables rules can often be reduced to a smaller nftables ruleset using maps and sets. eBPF shines when you need very fast packet decisions, container networking, DDoS filtering, or deep observability. If your team wants fewer surprises, start with nftables and bring in eBPF only where the extra control is worth the added complexity.
Why bpfilter Still Comes Up
bpfilter sounds like it should be the missing bridge between old iptables and modern BPF-based networking. The idea was attractive: keep the familiar iptables interface, then run the actual filtering through BPF programs for better speed and flexibility.
In practice, bpfilter never became that clean upgrade path. It appeared in the Linux kernel as an experimental project, tied to user-mode helper code and BPF translation. Then development stalled. For many users, it existed more as a confusing kernel configuration option than a useful firewall engine. Honestly, it feels like one of those features that made sense on a whiteboard but left admins asking, “So am I supposed to use this or not?”
The short answer is no. If you are building firewall rules today, bpfilter should not be your target. Recent kernels and distributions have moved away from it, and the operational ecosystem around it never matured.
nftables: The Practical Successor to iptables
nftables is the mainline Linux packet filtering framework built on the nf_tables subsystem. It replaces the older iptables, ip6tables, arptables, and ebtables tools with one unified interface.
That matters. Old iptables setups often grow into a mess of duplicated IPv4 and IPv6 rules, long chains, and fragile ordering. nftables fixes much of that with a cleaner rule model.
Key strengths include:
- Unified syntax: One tool can manage IPv4, IPv6, ARP, bridge filtering, and more.
- Sets and maps: Large address lists or port groups can be handled cleanly instead of repeated line by line.
- Atomic updates: Rules can be loaded as a single transaction, reducing half-applied firewall states.
- Stateful filtering: Connection tracking remains strong and familiar.
- NAT support: nftables handles SNAT, DNAT, masquerading, and redirection well.
For a standard server, router, VPN gateway, or office firewall, nftables is usually the right tool. It is boring in the best possible way. It has documentation, distribution support, and predictable behavior.
The catch is that migration can be annoying. Automatic iptables-to-nft translation tools help, but they do not always produce elegant rules. Expect to waste time cleaning up old chains, especially if the original firewall was patched by five different admins over seven years.
Where eBPF Fits
eBPF is not just a firewall tool. It is a safe in-kernel execution system that can attach programs to many hooks, including networking, tracing, security, and performance events.
For packet filtering, eBPF often appears in three places:
- XDP: Runs very early, close to the network driver. Best for dropping or redirecting traffic before the kernel spends more work on it.
- tc BPF: Runs at the traffic control layer. Useful for shaping, policy, and packet modification.
- cgroup BPF: Applies controls to groups of processes or containers. Handy for service-level policy.
eBPF can be extremely fast. At XDP speed, a server can discard unwanted packets before they hit the normal networking stack. That is why it is popular in DDoS mitigation, Kubernetes networking, service meshes, and observability tools.
But raw power comes at a cost. Writing and operating eBPF programs is harder than writing nftables rules. You may need C, Rust, Go libraries, verifier knowledge, kernel feature checks, and careful testing. A bad nftables rule may lock you out. A bad eBPF rollout can also lock you out, but with extra debugging pain.
bpfilter vs nftables vs eBPF
The three options are often mentioned together, but they sit in different categories.
| Technology | Best Use | Main Problem |
|---|---|---|
| bpfilter | Mostly historical interest | Unfinished, little real adoption, not a safe target |
| nftables | General firewalling, NAT, stateful rules | Migration from iptables may need cleanup |
| eBPF | High-speed filtering, container networking, deep visibility | More code, more skill, more testing |
bpfilter tried to make iptables feel modern without forcing users to change habits. That was the promise. The result did not reach production-grade usefulness.
nftables took another route. It changed the user interface and rule model, but stayed close to the traditional Linux firewall role. It is the natural upgrade for hosts and gateways still using iptables.
eBPF goes deeper. It gives engineers a programmable packet path. That is amazing in skilled hands, but it is not the first tool to hand to someone who just needs to block SSH from the public internet.
Performance Expectations
Performance depends on hardware, rule design, packet size, NIC support, and kernel version. Still, some rough patterns are useful.
- nftables performs well for most firewall workloads, especially when sets replace huge linear rule lists.
- XDP-based eBPF can outperform normal firewall paths for early drops, especially under flood traffic.
- bpfilter is not worth benchmarking for new deployments because it is not a practical production path.
For example, if 80% of unwanted traffic can be dropped at XDP before connection tracking, CPU usage can fall sharply during attacks. On the other hand, if traffic needs NAT, state tracking, logging, and normal routing decisions, nftables may be simpler and more maintainable.
Security and Operations
Security is not only about packet speed. It is also about clear rules, safe updates, logging, and recovery.
nftables gives admins a readable policy layer. You can review a ruleset, store it in Git, test it in staging, and roll it out with system tools. Most Linux distributions support it directly.
eBPF security depends on the kernel verifier, program permissions, helper functions, and loader design. Modern eBPF is powerful, but that means access should be controlled. On multi-tenant systems, unprivileged BPF settings deserve special care.
bpfilter offers little here for real teams because the tooling story never caught up. If a security audit asks why it is in your plan, you will spend time explaining an abandoned idea instead of showing a clean control model.
Which One Should You Choose?
Choose nftables if you need:
- A reliable Linux host firewall
- Router or gateway filtering
- NAT and port forwarding
- Readable stateful firewall rules
- A supported replacement for iptables
Choose eBPF if you need:
- Very early packet drops with XDP
- Kubernetes network policy at scale
- Per-service or per-container enforcement
- Custom telemetry and tracing
- Packet processing that normal firewall rules cannot express cleanly
Avoid bpfilter for new work. It is useful to know why it existed, but not useful enough to build around.
The Bottom Line
nftables is the default answer. It solves the everyday firewall problem with fewer moving parts than eBPF and far more real-world support than bpfilter. For most servers, that is exactly what you want.
eBPF is the specialist tool. Use it when speed, programmability, or container-scale policy makes the added effort worthwhile. It can be brilliant, but it asks more from the team running it.
bpfilter is the cautionary tale. Not every clever kernel idea becomes the future. Sometimes the boring supported tool wins, and in Linux packet filtering, that tool is nftables unless your needs clearly point to eBPF.
