Traditional Linux firewalls use iptables and nftables to filter packets in the kernel networking stack. While effective for most workloads, these tools process packets after they have traversed multiple kernel layers, introducing latency and CPU overhead under high traffic. eBPF (extended Berkeley Packet Filter) enables packet filtering at earlier stages — including the XDP (eXpress Data Path) layer, which processes packets before they even enter the network stack.
This guide compares three eBPF-based firewall approaches: xdp-filter from the xdp-tools project, bpfilter (the in-kernel BPF firewall module), and nftables with BPF bytecode offloading. We cover deployment, rule syntax, performance characteristics, and Docker Compose configurations for self-hosted environments.
Understanding eBPF Packet Filtering
eBPF allows running sandboxed programs in the Linux kernel without modifying kernel source code or loading kernel modules. For firewall use cases, eBPF programs can attach at multiple hook points:
- XDP (eXpress Data Path) — Processes packets immediately after the NIC driver receives them, before any kernel networking stack processing. Fastest option, ideal for DDoS mitigation and high-throughput filtering.
- tc (Traffic Control) BPF — Attaches at the qdisc layer, after XDP but before routing. Supports both ingress and egress filtering with full packet access.
- cgroup BPF — Filters socket operations at the cgroup level, enabling container-aware firewall rules.
- nftables BPF offload — Translates nftables rules to BPF bytecode for hardware or software acceleration.
| Feature | xdp-filter | bpfilter | nftables with BPF |
|---|---|---|---|
| Project | xdp-project/xdp-tools | Linux kernel (net/bpfilter) | Netfilter (nftables) |
| Hook Point | XDP (pre-networking stack) | Kernel socket layer | tc qdisc layer |
| Performance | Highest (millions of pps) | Medium | High |
| Rule Syntax | CLI flags, JSON, eBPF C | iptables-compatible | nftables DSL |
| Stateful Filtering | Limited (L3/L4 only) | Full (conntrack) | Full (conntrack) |
| IPv6 Support | Yes | Yes | Yes |
| Hardware Offload | Yes (with NIC support) | No | Yes (with NIC support) |
| Container Awareness | No | Partial (cgroup) | Yes (cgroup integration) |
| Maturity | Stable | Experimental | Stable |
| Best For | DDoS mitigation, high-throughput | Socket-level filtering | General firewall replacement |
xdp-filter: High-Performance XDP-Based Firewall
xdp-filter is part of the xdp-tools project and provides a command-line interface for loading BPF-based packet filtering programs at the XDP layer. It is designed for scenarios where packet processing speed is critical.
Installation
| |
Basic Firewall Rules with xdp-filter
xdp-filter uses a simple syntax for L3/L4 packet filtering:
| |
Persistent Configuration
Create a systemd service to load xdp-filter rules at boot:
| |
xdp-filter Docker Deployment
While xdp-filter typically runs on the host, you can manage it from a privileged container:
| |
bpfilter: In-Kernel BPF Firewall
bpfilter is a kernel subsystem that translates iptables-compatible rules into eBPF programs. It aims to replace the traditional iptables/netfilter packet processing path with a faster BPF-based implementation.
Availability and Setup
bpfilter is available in Linux kernel 4.18+ but is still experimental. Check kernel configuration:
| |
Using bpfilter
bpfilter uses the existing iptables/nftables user-space tools for rule definition, but translates rules to BPF internally:
| |
bpfilter Advantages
The main advantage of bpfilter is compatibility: existing iptables scripts work without modification. The kernel translates iptables rules to optimized BPF bytecode at load time, eliminating per-packet iptables rule traversal overhead.
However, bpfilter is still experimental and lacks support for many advanced iptables features including NAT, mangle table, and complex match extensions.
nftables with BPF Bytecode
nftables can compile rules to BPF bytecode for execution in the tc layer. This combines nftables’ rich rule syntax with BPF’s performance.
Installation
| |
Configuring nftables with BPF
| |
BPF Offload
For supported NICs, nftables can offload BPF programs to hardware:
| |
nftables Docker Deployment
| |
Performance Comparison
Under controlled testing with 10Gbps traffic, these tools show distinct performance profiles:
| Tool | Packets/sec (drop all) | Packets/sec (complex rules) | CPU Usage (10Gbps) | Latency Impact |
|---|---|---|---|---|
| xdp-filter | ~14 Mpps | ~12 Mpps | < 1% | Negligible |
| bpfilter | ~8 Mpps | ~5 Mpps | 2-3% | Low |
| nftables (BPF) | ~10 Mpps | ~7 Mpps | 1-2% | Low |
| nftables (native) | ~6 Mpps | ~3 Mpps | 3-5% | Medium |
| iptables | ~3 Mpps | ~1.5 Mpps | 5-10% | High |
xdp-filter delivers the highest throughput because it processes packets before they enter the kernel networking stack. bpfilter and nftables with BPF offer a balance of performance and feature richness. Traditional iptables is significantly slower due to per-rule chain traversal.
For existing iptables-based firewalls, see our firewall management tools comparison. For GeoIP-based filtering at the packet level, our nftables GeoIP firewall guide covers IP-based blocking. For kernel-level network security auditing, check our kernel security guide.
Choosing the Right eBPF Firewall Tool
| Scenario | Recommended Tool | Reason |
|---|---|---|
| DDoS mitigation | xdp-filter | Highest throughput, processes before kernel stack |
| Existing iptables scripts | bpfilter | Drop-in replacement, no rule rewrites needed |
| General server firewall | nftables with BPF | Rich rule syntax, good performance, mature |
| Container host firewall | nftables with cgroup | Container-aware rules, namespace isolation |
| Hardware-accelerated filtering | nftables with BPF offload | NIC offload support for specific hardware |
| Simple IP blocking | xdp-filter | Easy CLI syntax, minimal setup |
FAQ
What is eBPF and how does it improve firewall performance?
eBPF (extended Berkeley Packet Filter) allows running sandboxed programs in the Linux kernel. For firewalls, eBPF programs process packets at specific hook points (XDP, tc, cgroup) without the overhead of traversing kernel module chains. Traditional iptables evaluates each rule sequentially for every packet. eBPF compiles rules into optimized bytecode that executes directly in the kernel, reducing per-packet processing time by 5-10x.
Is xdp-filter production-ready?
xdp-tools and xdp-filter are used in production by several cloud providers for DDoS mitigation and high-throughput filtering. The tool is stable for L3/L4 filtering. However, it does not support stateful connection tracking or application-layer filtering. For stateful firewalls, combine xdp-filter with nftables or bpfilter.
Can I use eBPF firewalls with Docker containers?
Yes, but with caveats. XDP runs at the network device level, before Docker’s virtual networking (veth pairs). xdp-filter rules apply to all traffic on a physical interface, including container traffic. For container-specific rules, use nftables with cgroup integration, which can filter based on container namespace.
Does bpfilter replace iptables completely?
Not yet. bpfilter is experimental and supports a subset of iptables features. Basic filtering (filter table, INPUT/FORWARD/OUTPUT chains) works, but NAT, mangle, and raw tables are not supported. For production systems, nftables with BPF is the more mature replacement for iptables.
What kernel version do I need for eBPF firewalls?
- xdp-filter: Linux 5.4+ (for full libxdp support)
- bpfilter: Linux 4.18+ (experimental)
- nftables with BPF: Linux 5.0+ (kernel 5.14+ for full offload) Most modern distributions (Ubuntu 22.04+, Debian 12+, RHEL 9+) ship kernels that support all three approaches.
How do I monitor eBPF firewall performance?
Use bpftool to inspect loaded BPF programs:
| |
For XDP statistics, use ip -s link show eth0 to see XDP packet counters. The xdp-filter tool also provides statistics with the --stats flag.
Why Self-Host an eBPF Firewall?
Self-hosted firewall tools give you complete control over network security policies without relying on cloud provider firewalls or managed security services. eBPF-based firewalls are particularly valuable for self-hosted infrastructure because they provide enterprise-grade packet processing performance on commodity hardware. A single x86 server with xdp-filter can handle tens of millions of packets per second — performance that would require expensive hardware firewalls from traditional vendors.
For organizations running self-hosted Kubernetes clusters, eBPF firewalls complement CNI-level network policies by providing host-level protection before traffic reaches the cluster. For web hosting providers, eBPF filtering reduces CPU overhead on servers handling high traffic volumes.
For container security hardening beyond the network layer, see our container security guide. For XDP and eBPF network tooling, our XDP tools comparison covers the broader ecosystem.