Banana Pi BPI-R4 Pro Review: A 10-Gigabit Router Board I Put to Work as a Bastion

A.C. Jokela — Fri, 17 Jul 2026 00:46:59 GMT

Most of the single-board computers I review here are compute boards: you install Debian or Ubuntu, you build software on them, you measure how fast they crunch. The Banana Pi BPI-R4 Pro is a different animal entirely. It is a router - a networking board built around MediaTek's MT7988A (Filogic 880) SoC, shipping with OpenWRT rather than a general-purpose Linux distribution, and designed from the silicon up to move packets rather than compile code. Reviewing it by the same yardstick I use for a Raspberry Pi 5 would be like reviewing a delivery truck by its quarter-mile time. So I did something a little different: I deployed the R4 Pro as a real piece of infrastructure - an internet-facing SSH bastion and TLS reverse proxy sitting in front of a small fleet of machines - and then benchmarked the things a router actually has to be good at.

The short version: the BPI-R4 Pro is an impressively capable networking platform with genuine 10-gigabit ambitions and a crypto engine strong enough to terminate encrypted tunnels at line rate. Its quad Cortex-A73 CPU is modest by 2026 compute-board standards, but that CPU is not the point. The board's constraints - OpenWRT instead of Debian, a tiny writable overlay, a stock kernel with some conspicuous gaps - are exactly the constraints of the router-appliance world it comes from. Here is where it shines, where it frustrated me, and who should actually buy one.

Hardware Architecture: The MediaTek MT7988A (Filogic 880)

At the heart of the R4 Pro is the MediaTek MT7988A, marketed as the Filogic 880. Where a typical SBC SoC is a Rockchip or Broadcom part with a strong CPU cluster and networking bolted on, the MT7988A inverts that priority: it is a networking processor first, with a competent application CPU attached.

The CPU cluster is four ARM Cortex-A73 cores running at 1.8 GHz. Reading /proc/cpuinfo confirms CPU part 0xd09 (Cortex-A73) with the full ARMv8 crypto feature set: aes, pmull, sha1, sha2, and crc32. That crypto flag list matters enormously for a router, and I will return to it.

The Cortex-A73, released by ARM in 2016, is architecturally interesting for a networking chip. It sits between the Cortex-A72 (2015, found in the Banana Pi CM5-Pro) and the Cortex-A76 (2018, found in the Raspberry Pi 5 and Orange Pi 5 Max). The A73 was ARM's efficiency-focused big core - narrower than the A72 in some respects but with better power characteristics and, in practice, comparable or slightly better per-clock throughput. Four of them at 1.8 GHz is a sensible choice for a router: enough headroom to run a full firewall, a reverse proxy, and userspace daemons, without the thermal and power budget of a compute-grade cluster.

What surrounds that CPU is where the money went:

Dual 10 Gigabit Ethernet MACs. Two of the board's interfaces (eth0 and eth2) report a link capability of 10000 Mbps.
A hardware packet-processing engine (PPE) for NAT/flow offload, so routed traffic need not touch the CPU on the fast path.
An inline crypto engine exposed through the ARMv8 AES/SHA instructions, which the kernel and OpenSSL use transparently.
An external MaxLinear switch (the mxl_lan* DSA ports in Linux), which is how the "Pro" and "8X" board variants fan out their many gigabit and multi-gigabit ports.
A WiFi 7 radio (the "BE14" in the stock image name, driven by MediaTek's mt76 stack).

My unit is the BPI-R4-PRO-8X, the higher-tier variant, with 8 GB of RAM - MemTotal reports 8,136,024 kB, roughly 7.76 GiB usable. For a router that is a genuinely generous memory allotment; most consumer routers ship with a fraction of it, and it means the R4 Pro can hold large connection-tracking tables, run containers, or cache aggressively without breaking a sweat.

The Banana Pi BPI-R4-PRO-8X - the MediaTek MT7988A router board reviewed here, with dual 10-gigabit MACs, a MaxLinear switch, and WiFi 7, running OpenWRT

The Board Itself: Ports, Storage, and the Console

Physically, the R4 Pro follows the BPI-R4 family form factor: a router-style board rather than a credit-card SBC, with a bank of Ethernet jacks, SFP+ cages for the 10-gigabit optics, an M.2 slot, USB, and the usual pin headers. The "8X" designation refers to its port fan-out via the MaxLinear switch. In Linux I see eth0 and eth2 as 10G-capable MACs, eth1 as a 1G interface, and a family of mxl_lan0 through mxl_lan5 DSA switch ports hanging off eth2.

Storage is the first place the router DNA shows. The board boots from onboard flash - a squashfs /rom (100 MB, read-only) overlaid with a UBI/NAND overlay for persistent writes. That overlay is small: 48.5 MB total, of which only around 42 MB was free on my unit. There is eMMC on board as well (I booted from it during setup earlier in the board's life), but the running configuration lives on a constrained flash budget by design. Offsetting this, OpenWRT mounts a 3.9 GB tmpfs at /tmp, RAM-backed and fast, which is where any scratch work belongs.

This is not a criticism so much as a category marker. Routers do not have roomy filesystems; they have just enough flash to hold firmware and config, plus RAM for working state. If you come to the R4 Pro expecting to apt install a development toolchain and a few hundred megabytes of dependencies, you will run out of overlay in about four packages. Plan accordingly.

The console deserves a note for anyone deploying one headless. The board exposes a USB-C serial console (an HT42B534-based UART bridge), so a single USB-C cable gets you a boot log and a login shell at 115200 baud without needing a separate TTL adapter. It is a small quality-of-life win that matters the first time a firewall rule locks you out over the network.

Software: OpenWRT, Not Debian

The single most important fact about the R4 Pro - the fact that colors every other observation in this review - is that it runs OpenWRT, not a general-purpose Linux distribution. My unit shipped the BPI-R4Pro-8X-BE14-MT76-OpenWRT24.10 image, kernel 6.6.93.

For anyone who has only used SBCs as tiny Linux PCs, OpenWRT is a different world with its own idioms:

opkg, not apt. Packages come from OpenWRT feeds. The catalog is large - opkg list returned 9,695 packages on my unit - but it is a router-firmware catalog, so you find iperf3, coremark, stress-ng, nginx, and wireguard-tools, not build-essential and python3-dev.
UCI configuration. Networking, firewall, DHCP, and services are configured through OpenWRT's Unified Configuration Interface (/etc/config/*) and the uci command, not by hand-editing /etc/network/interfaces.
fw4/nftables firewall. Modern OpenWRT builds the firewall on nftables via the fw4 layer, organized into zones (LAN, WAN) with per-zone input/forward/output policies.
DSA switch model. The MaxLinear switch ports appear as individual mxl_lanN netdevs bridged together, the modern Distributed Switch Architecture model, rather than the old swconfig VLAN approach.
ash, not bash. The shell is BusyBox ash; the userland is BusyBox. Little things bite you - nproc does not exist, dd rejects conv=fdatasync - until you internalize that you are on an embedded system.

None of this is bad. It is, in fact, exactly what you want if your goal is a router: OpenWRT is battle-tested router firmware with a coherent configuration model, atomic sysupgrades, and a security posture built for internet-facing deployment. But it does mean the R4 Pro is not a drop-in for someone who wanted "a fast little Linux box." It wants to be a network appliance, and it is happiest when you let it.

Performance: How Do You Benchmark a Router?

My standard SBC benchmark is a from-clean Rust compilation of a moderately large ballistics-simulation engine, run three times and averaged. It is a great CPU-and-I/O stress test for a compute board. It is also completely inapplicable here: the R4 Pro has no Rust toolchain, no C compiler in the base image, and a 42 MB writable overlay that could not hold the dependency tree, let alone the build artifacts. Installing a cross-toolchain onto router flash to run a compile benchmark would be measuring the wrong thing anyway.

So I measured what actually determines whether this board is good at its job: raw CPU throughput in a portable benchmark, cryptographic performance (the workload of a bastion, a VPN endpoint, or a TLS proxy), network throughput, and thermals under load. Every number below was measured on the board as configured, running its shipping OpenWRT image.

CPU: CoreMark

CoreMark is the portable, compiler-neutral-ish CPU benchmark that actually runs on embedded systems. Installed straight from the OpenWRT feed (built with GCC 13.3, -O3 -flto), the R4 Pro turned in:

CoreMark run	Iterations/sec
Single thread	9,533
Four threads (aggregate)	37,952

Two things stand out. First, multi-core scaling is essentially perfect - 37,952 is 99.5% of 4x the single-thread figure, which tells you the four A73 cores are genuinely independent and the memory subsystem is not choking under parallel load. Second, the per-clock efficiency is good: 9,533 CoreMark at 1.8 GHz works out to about 5.3 CoreMark/MHz, a strong showing for a Cortex-A73 and comfortably ahead of the A53-class cores that populate cheaper networking boards.

How does that translate against the compute boards I have benchmarked? Honestly - and this is the important framing - the R4 Pro would land near the back of that pack for a heavy parallel workload. My compile-benchmark table runs from the Orange Pi 5 Max (RK3588, eight A76/A55 cores, 62 seconds) down through the Banana Pi CM5-Pro (eight A72/A53 cores, 167 seconds) to the Horizon X3 CM (four A53 at 1.5 GHz, 379 seconds). Four A73 cores at 1.8 GHz sit architecturally between the A72 and A76 on a per-core basis, but with only four cores and a lower clock, the R4 Pro's aggregate compute is modest - comfortably ahead of the A53 boards, well behind the eight-core A76 machines. That is completely fine. A router does not compile Linux kernels for a living; it forwards packets and terminates crypto, and it has plenty of CPU for both.

Cryptography: The Metric That Actually Matters

For a board destined to be a bastion, a VPN concentrator, or a TLS reverse proxy, cryptographic throughput is the benchmark that decides whether it can do its job at line rate. I ran openssl speed (OpenSSL 3.0.21 from the feed) across the ciphers a real deployment uses. Figures below are for 16 KB blocks, the regime that matters for bulk transfer:

Algorithm	Throughput	Hardware accelerated?
AES-128-CBC	1,432 MB/s (~11.5 Gb/s)	Yes (ARMv8 AES)
AES-128-GCM	1,190 MB/s (~9.5 Gb/s)	Yes
AES-256-GCM	1,023 MB/s (~8.2 Gb/s)	Yes
SHA-256	917 MB/s (~7.3 Gb/s)	Yes (ARMv8 SHA2)
ChaCha20-Poly1305	310 MB/s (~2.5 Gb/s)	No (software)
RSA-2048 sign / verify	195 / 7,395 ops/s	—
ECDSA P-256 sign / verify	8,774 / 3,206 ops/s	—

The headline: the R4 Pro can encrypt AES-256-GCM at over a gigabyte per second, which is more than 8 Gb/s of authenticated encryption. That is enough to terminate a fully saturated 10-gigabit TLS or IPsec/AES tunnel on the CPU, before you even reach for the SoC's dedicated crypto offload. The ARMv8 AES and SHA-2 instructions are doing exactly what they were added to the architecture to do.

The most instructive line in that table is ChaCha20-Poly1305. At 310 MB/s it is more than four times slower than AES-256-GCM - not because ChaCha is a bad cipher, but because the A73 has no hardware acceleration for it, so it runs in software while AES rides dedicated instructions. This has a concrete deployment consequence: WireGuard uses ChaCha20-Poly1305 exclusively. So on this board, a WireGuard tunnel tops out around 2.5 Gb/s of crypto, while an AES-GCM-based tunnel (IPsec, OpenVPN in AES mode, or TLS) can push three to four times that. For most home and small-office links - where the WAN is a gigabit or two - 2.5 Gb/s of WireGuard is still far more than the pipe, so it is academic. But if you were dreaming of the R4 Pro saturating a 10G link over WireGuard specifically, temper that expectation; point it at AES instead, or lean on hardware offload.

The asymmetric numbers (RSA and ECDSA) govern TLS handshake rate and SSH key exchange. 8,774 ECDSA P-256 signatures per second is plenty for a bastion fronting a fleet - you are gated by human login rate, not the CPU. RSA-2048 signing at 195/s is unremarkable but, again, not a bottleneck for anything short of a busy public web frontend.

Network Throughput

I measured real network throughput with iperf3 between the R4 Pro and another fleet host on the same LAN segment. An important caveat up front: while the board's eth0 and eth2 MACs are 10-gigabit capable, my deployment wiring negotiated both the LAN and WAN bridges at 1 Gb/s - the R4 Pro was standing in for an older gigabit box, on gigabit infrastructure. So these numbers reflect gigabit wiring, not the board's 10G ceiling.

Direction	Throughput	Retransmits
Download (board receives)	933 Mb/s	0
Upload (board transmits)	720 Mb/s	3,372

The receive path hits gigabit line rate cleanly - 933 Mb/s with zero retransmissions is about as good as TCP over a 1 Gb link gets. The transmit path came in lower at 720 Mb/s with a burst of retransmissions on a single stream, which is the kind of thing that usually improves with parallel streams or a little TCP tuning, and which I would not read too much into on a router whose fast path is hardware-offloaded routing rather than host-terminated TCP. The meaningful takeaway is that the R4 Pro handles gigabit host traffic without breaking stride, and its silicon is built to go far beyond that once you feed it 10-gigabit optics and peers - the ports and PPE offload are there; my wiring simply was not.

Thermals

Routers are frequently fanless, sealed, and left running for years, so sustained thermal behavior is a real concern. Here the R4 Pro was almost boring, in the best way. Idle SoC temperature read 48.9 C. After hammering all four cores flat-out through the CoreMark and OpenSSL runs, it reached 50.3 C - a 1.4-degree rise under full load. That is the signature of a chip with power headroom to spare and a competent thermal solution; there is no throttling drama here, and a passively cooled deployment is entirely realistic.

A Note on Memory and Storage Benchmarks

I tried to characterize memory and flash bandwidth with dd, but BusyBox's dd lacks the flags (conv=fdatasync) my normal harness relies on, and the persistent storage is NAND-with-overlay rather than a benchmarkable block device. The practical picture is straightforward: 8 GB of LPDDR4 is ample working memory for a router, /tmp is RAM-fast, and the flash is small-but-adequate firmware storage rather than a performance surface. If you need real bulk storage, that is what the M.2 slot is for.

The Bastion Build: What I Actually Did With It

Benchmarks characterize a board; deployment reveals it. I put the R4 Pro into production as the replacement for an aging Linux box that had been serving two roles: an internet-facing SSH bastion and a TLS reverse proxy for a handful of internal services.

The topology is a classic small-infrastructure setup. The board carries two addresses at once: a WAN address (192.168.3.21) on the br-wan bridge facing the fiber modem, and a LAN address (10.1.1.13) on br-lan facing the internal network. The fiber modem port-forwards inbound SSH from its public IP to the R4 Pro's WAN address, and forwards ports 80 and 443 there as well. From the board, two very different things happen to those flows:

Port 22 is the bastion login. It terminates on the board's own OpenSSH daemon - there is no proxy in front of it. This is the front door to the whole fleet.
Ports 80 and 443 hit nginx running on the board, which reverse-proxies each virtual host to the correct backend on the 10.1.1.0/24 network - a web app on one machine, an LLM inference endpoint (a token-gated proxy in front of Ollama) on another.

Standing this up on OpenWRT was instructive about the board's strengths and its one real weakness.

On the strengths side, the security posture came together cleanly. I hardened SSH to OpenSSH only, disabling the default dropbear daemon, enforcing key-only authentication, and setting root to prohibit-password. The fw4/nftables WAN zone got an input policy of DROP with explicit allows only for 22, 80, and 443. nginx installed straight from the feed and proxied TLS to internal backends without fuss. The 8 GB of RAM meant I never thought about memory, and the crypto numbers above meant TLS termination was never going to be a bottleneck. As a hardened, internet-facing appliance, the R4 Pro is squarely in its element - this is the job the hardware and firmware were built for.

The one genuine frustration was WireGuard. I wanted to migrate an existing WireGuard hub onto the board, and hit a wall: the stock 6.6.93 kernel in the shipping image did not include WireGuard support, and the kmod-wireguard package from the feed was built against a different kernel revision and refused to load. This is a recurring hazard with vendor OpenWRT images - the kernel is pinned, the module ABI is strict, and out-of-tree kmods have to match exactly. It is fixable (a matching image build, or a sysupgrade to a community build with WireGuard baked in), but it is the sort of speed bump that reminds you that you are on a vendor router image, not a rolling general-purpose distro. Given the ChaCha20 software-crypto ceiling I measured, WireGuard was never going to be this board's showcase feature anyway - but the inability to even load the module out of the box is worth knowing before you plan around it.

Everything else I asked of it, the R4 Pro did without complaint, and it has been a quietly reliable piece of infrastructure since.

Comparative Context

The R4 Pro does not slot neatly into my usual comparison table, because nothing else I have reviewed is a router. The closest relative in my fleet is the Banana Pi R2 Pro (Rockchip RK3568), a previous-generation dual-gigabit router board - but the R4 Pro is a generation and a tier above it in every networking dimension: quad A73 instead of quad A55, 10-gigabit MACs instead of gigabit, WiFi 7 instead of WiFi 5, and hardware offload built for far higher throughput.

Against the compute SBCs, the comparison is really about category, not winner-and-loser. A Raspberry Pi 5 or an Orange Pi 5 Max will compile code two to six times faster than the R4 Pro's CPU could, and they cost less. But neither has 10-gigabit MACs, a hardware packet-processing engine, a bank of switch ports, SFP+ cages, or router firmware. You would spend more time and money bolting networking onto a Pi 5 than you would save on the sticker price, and you would still not have a hardware fast path. Conversely, if your workload is desktop use, AI inference, or software builds, the R4 Pro is the wrong tool and its A73 cluster will feel slow. These boards are not substitutes; they are answers to different questions.

On price, the R4 Pro commands a substantial premium over general-purpose SBCs, and over the base BPI-R4 as well - street pricing varies by region and configuration but lands well north of a typical Raspberry Pi, reflecting the 10-gigabit silicon, the switch, and the WiFi 7 radio rather than the CPU. If you need what it offers, it is reasonable value for a 10G-capable OpenWRT platform with this much RAM. If you do not, none of that premium is buying you anything.

Use Cases and Recommendations

Choose the BPI-R4 Pro if you:

Are building a serious home or small-office router or firewall. This is the core use case and the board excels at it: OpenWRT, hardware NAT offload, 10-gigabit uplinks, a switch, generous RAM, and a CPU with power to spare for firewall and userspace services. It is a genuine alternative to a commercial 10G router or a x86 firewall appliance, at lower power.

Want a hardened, internet-facing bastion or reverse proxy. I proved this one in production. Key-only SSH, an nftables WAN zone, nginx TLS termination, and over a gigabyte-per-second of hardware AES make it an excellent front door - and it sips power doing it.

Need 10-gigabit networking on an ARM/OpenWRT platform. The MT7988A's dual 10G MACs plus SFP+ cages put line-rate 10G within reach, with the PPE keeping routed traffic off the CPU. Few boards in this class and price bracket offer that.

Value RAM headroom on a router. 8 GB is a lot for a networking box. Large connection tables, containerized services (Docker/Podman on OpenWRT), or aggressive caching all become practical.

Choose something else if you:

Want a general-purpose Linux computer. The R4 Pro runs OpenWRT with a tiny writable overlay and BusyBox userland. It is a router, not a workstation. A Raspberry Pi 5, Orange Pi 5 Max, or the Banana Pi CM5-Pro will be far happier and far faster at desktop, development, and compute tasks.

Are prioritizing raw CPU throughput or AI inference. Four A73 cores at 1.8 GHz are modest, and there is no NPU. The compute-focused boards in my reviews leave it well behind on those axes.

Specifically need line-rate WireGuard. The A73's lack of ChaCha20 hardware acceleration caps WireGuard crypto around 2.5 Gb/s, and the stock image did not ship a loadable WireGuard module. Both are surmountable, but if a 10G WireGuard hub is your exact goal, do your homework first - or plan to use an AES-based tunnel.

Want a plug-and-play, beginner-friendly experience. OpenWRT, UCI, DSA, and vendor image quirks reward network-literate users. If you have never configured a firewall zone, the learning curve is real.

Build Quality and Physical Characteristics

The R4 Pro is a well-built router-class board with the port density and connector variety its role demands. The SFP+ cages, M.2 slot, multiple Ethernet jacks, and header banks are laid out sensibly, and the onboard USB-C serial console is a thoughtful touch for a device that will inevitably lock you out over the network at least once. My unit arrived cleanly manufactured with no obvious defects, and as the thermal numbers show, it runs cool enough for fanless or lightly-cooled enclosures. As always with a board that carries 10-gigabit PHYs and a switch, plan for some airflow if you enclose it under sustained heavy load - but my measurements suggest thermal headroom is not a concern at typical router duty cycles.

Conclusion: The Right Tool, Precisely Aimed

The Banana Pi BPI-R4 Pro is not trying to be a fast little Linux PC, and judging it as one would miss the point entirely. It is a purpose-built 10-gigabit router platform, and by that measure it is very good. The MT7988A pairs a modest-but-efficient quad Cortex-A73 with the networking silicon that matters - dual 10G MACs, hardware NAT offload, a switch, and a crypto engine that pushes AES-256-GCM past a gigabyte per second. It runs real router firmware, it carries a generous 8 GB of RAM, it stays cool under full load, and - as I proved by putting it into production - it makes an excellent hardened bastion and TLS reverse proxy.

Its limitations are the honest limitations of its category. The CPU is slow for compute work; OpenWRT and a tiny overlay make it a poor general-purpose machine; ChaCha20 runs in software, so WireGuard specifically will not saturate 10G; and vendor-image kernel pinning bit me when I tried to add an out-of-tree module. None of these are surprises once you accept what the board is: a network appliance, not a computer you happen to network with.

If you are building a router, a firewall, a 10-gigabit homelab core, or an internet-facing bastion, the BPI-R4 Pro deserves a hard look - it delivers networking capability and cryptographic throughput that are genuinely hard to find at its price and power envelope on an ARM/OpenWRT platform. If you want to compile code, run models, or use a desktop, buy a compute board instead. The R4 Pro knows exactly what it is, and so should you before you buy one.

Specifications Summary

Processor:

MediaTek MT7988A (Filogic 880)
4x ARM Cortex-A73 @ 1.8 GHz
ARMv8 crypto extensions: AES, PMULL, SHA-1, SHA-2, CRC32
Hardware packet-processing engine (NAT/flow offload)

Memory & Storage:

8 GB RAM (~7.76 GiB usable) - BPI-R4-PRO-8X unit
Onboard NAND (squashfs + UBI overlay) + eMMC
M.2 slot for expansion storage

Networking:

2x 10 Gigabit Ethernet MACs (SFP+), 1x Gigabit Ethernet
External MaxLinear switch (DSA), multiple gigabit/multi-gig ports
WiFi 7 (BE14, MediaTek mt76)

Software:

OpenWRT 24.10, Linux kernel 6.6.93 (aarch64)
opkg feeds (9,695 packages), UCI config, fw4/nftables, BusyBox userland
USB-C serial console (115200 baud)

Benchmark Performance (as-shipped OpenWRT image):

CoreMark: 9,533 single-thread / 37,952 four-thread (5.3 CoreMark/MHz, ~99% scaling)
AES-256-GCM: 1,023 MB/s; AES-128-CBC: 1,432 MB/s; SHA-256: 917 MB/s (all HW-accelerated)
ChaCha20-Poly1305: 310 MB/s (software)
RSA-2048: 195 sign/s, 7,395 verify/s; ECDSA P-256: 8,774 sign/s
iperf3 (gigabit wiring): 933 Mb/s RX, 720 Mb/s TX
Thermal: 48.9 C idle, 50.3 C under full four-core load

Recommendation: An excellent 10-gigabit OpenWRT router and hardened-bastion platform; not recommended as a general-purpose or compute SBC.

Review Date: July 16, 2026

Hardware Tested: Banana Pi BPI-R4-PRO-8X (MediaTek MT7988A) with 8 GB RAM, deployed as SSH bastion + nginx reverse proxy

OS Tested: OpenWRT 24.10 (BPI-R4Pro-8X-BE14-MT76 image), Linux kernel 6.6.93

Conclusion: A purpose-built 10-gigabit router board that excels at networking and cryptographic workloads and makes a superb hardened bastion - reviewed, and recommended, as the network appliance it is rather than the compute SBC it is not.

TinyComputers.io (Posts about reverse proxy)