Tempesta FW puts a WAF inside the Linux TCP/IP stack

Four products in one frontend

Tempesta FW is described as an all-in-one open-source solution for high performance web content delivery and advanced protection against DDoS and web attacks, and the README frames it as a drop-in replacement for the whole web server frontend infrastructure.

The four pieces are named explicitly: an HTTPS load balancer, a web accelerator, a DDoS mitigation system, and a web application firewall. That combination is the differentiator, because the README claims Tempesta FW is the first and only hybrid of a Web accelerator and a multi-layer firewall, and that this architecture integrates with the Linux iptables or nftables.

The performance claims are in the README, attributed to the project rather than to me: it says Tempesta FW services up to 1.8M HTTP requests per second on the cheapest hardware, which is x3 faster than Nginx or HAProxy, and that Tempesta TLS is about 40-80% faster than Nginx/OpenSSL and provides up to x4 lower latency. The TLS figure links to a NetDevConf talk on a performance study of kernel TLS handshakes, so the comparison is anchored to a public talk rather than a marketing page.

The primary language of the repository is C, the licence is GPL-2.0, and the topics list spans ddos-protection, http-accelerator, http2, linux-kernel, load-balancer, tls, waf and web-security, which is a fair summary of what the thing is trying to be.

Why the kernel matters here

The How it works section is short and it is the most important paragraph in the README.

Tempesta FW is built into Linux TCP/IP stack for better and more stable performance characteristics in comparison with TCP servers on top of common Socket API or even DPDK or other kernel bypass technology.

That sentence describes two opposing approaches to the same problem. A userspace proxy such as Nginx sits above the kernel and moves data through the socket API, which means copies, context switches and syscall overhead on every request. A kernel bypass approach such as DPDK goes the other way and skips the kernel entirely, which removes that overhead but also removes the network stack, and with it the places where filtering and connection tracking naturally live. Tempesta takes the third route: it modifies the kernel so the processing happens where the packets already are.

The cost of that choice is the maintenance burden it creates, and the project is open about it. We do our best to keep the kernel modifications as small as possible, and the current patch is just about 3,200 lines. The repository root makes this concrete, with a file named linux-6.12.12.patch sitting next to the source.

So the performance argument and the operational argument are two sides of the same decision. You get the speed because the code is in the right place, and you take on the responsibility of building and maintaining a kernel that nobody upstream has merged.

The repository layout and the test suites

The top level of the repository shows the size of the project, and it is not a small one.

There is fw/ for the firewall itself, tls/ for the TLS implementation, lib/ and libtus/ for library code, db/ for the configuration database, regex/ for the regular expression engine, logger/ for logging, pkg/ for packaging, etc/ for the distribution configuration, doc/ for documentation, ktest/ for the kernel test suite, scripts/ for helper scripts, and a Makefile at the root.

The presence of ktest/ and a libtus/ directory is notable. A kernel component needs to be tested at the kernel level, and a project that maintains its own test harness for that is doing more than bolting a module together. The db/ directory points at a database-backed configuration, which is the shape you would expect for something that manages rules, certificates and virtual servers rather than reading a flat config file.

There is also a .clang-format and a .clang-tidy at the root, plus a .githooks/ directory and AGENTS.md and CLAUDE.md files, so the project has the tooling and the agent instructions that a large C codebase tends to accumulate.

The Makefile shows how the build is parameterised. TFW_CFLAGS is built from DEFINES with -Werror, and there is a DEBUG mode that adds -DDEBUG with a check that DEBUG must be greater than 0. Coverage is opt-in through TFW_GCOV, and the comment explains the kernel side of it:

# Use `$ TFW_GCOV=y make` to compile Tempesta modules with GCOV.
# The kernel should be built with:
#	CONFIG_GCOV_KERNEL=y
#	CONFIG_GCOV_PROFILE_ALL=y
#	CONFIG_GCOV_FORMAT_AUTODETECT=y
TFW_GCOV ?= n

Per subsystem debug output is configured with separate DBG_ variables, for example a line the Makefile gives for Tempesta TLS:

Building the modules with debug output

The same Makefile comment block gives the invocation for a subsystem debug build, and it is the clearest sign of how the developers work.

#	$ DEBUG=1 DBG_SS=2 DBG_TLS=3 make clean all

So DEBUG selects the general debug level, DBG_SS and DBG_TLS turn on the debug output for the security subsystem and the TLS layer, and the build is a make clean all. The Makefile also notes that the most debug-output subsystems have their own DBG_ option while the rest of the code prints debug messages solely on the DEBUG variable, and that DEBUG can be undefined to compile smoothly with 3-party code using the same variable.

That last detail is the kind of thing that only matters in a project that pulls in other people's code, and it suggests the boundary between Tempesta's own modules and the third-party components it embeds is a real one in the build.

The public face of the project is its knowledge base, and the README lists the topics it covers: quick start, design description, system requirements, installation procedures, a configuration guide, use cases, performance tips and benchmarks, high availability, observability through access log analytics, and application performance monitoring. That list is the shape of the operational surface, and it is where a reader should go after this page, since the repository README itself is a summary.

The contribute path is also documented rather than implied, with a link to the Tempesta Contributor's Guide for guidance on making new contributions.

Beta status, branches, and how to install

The Current state section is where the project is honest about itself, and it is a section worth reading carefully before planning an adoption.

We're in Beta state for now. The beta is available by source code or by an installation script that provides binary packages. And then the line that catches most people out: the master branch is a development (and unstable) branch for contributors and early testers only, with the release-0.8 branch to use for a stable version.

The release tags confirm the branch structure, with ubuntu-24/0.8.2 dated 2025-10-02, ubuntu-24/0.8.1 from 2025-08-13 and ubuntu-24/0.8.0 from 2025-03-13. The naming carries the packaging target, so a release is identified by the distribution it was built for, which is what you would expect for a project that ships kernel modules and has to be rebuilt per distribution.

The last push was on 2026-10-10, so the code is being worked on even though the newest tag is from a year earlier. A year between the newest release tag and the last commit is a normal pattern for a project whose releases are gated on kernel compatibility, but it does mean the stable branch and the development branch are a long way apart.

The documentation site is tempesta-tech.com, and the homepage is the same domain. The project is developed by Tempesta Technologies, with the copyright header in the Makefile crediting NatSys Lab for 2014 and Tempesta Technologies from 2015 through 2026, which dates the project back to before the company was founded around it.

Where Tempesta fits against Nginx and HAProxy

The comparison the README itself invites is with Nginx and HAProxy, and the honest answer is that it is a comparison of operating models rather than of features.

Nginx and HAProxy run in userspace. You put them in front of your application servers, they terminate TLS, they balance, and if you want a WAF you add something else, commonly ModSecurity, which then either sits in front of the proxy or inside it. The result is a stack of components, each with its own configuration language, its own upgrade cycle and its own memory footprint, and a request that passes through all of them.

Tempesta collapses that into one binary plus a patched kernel, and it can do the filtering and the load balancing in the same place in the stack. The WAF and the accelerator are the same code path rather than two programs cooperating.

The cost is the thing the README spends most of its words on. Nginx installs with apt. Tempesta requires a kernel built from a patch, and the project ships a script for that, but the operator is now responsible for kernel security updates. A distribution kernel update can also interact badly with a patched one, which is a class of problem that does not exist when you are running a userspace proxy.

So the decision is about who owns the machine. If you already run a patched kernel for other reasons, or you are running bare metal and control the whole stack, Tempesta is a serious option. If your servers are managed instances where you cannot replace the kernel, it is not an option at all, and the rest of the comparison is academic.

Editorial conclusion

Tempesta FW suits an operator who needs filtering, TLS termination and load balancing to happen before a request reaches an application server, and who is prepared to maintain a patched kernel, since the whole design depends on code sitting in the network stack. It is the wrong tool if you cannot patch the kernel, and it is the wrong tool for a team that wants a reverse proxy it can drop in front of an application in an afternoon. Before trying it, read the requirements page in the project wiki, and remember that the master branch is described as a development and unstable branch, so use the release-0.8 branch if you want the stable version.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. tempesta-tech/tempesta on GitHub