Performance evidence & release verification

The Gateway publishes two different kinds of performance information, and they should not be confused:

Release verification is an observed pass/fail result from live reference nodes.
Sizing guidance is a planning estimate for choosing hardware. It is not a benchmark guarantee.

What v2.13.1 verified

The v2.13.1 release was exercised on two Linux reference nodes. Both nodes passed:

18 of 18 node-verification checks
9 of 9 traffic-leak checks

The release’s verification record reports these results for an arm64 Raspberry Pi 4 and an amd64 Linux VPS. The node verifier checks service-unit integrity, credential storage and access controls, file permissions, kill-switch table presence and boot-time forwarding configuration, node identity, and the leak-check endpoint. The nine leak checks are included in that node-verification run; these are not 27 independent tests.

On the Pi, the release record also describes tunneled upstream DNS, DNS interception, DNSSEC, forwarded DoH/DoT and STUN blocking, and no global IPv6. On the VPS it records DNS over TLS with no observed port-53 packets during the capture. See the v2.13.1 release notes for the associated fixes.

These results demonstrate that the tested configurations passed the published checks. They do not prove a universal throughput number, every hardware combination, or every VPN provider.

This is a summary of the project’s release verification, not an independent audit or a claim that every failure scenario was exercised. The binaries hosted by this site are stripped builds from the same release tag; their checksums identify these hosted artifacts, not the reference nodes’ original build artifacts.

What is estimated

Sizing & performance provides hardware-selection guidance, not a measured throughput table. This page does not publish a raw, reproducible v2.13.1 throughput dataset. Test the exact CPU, kernel, tunnel provider, MTU, and privacy level you intend to operate before choosing hardware against a bandwidth target.

Reproduce a throughput test

Use two systems you control and record the complete test context:

Record gateway hardware, CPU governor, Linux kernel, The Gateway version, tunnel type, MTU, privacy level, and number of active tunnels.
Run a direct baseline with iperf3 before enabling the policy path.
Repeat through the intended tunnel and privacy level.
Test both upload and download for at least 60 seconds.
Capture CPU, memory, packet loss, retransmits, and tunnel state during the run.
Repeat the test at least three times and report the median, not the best result.

Example client commands:

iperf3 -c <server-ip> -t 60 -P 4
iperf3 -c <server-ip> -t 60 -P 4 -R

Do not use a public speed-test result as proof of gateway throughput: ISP congestion, browser overhead, and the remote test server add uncontrolled variables.

Verify fail-closed behaviour

A useful validation is not only “does traffic pass?” but “does traffic stop when protection fails?”

Run this disruptive test on a test node or during an agreed maintenance window with a recovery path. It is a suggested operator procedure, not part of the pass counts above.

Confirm the protected client reaches the expected public exit.
Stop or disconnect the selected tunnel.
Confirm new internet connections from that client fail instead of falling back to the WAN.
Restore the tunnel and confirm connectivity returns without removing the policy.
Run the DNS leak checks again after recovery.

See Fail-closed routing for the expected state transitions and limitations.

Evidence policy

When a number on this site is measured, the page should identify the hardware, software version, test method, and scope. When those details are unavailable, the number remains explicitly labelled as an estimate.

Sizing & performance — hardware selection and scaling guidance.
Release notes — current version and observed verification results.
Threat model — what the product is designed to protect.
Operations playbook — routine checks for a live gateway.