VPN memory use on OpenWrt: measured on 128 MB

On a small OpenWrt virtual machine, the ForestVPN router client process and OpenVPN each held a few megabytes of resident memory. Kernel WireGuard has no process to measure at all.

Most "OpenWrt VPN memory" searches ask whether a small router has room for a VPN. None of the results we could read gives a measured per-component figure, so this page gives one table. Each number says which image, memory cap, package version and day it came from. We also say what the run could not see.

How much memory does a VPN use on 128 MB OpenWrt?

On one 128 MB virtual machine, each userspace piece held between 4.2 and 5.5 MB resident, and the kernel pieces were measured separately because a process table cannot show them. Here is what ran, and under what conditions.

For scale, the same guest held uhttpd at 1664 kB, rpcd at 1920 kB, dnsmasq at 1200 kB and dropbear at 888 kB of resident memory after boot.

Both ForestVPN rows are one binary in two shapes:

• fv run is the tunnel core.
• fv up is the account agent that registers the router with ForestVPN.

An earlier run on 2026-10-04, on x86_64 OpenWrt 24.10 with an older build, printed about 4.1 to 4.2 MB for fv run and 4.3 MB for fv up (that run recorded 4104 to 4168 kB and 4308 kB).

Today the run shape sits at about the same size, while the up shape rose from 4.3 to 4.8 MB. The growth is in file-backed pages: RssFile went from 3376 to 3824 kB, and the binary from 4,229,592 to 4,717,984 bytes.

What did the ForestVPN client hold over 120 seconds?

Our client, the ForestVPN router client (package forestvpn, binary fv, interface fvpn0), held 4.2 MB resident at ten seconds and 4.3 MB from twenty seconds on, flat to the end of the two minutes. The anonymous part, the memory only this process owns, stayed at 928 kB for the whole window.

Most of the rest, about 3.3 MB, is file-backed, and that part is mostly the program itself. The kernel documentation defines RssFile as the resident file mappings, and the client is a single static binary of 4,717,984 bytes, so most of its resident size is the file mapped into memory. That is why a VmRSS figure overstates what the process holds privately.

MemAvailable, the kernel's estimate of memory a new program could use without swapping, gives one noisy pair and no more. It read:

• 22384 kB just before the client started.
• 17664 kB ten seconds after, a drop of about 4.7 MB.
• 19492 kB at 120 seconds, 2.9 MB below the start.

We dropped no caches for these samples and ran no cycles, so that pair can neither confirm nor refute the RssAnon reading.

The fv up shape stayed at 4.8 MB, with a peak of 4864 kB. Its anonymous part crept from 940 to 980 kB while it retried an unreachable catalog.

One caveat: we measured a build from the same source and features, not the installed package, so treat these numbers as those of the binary.

How much memory does OpenVPN use on OpenWrt?

OpenVPN's process held 5.3 to 5.5 MB resident across three start-and-stop cycles: 5456, 5296 and 5344 kB. About 1.3 MB of that was anonymous, memory the process wrote to itself, and 4.0 to 4.1 MB was file-backed.

OpenVPN is a separate userspace daemon that opens a TUN device, a virtual network interface the kernel hands to a program, as the OpenVPN reference manual describes.

Installing openvpn-openssl pulled in libopenssl3 and the kernel modules tun and ovpn. Those modules never show up in the process's VmRSS.

It never finished a TLS handshake here. A session that has authenticated, pushed routes and carried traffic may well hold more, and we make no claim about it.

IVPN's OpenWrt guide, written for OpenWrt 23.05.5, walks through a similar OpenVPN setup and gives no memory figure, which is the gap this table fills for one configuration.

What does kernel WireGuard cost if it has no process?

Kernel WireGuard costs a module and an interface, and on this guest the interface's cost was smaller than the noise.

We installed kmod-wireguard and wireguard-tools with apk, OpenWrt's package manager since 25.12 (opkg on 24.10 and older), loaded the module before the first cycle so it was present in both states, then switched the wg9 interface on and off three times. The module's own cost comes from its lsmod size, given below. With no process to read, MemAvailable is the only gauge, so each state is the median of three samples.

OpenVPN's drop of 4.3 to 7.1 MB is the same order as its 5.3 MB resident size, within this run's noise.

The WireGuard drops of 0.6 to 2.1 MB cannot be told apart from the baseline, which slid from 43776 kB to 41480 kB across the three cycles with no change on our side. The module itself is 61440 bytes, with ChaCha20-Poly1305 and Curve25519 helper modules beside it, and the WireGuard install page lists OpenWrt among its platforms.

Both are small. This run cannot rank them to the megabyte.

Why does MemAvailable on OpenWrt look so low?

Because the kernel, the page cache, the in-memory filesystems and the router's own daemons are already in memory before any VPN arrives. Our guest reported 107760 kB total and 25908 to 26076 kB available in three readings after boot, with LuCI, uhttpd, dnsmasq and the SSH server running. /tmp is a tmpfs, so files written there sit in RAM too.

A reading of 26 MB available does not mean the rest is wasted. It is the kernel's estimate of what a new program could use without swapping.

The baseline moved by several MB with nothing of ours running: between the OpenVPN cycles, the off state alone swung from about 39 to 42 MB. The after-boot reading and the cycle run's off states come from different boots and conditions (caches were dropped before each cycle sample), and this run does not explain the gap. One pair of readings proves nothing here, which is why the cycles above are the evidence.

How do you read free, MemAvailable and VmRSS on OpenWrt?

Read MemAvailable for the whole system and VmRSS for one process, and expect them to disagree. The kernel documentation describes MemAvailable as an estimate of memory available for starting new applications without swapping, computed from free memory, reclaimable slab, file cache and the low watermarks. free prints the same figure in its available column.

By that documentation a process's VmRSS is the sum of RssAnon, RssFile and RssShmem. Shared file pages count in every process that maps them, and kernel modules count in none.

These commands, or close to them, ran on the guest. BusyBox's pidof can return several PIDs, hence the cut.

free
grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached' /proc/meminfo
p=$(pidof uhttpd | cut -d' ' -f1)
grep -E 'VmHWM|VmRSS|RssAnon|RssFile' /proc/$p/status
lsmod | grep -E '^(wireguard|tun|ovpn) '

For a before-and-after comparison, flush the page cache first, as we did before every MemAvailable sample in the on/off cycles, and repeat in cycles.

sync; echo 3 > /proc/sys/vm/drop_caches

Can a 128 MB router run a VPN client?

On memory alone, our run says the client process is a small part of the guest's memory, and OpenVPN is close to it in size. That is one image, on x86 emulation, with the router doing nothing else.

The run cannot answer two things.

Smaller router: we ran nothing on 64 MB, so there is no verdict here, and ForestVPN's install help lists 128 MB for its MIPS builds and says the installer refuses a router with too little memory or storage before changing anything.

Busier router: one also running a large blocklist, a second VPN or extra LuCI apps will have less room than our guest did.

Memory is also not the only limit. Flash decides whether a package installs at all, and CPU decides how fast it moves packets. We have a dated throughput comparison for other hardware in our CPU-cycle post and none for OpenWrt. For the wider choice between a hand-built tunnel and a managed one, see the OpenWrt WireGuard guide; the MikroTik versus OpenWrt comparison covers the other router platform.

How much memory does a VPN use under load, or on ARM and MIPS routers?

This run cannot say: a connected tunnel under load, CPU, flash use and throughput were not measured, and neither was any real router, any ARM or MIPS CPU, or the installed forestvpn package.

The arm64 image of this release did not boot at the same memory cap in our lab, so there is no arm64 figure and the x86 numbers must not be carried over to one. A binary's memory use differs by architecture, and QEMU's emulated CPU and kernel allocation are not a router's.

Every peer and server in the run was unreachable on purpose, so no handshake completed. Memory during a live, busy tunnel is the number most readers want, and it is the one missing. If a tunnel stops carrying traffic on your router, the no-internet troubleshooting post is the better place to start.

Which VPN should you run on a small OpenWrt router?

Pick on the work each one leaves you, because all three were small next to the guest's total memory. Kernel WireGuard adds a module you may already have installed, and the two userspace programs both fit comfortably in this run.

What differs is the job around the tunnel. A hand-built WireGuard or OpenVPN setup needs its own firewall zone and kill switch; the ForestVPN client brings its own, described on the kill switch page, with its limits on the trust and limits page and the device modes page.

The kill switch is never absolute: it covers the devices ForestVPN protects, not the router's own traffic and not devices on Direct, and under Standard protected devices go direct in the cases that page lists. Its help page says it is not yet verified on hardware as a whole, and the install steps are not yet verified on hardware. Install availability for your firmware is on the install page.