Fireperf sharpens firewall performance testing

Last updated: November 3, 2026

A network administrator can see excellent throughput and still face a serious problem: the firewall may struggle when thousands of short-lived connections arrive or when it expires idle sessions too quickly. That distinction matters during firewall performance testing.

According to Help Net Security, the IPFire project has released fireperf, a free, open-source tool designed to measure how firewalls, routers and other stateful systems handle connection churn.

Fireperf at a glance

• Fireperf opens connections at a controlled, fixed rate and reports how the tested device handles each one.
• It records handshake duration and distinguishes timeouts, refusals and local resource failures.
• It keeps connections open, rechecks them and identifies state discarded after long idle periods.
• It supports multiple simultaneous clients, iperf interoperability and JSON output.
• Signed packages are available for several major Linux distributions.

What Fireperf measures

Traditional bandwidth testing answers one question: how quickly can two systems move data? A firewall must also create connections, track their state and decide when that state should expire. Fireperf focuses on that second layer of performance.

The tool opens connections at a predetermined rate rather than simply pushing a fixed amount of data through a link. For every connection, it records how long the handshake took. When a connection cannot be established, fireperf can identify whether the cause was a timeout, a refusal or the test machine exhausting its available resources.

Fireperf can also hold connections open and revisit them later. That makes it possible to observe whether a firewall removes state after a prolonged idle interval. A high throughput result alone would not reveal this behavior, which is why the new tool complements rather than replaces conventional bandwidth testing.

The reporting options suit different environments. In a terminal, fireperf presents a live graph and an overview of the connected clients. Without a terminal, it can print results line by line. Its JSON mode emits one object each second, allowing administrators or developers to process the measurements through their own tooling.

How it differs from iperf3

Fireperf works with iperf3 and iperf servers, and iperf3 clients can run tests against a fireperf server. It can also reproduce request-response patterns, including a small request followed by a much larger response.

A significant operational difference is concurrency. Fireperf supports multiple clients on the same port at once, with each client running its own test. Iperf3 normally handles one test at a time. That difference is valuable when the goal is to put a firewall or intrusion prevention system under sustained connection pressure rather than measure raw transfer speed.

The design is event-loop based, according to Rico Hoppe, fireperf’s creator. He said the project began as an experiment after existing tools could not generate enough traffic for the team’s testing needs.

Why this matters

Firewall performance testing becomes more meaningful when administrators examine several signals together. Throughput shows how efficiently data moves. Connection rate shows how quickly a device accepts new sessions. Handshake timing reveals delays, while idle-state checks expose whether long-lived sessions survive as intended.

The trade-off is additional complexity. Fireperf is free and open source, but source installations require a C compiler, Autotools, pkg-config, ncursesw, gettext and intltool. The optional but recommended liburing dependency must be version 2.3 or later. Signed packages simplify deployment on Debian, Arch Linux, RHEL and compatible distributions such as AlmaLinux and Rocky Linux, as well as openSUSE Tumbleweed.

Organizations interested mainly in maximum transfer speed may continue using iperf3 alone. Administrators evaluating firewalls, routers or intrusion prevention systems under heavy session churn get a more relevant tool.

A practical scenario for security teams

Say you operate a spam protection service behind a firewall and notice that incoming mail workflows slow during peak periods. A throughput test might look healthy while failing to explain the slowdown.

Fireperf could be used to reproduce the condition with a controlled stream of short connections and a request-response pattern resembling the service’s traffic. The administrator could then review handshake timing, connection failures and the number of sessions that disappear after remaining idle. If the tests show premature state expiration or an inability to sustain new connections, the results provide evidence for investigating firewall capacity or configuration.

That does not make fireperf a spam filter or a complete security assessment. Its value is diagnostic: it helps separate a bandwidth problem from a connection-management problem.

What to watch next

Fireperf should be treated as a companion to iperf3, not a universal replacement. The next important signals will be how administrators incorporate its connection and state measurements into routine testing, whether its JSON output supports easier automated analysis, and how broadly its package availability expands.

Bottom line: for firewall performance testing that goes beyond transfer speed, fireperf adds a useful view of connection churn, handshake behavior and idle-state retention.

Key takeaways

• Use fireperf when the question involves many new connections rather than only maximum throughput.
• Review handshake times, failure reasons and idle-session behavior alongside standard bandwidth results.
• Test iperf and fireperf together to distinguish transfer capacity from connection-management performance.
• Prefer signed Linux packages where available, but note the dependencies required for source builds.