Host firewall (eBPF)
Loopback offers a host-integrated firewall that uses Linux eBPF to enforce policy close to the wire, with significantly higher throughput and lower latency than traditional iptables-only stacks for many workloads. In product materials this capability is often associated with LBFW (Loopback Firewall). This page is written for security buyers, platform engineers, and SRE leaders evaluating datapath controls on managed hosts.
What it is (buyer language)
- A kernel-assisted firewall that runs as part of the managed agent story on supported Linux hosts.
- It enforces allow/deny policy for network traffic on the host, complementing (not replacing) cloud security groups, Loopback-managed load balancer ACLs, and Kubernetes network policies where you use clusters.
- Policy is pushed from Loopback and applied in a way designed for minimal disruption during updates (conceptually: double-buffered rule swaps rather than “delete everything, then recreate”).
Why eBPF
eBPF allows safe, verified programs to run in the Linux kernel without shipping a custom kernel module for every customer. For firewalls, that typically means:
- Early packet handling - obvious bad traffic can be dropped before expensive paths.
- Stateful behavior - connection tracking and richer policy can live in TC (traffic control) stage programs while still benefiting from XDP-class fast paths where enabled.
- Observability - counters and structured events can be exported for monitoring and incident response.
Loopback’s implementation is oriented toward host edge and high packet rates—the same places where pure userspace or iptables chains become operationally painful.
What you can do with it (capability view)
Exact feature flags depend on your operator’s build, but the design center includes:
| Capability | User-facing value |
|---|---|
| CIDR-based rules | Allow or deny sources/destinations at IP prefix granularity for IPv4 and IPv6-oriented designs. |
| Port policy | Restrict services to expected listeners; reduce lateral movement after compromise. |
| Default posture | Choose default allow vs default deny per direction, then layer explicit rules. |
| Stateful tracking | Established flows behave predictably; fewer “mystery breaks” for legitimate long-lived connections. |
| DoS-oriented controls | Rate limiting and abuse profiles at the host edge to protect shared services. |
| Statistics | Per-port and aggregate counters for capacity planning and attack visibility. |
| Logging / alerts | Ring-buffer style streams suitable for SIEM integration on the observability side. |
This is host policy. It is defense in depth next to:
- Loopback load balancers (origin allow/block lists at the VIP).
- Organization/workspace firewall objects documented under Firewalls.
- Provider network ACLs and Kubernetes policies for cluster traffic.
What it is not
- Not a WAF - it does not parse HTTP at application layer by itself.
- Not a replacement for identity - combine with RBAC, service mesh, and strong authentication for apps.
- Not magic multi-tenant isolation - if multiple unrelated teams share a host, you still need sound tenancy design upstream.
Operating expectations
- Kernel and packages: eBPF firewalls require supported kernels and libbpf-class dependencies. Your operator publishes minimum versions.
- Interfaces: the module attaches to specific NICs or integration points relevant to your WGLB/LBFW topology. Ask for the network diagram that matches your workspace.
- Change windows: policy pushes are designed to be safe, but any datapath change can still impact long-lived connections. Schedule aggressive changes during maintenance when possible.
- Debugging: if traffic “mysteriously fails,” check three layers in order: LB ACLs → host eBPF policy → cloud security groups / Kubernetes rules.
Compliance framing
For audits, position the module as:
- Technical control: network segmentation and default-deny posture at the host.
- Operational control: RBAC on who can change policy, change management via Loopback, logging to your SIEM.
- Evidence: request architecture diagrams, sample policies, and runbooks from your operator under your NDA / diligence process (see Technical verification).