TinyComputers.io (Posts about wireguard)

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.

The Tunnel Was the Easy Part: Site-to-Site WireGuard Between My House and a VPC

A.C. Jokela — Mon, 15 Jun 2026 21:30:00 GMT

The Tunnel Was the Easy Part: Site-to-Site WireGuard Between My House and a VPC

For about three years, a PostgreSQL database that runs dozens of projects — portfolio data, home-automation history, a dozen scraped feeds — had its port 5432 listening on the public internet. Not wide open: it sat behind a long password and TLS, the rest of the host was hardened, and nothing had ever gone wrong. But "open to the internet behind a password" is the kind of sentence that sounds fine right up until it doesn't, and I'd been meaning to fix it for months.

The fix I wanted wasn't a bastion host, and it wasn't a clutch of /32 firewall exceptions I'd have to update every time my home IP changed. I wanted the database to simply not be reachable from the public internet — and to reach it anyway, from my house, as if the AWS VPC it lives in were just another room in the building.

That's a site-to-site VPN. And the moment you say "VPN" in 2026 you mean WireGuard, because the alternatives — IPsec, OpenVPN — are heavier, slower, and far more painful to reason about. WireGuard is a few thousand lines of kernel code, a dozen lines of config per side, and a security model you can hold in your head: every peer is a public key, and a packet is either from a key you trust or it's dropped.

So I expected the WireGuard part to be the work. It wasn't. The WireGuard part took about fifteen minutes and came up on the first handshake. The other day and a half went to an IP-address collision I'd created years earlier, a load-balancing router that kept quietly breaking the tunnel's return path, and the slow realization that a VPN doesn't connect two networks so much as force you to confront every assumption each of them made while pretending the other didn't exist.

As an aside, my last dabbling with VPNs and such was during my FreeBSD phase in the early 2000s. To be more precise, February of 2005. I had an article published in Daemon News on using Racoon and X.509 certificates for IPSEC.

This is the story of the parts that weren't WireGuard.

The shape of the thing

Two networks. At home, a flat 10.1.1.0/24 LAN behind a MikroTik router — laptops, a large handful of Linux hosts, a few BSD hosts, the usual home-lab sprawl. In the cloud, an AWS VPC on 10.0.0.0/16 with the database sitting on a private address, 10.0.0.76, that I'd very much like to be the only way to reach it.

The naive instinct is to put WireGuard directly on the database host. Don't. The endpoint that terminates a site-to-site tunnel becomes a router — it forwards packets for an entire subnet, runs ip_forward, owns firewall and NAT rules — and you do not want that responsibility tangled up with your most important stateful service. Give it its own box.

So the tunnel terminates on a dedicated gateway instance: a t4g.nano (the smallest Graviton box AWS sells, a few dollars a month, comfortably inside the free tier) with an Elastic IP so the home side always has a fixed address to dial, and — critically — with its EC2 source/destination check disabled, because by default AWS drops any packet whose source or destination isn't the instance itself. A router's entire job is to handle packets addressed to other machines; leave that check on and the gateway silently swallows everything it's supposed to forward.

The home end of the tunnel lives on one of my always-on Linux boxes. It dials out — the house is behind NAT and a dynamic-ish IP, so it can't be dialed into — and the AWS gateway, with its stable Elastic IP, waits to be reached.

Between them I gave the tunnel its own little address space, a /30 carved out of a range that exists nowhere else in either network: 10.99.99.0/30. The gateway is 10.99.99.1, the house is 10.99.99.2. That deliberate, unused /30 turns out to matter enormously, for reasons that won't be obvious until the routing breaks. Hold onto it.

WireGuard, the easy twenty percent

Here is essentially the entire VPN. On the AWS gateway:

[Interface]
Address = 10.99.99.1/30
ListenPort = 51820
PrivateKey = <gateway private key>
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT

[Peer]
# the house
PublicKey  = <home public key>
AllowedIPs = 10.99.99.2/32

And on the home box:

[Interface]
Address = 10.99.99.2/30
PrivateKey = <home private key>
PostUp   = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

[Peer]
# the AWS gateway
PublicKey  = <gateway public key>
Endpoint   = 203.0.113.10:51820     # the gateway's Elastic IP
AllowedIPs = 10.0.0.0/16, 10.99.99.1/32
PersistentKeepalive = 25

wg-quick up wg0 on each end — or systemctl enable --now wg-quick@wg0 to make it survive reboots — and within a second or two wg show reports a handshake. Ping 10.99.99.1 from the house; it answers. The cryptographic part, the part everyone is nervous about, is done.

Two fields carry almost all the meaning. AllowedIPs is doing double duty — it's both an access-control list (packets arriving from this peer are only accepted if their source falls inside it) and a routing table (packets you send to those destinations get encrypted and shipped to this peer). On the home side I list 10.0.0.0/16 because that's the VPC I want to reach; that single line installs a route sending all VPC-bound traffic into the tunnel. PersistentKeepalive = 25 is on the home side only, and it's there because the house initiates from behind NAT: without a packet every 25 seconds, the NAT mapping that lets return traffic find its way home expires, and the tunnel goes deaf until the next outbound packet wakes it. The side with the stable public address doesn't need it; the side hiding behind NAT does.

That's the whole VPN. If your two networks were sensibly addressed and your path were clean, you would be done, and this would be a very short post.

The first wall: you can't route to your own house

The tunnel was up, but a tunnel is just a wire. For a machine inside the VPC to send a reply back to my house, the VPC has to know that house-bound packets go to the gateway instance. That's a route-table entry: destination 10.1.1.0/24 (my home LAN), target the gateway's network interface. I added it.

AWS rejected it:

Route destination doesn't match any subnet CIDR blocks

It took me an embarrassing minute to understand, and then a much longer one to forgive my past self. Years ago, for reasons that made sense at the time and that I have completely forgotten, I had given this VPC a secondary CIDR block of 10.1.0.0/16. My home LAN, 10.1.1.0/24, lives entirely inside that /16. As far as the VPC is concerned, 10.1.1.0/24 is local — it's part of the VPC's own address space — and AWS will not let you install a route that's more specific than a local one. You cannot route to a place the network already believes it is.

This is the oldest mistake in site-to-site networking and I'd walked straight into it: the two address spaces overlapped. RFC 1918 hands you 10.0.0.0/8 — sixteen million addresses — and the one discipline that makes joining networks painless is to carve home and cloud out of ranges that can never collide. I hadn't. And re-addressing a production VPC, or renumbering my entire house, to fix a self-inflicted overlap was not a Tuesday-afternoon project.

So I didn't fix the overlap. I routed around it — and this is where that deliberate, unused /30 earns its place.

One address to stand for a whole house

Look again at the home config: PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE. That one line is doing the heavy lifting. It tells the home box to source-NAT every packet leaving the tunnel so it appears to originate from the tunnel interface's own address, 10.99.99.2. From the VPC's point of view, my entire house — every laptop, every Linux box, the whole 10.1.1.0/24 — collapses into a single client at 10.99.99.2.

And 10.99.99.0/30 lives outside every CIDR the VPC claims. So the route AWS refused to accept for 10.1.1.0/24 is perfectly legal for 10.99.99.0/30: destination 10.99.99.0/30, target the gateway interface. Accepted instantly. The VPC never has to route to the contested 10.1.1.0/24 at all, because it never sees 10.1.1.0/24 — every reply goes to 10.99.99.2, an address it's allowed to know about, and the gateway tunnels it home.

The cost of this trick is honesty about its asymmetry. Masquerade collapses a network into a point, and points don't have interior structure. Traffic the house initiates to the cloud works beautifully; the VPC sees one client and answers it. Traffic the cloud initiates toward an individual home machine has nowhere to land — to AWS, 10.99.99.2 is the whole house, with no way to address the laptop behind it. For my purpose — reaching cloud services from home — that's exactly the direction I needed, and the asymmetry is free. If you need the VPC to open connections into specific home hosts, you're back to real routes and real subnets, which means back to not overlapping your address spaces in the first place. Pick your ranges so that future-you never has to make this choice.

The second wall: a router doing exactly what I told it

With routing sorted, the tunnel worked — and then, intermittently, didn't. The handshake was solid. Small things — a ping, a quick psql connection — went through. But sessions would stall, and throughput was a coin flip. The classic shape of a working control path and a broken data path, which usually screams MTU (more on that later). It wasn't MTU. It was my own router being obedient.

My house has two internet connections, load-balanced on the MikroTik with per-connection-classifier (PCC) mangle rules — the standard dual-WAN recipe that pins each new connection to one uplink or the other so a single flow doesn't get split across two public IPs. Which is the entire problem. WireGuard is one long-lived UDP flow to a fixed Endpoint. The PCC rules looked at the tunnel's packets, classified them like any other connection, and cheerfully load-balanced them — sending some out WAN 1 and some out WAN 2. But the gateway had completed its handshake with whichever public IP came first, and a reply arriving from the other WAN's address didn't match the cryptographic session. WireGuard, correctly, dropped it.

The fix is a single exemption at the top of the mangle chain: traffic to or from the WireGuard endpoint is accepted before the PCC rules ever see it, pinning the entire tunnel to one WAN. In MikroTik terms, a mangle rule matching the WireGuard port and destination with an action=accept ahead of the connection-marking rules. The moment that landed, the flakiness vanished.

The lesson generalizes past MikroTik: a VPN tunnel over a multi-WAN uplink must be pinned to one path. And the deeper lesson is the one I keep relearning — this bug didn't come from the new thing. The router was doing precisely what I had configured it to do, years ago, for a completely unrelated reason. The tunnel just walked into a decision that had been sitting there, correct and forgotten, waiting for a single long-lived UDP flow to make it wrong.

Making it useful: split-horizon DNS

A tunnel that routes private addresses is only half a win. My home cron jobs and scripts didn't connect to 10.0.0.76; they connected to a hostname, and that hostname resolved — on the public internet, as it must — to the database's public address. Routing it privately is pointless if the name still points at the front door.

The answer is split-horizon DNS: the same name resolving differently depending on where you're standing. On the LAN I want db.example.net to mean 10.0.0.76; everywhere else it should keep meaning the public address. Two small overrides do it. A static DNS entry on the MikroTik (db.example.net → 10.0.0.76) catches anything using the router as its resolver, and a matching local-data line in the Unbound instance that actually serves the 10.1.1.0/24 segment catches the rest:

local-zone: "db.example.net." transparent
local-data: "db.example.net. IN A 10.0.0.76"

Now every home machine reaches the database over the tunnel, by name, with zero application changes — the code doesn't know or care that the address it gets back is private. The backup job that used to copy dumps across the public internet now runs entirely inside the tunnel.

One caveat worth stating because it bit me for ten confused minutes: split-horizon is per resolver. My main workstation sits on a different subnet — 192.168.0.x, behind a different router with a different upstream resolver — and it never sees the LAN's Unbound, so it kept resolving the public address and connecting the old way. A DNS horizon only covers the clients that actually ask the resolver you edited. Map your resolvers before you trust the trick.

The gotcha everyone eventually hits: MTU

I promised to come back to MTU, because it is the single most common way a WireGuard tunnel "works but doesn't," and the symptom is exactly the one I thought the dual-WAN bug was: the handshake succeeds, small requests fly, and then a large transfer hangs forever with no error anywhere.

WireGuard wraps every packet in roughly 60–80 bytes of encapsulation, which drops the usable MTU inside the tunnel to about 1420 bytes. On a clean path this is invisible. On a path that drops oversized packets without sending the ICMP "fragmentation needed" message back — and plenty of the internet does, because plenty of the internet firewalls ICMP into oblivion — full-size data packets vanish silently while the small control packets sail through. The cure is MSS clamping: an iptables rule on the forwarding chain that rewrites the TCP maximum-segment-size of passing connections down to fit the tunnel.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

In the interest of honesty: my home-to-AWS tunnel didn't need this. A 330 MB database dump rsync'd across it on the first attempt, full speed, no clamp. But a second tunnel I stood up later — a cloud-to-cloud hop over a different path, joining a second provider into the same private fabric — reproduced the "connects fine, transfers hang" symptom perfectly, and the clamp on both ends fixed it instantly. It's path-dependent, which is exactly why it's so maddening to diagnose. Reach for it the instant authentication succeeds but bulk data stalls; it is cheap insurance and an even cheaper first guess.

What it bought

With the tunnel carrying traffic and the name resolving privately, the actual goal became a one-line change. The database's security group dropped its 0.0.0.0/0 rule on 5432 and replaced it with the gateway and the VPC. The port that had been answering the entire internet for a year now answers exactly one place: the wire to my house. The home backup runs over the private path. My laptop talks to the database as if AWS were a closet down the hall.

The bill for all of this is a t4g.nano and an Elastic IP — call it a few dollars a month, much of it inside the free tier — plus a /30 of address space and a handful of config lines that now live in version control next to everything else I'd need to rebuild the setup from scratch. And the VPC stopped being a remote, walled-off place I reach through public endpoints. It became a routable extension of my own network, which changes what feels reasonable to build there next.

The tunnel was the easy part

Add it up and the proportions are absurd. The WireGuard configuration — the cryptography, the key exchange, the part that is genuinely hard to get right and that brilliant people spent years making bulletproof — was a dozen lines per side and worked on the first handshake. Every hour after that went to problems that had nothing to do with WireGuard: an address-space overlap I'd authored years earlier and forgotten, a load-balancing router executing old instructions faithfully into a new failure, a DNS horizon that stopped at a subnet boundary, an MTU gremlin lying in wait on the next path over.

None of those are VPN problems. They're the problems a VPN reveals. Two networks each grew up as the center of their own universe — chose their address ranges, their routing policies, their resolvers — with no expectation of ever meeting. The tunnel is just the introduction. Everything afterward is the negotiation between two designs that were each, locally, perfectly correct, and that turn out to disagree the moment you ask them to share a routing table.

So the practical advice compresses to almost nothing. Give the tunnel its own box and its own unused /30. Keep a keepalive on the side behind NAT. Pin the flow to one WAN if you have more than one. Clamp the MSS the moment large transfers stall. And, above all the rest: choose your private address ranges, on day one, so that home and cloud can never collide — because the fifteen minutes WireGuard costs you is real, and so is the day and a half that an overlapping /16 will cost you somewhere down the line, long after you've forgotten you created it.

The encryption is solved. The hard part was never the secret. The hard part was the addresses.