OpenWrt WireGuard: three ways to run a VPN

An OpenWrt router can hold a VPN in three different shapes, and each of the top results for this topic teaches a single path: one provider, one protocol. You can build a WireGuard interface by hand in LuCI, run an OpenVPN tunnel, or install a managed client that creates and watches the interface for you. Each ends with a tunnel on the router and each leaves a different job on your desk.

Before you copy any command, check the version: OpenWrt switched its package manager at 25.12, from opkg on 24.10 and older to apk on 25.12 and newer, so a command from an older guide may not run on a new router.

Can OpenWrt run WireGuard?

Yes: WireGuard is a Linux kernel feature, OpenWrt is a Linux distribution for routers, and the two fit. WireGuard's own site describes it as securely encapsulating IP packets over UDP: you add a WireGuard interface, give it your private key and your peers' public keys, and send packets across it.

Moving packets is the easy part. The work is everything around it. The tunnel needs a firewall zone, a forwarding rule from your LAN to that zone, masquerading so replies come back, a decision about DNS, and an answer to the question "what happens when the tunnel drops?". WireGuard does not decide any of that. Its site says key distribution and pushed configuration are out of scope for the protocol, so a router guide has to supply them, or a client does.

That gap is the real subject.

Which of the three routes fits a router?

Manual WireGuard gives the most control and the most chores, OpenVPN is the mature option with its own daemon and certificates, and a managed client trades control for fewer steps. The table is read from our code and help pages and from the primary documentation of the two protocols; the box under it says exactly what was read and when.

The figure for speed is blank for a reason. We have no OpenWrt throughput number of our own, and the one we do have, from two MikroTik routers, belongs to a different box and does not transfer.

How do you set up a WireGuard client in LuCI by hand?

You create an interface, add one peer, give the interface a firewall zone, and allow forwarding from your LAN into it. Four jobs, in that order. Skip the last two, or leave Route Allowed IPs unticked, and you get the classic result: a tunnel that shows a handshake and carries nothing.

1. Install the packages. wireguard.com's install page shows # opkg install wireguard for OpenWrt and points to the OpenWrt wiki for the rest. That command is opkg, which is the package manager on 24.10 and older; OpenWrt 25.12 and newer use apk, so the same job is written differently there.
2. Add the interface. In LuCI, Network > Interfaces > Add new interface, protocol WireGuard VPN. Generate or paste the private key. Give it an address inside the tunnel's range, which your provider or your own server tells you.
3. Add the peer. The peer is the other end: its public key, its endpoint (an address and a UDP port), and the allowed IPs. Allowed IPs are WireGuard's routing table in miniature. Per the project, each peer is tied to the list of tunnel addresses allowed inside the tunnel for that public key. Setting it to 0.0.0.0/0 allows everything, but on OpenWrt no route enters the interface unless you also tick the peer's Route Allowed IPs box (route_allowed_ips); with it ticked, a narrower list sends only those ranges.
4. Zone and forwarding. Put the new interface into its own firewall zone, enable masquerading on that zone, and allow forwarding from lan to it. Without masquerading the far end sees private LAN addresses it cannot answer.

Then check it by looking, not by pinging. Open a what-is-my-address page from a LAN device. If it shows your home address, the traffic never entered the tunnel.

If the tunnel is up and pages hang, the culprit is often the MTU, the largest packet the link carries, rather than keys. A tunnel adds a header, so the largest packet that fits inside it is smaller than the link allows. Our post on a VPN that is connected with no internet walks through that symptom and the other ways a live tunnel can carry nothing.

Do you need kmod-wireguard and wireguard-tools by hand?

Not if you name the right package. The LuCI protocol package, luci-proto-wireguard, is the one that adds the WireGuard option to the interface screen. The kernel module is kmod-wireguard and the command-line tool is wireguard-tools. In normal use you ask the package manager for the LuCI package and it brings its dependencies with it.

We did not check that dependency chain against the OpenWrt wiki, so treat the line above as the common experience, not a statement from the project. Open the wiki's package page for WireGuard before you rely on it on a router with little flash storage.

Our own client is different. The ForestVPN router client (package forestvpn, interface fvpn0) is one package. It carries its own tunnel code in userspace instead of using kmod-wireguard, so installing it does not require the kernel module at all.

Is WireGuard as good as OpenVPN on a router?

It depends on what you value, and we will not name a winner. What we can do is lay out the differences that have a source.

WireGuard uses one fixed handshake. The protocol page names it as the Noise_IK handshake from Noise, and its construction string is Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s, with all packets sent over UDP. There is no cipher menu to misconfigure. OpenVPN's 2.6 manual describes a daemon you configure with many options, including tcp-client mode and the OpenSSL crypto library.

On code size, WireGuard's site claims it is meant to be implemented in very few lines of code and easily audited, compared with OpenVPN/OpenSSL and IPsec. It also says it intends to be considerably more performant than OpenVPN. Those are the project's stated aims on its own site.

Inside a router the question is narrower than "which is faster". It is "how much does the little CPU do per packet, and who maintains the pieces?". We have not measured either protocol on OpenWrt hardware, and we have no figure to offer. If a guide quotes one without naming the router, the firmware and the date, ignore it.

OpenVPN keeps one real advantage here: it runs over TCP when you need that, and WireGuard does not. Choose it for that reason, not out of habit.

How do you send only some devices through the VPN?

With a manual interface, you add policy-based routing; with ForestVPN's client, you pick devices in a menu. The first is flexible and the second is simple.

The package people usually reach for is pbr, which routes by source address, destination or domain into the interface you name. You write one policy per rule set, and you keep the interface, the zone and the policies consistent yourself.

ForestVPN's client chooses by device, never by website or app, and remembers each device by hardware address. Three modes sit in Services > ForestVPN > Devices:

• Every device: the whole home is protected.
• Only the devices I choose: tick the devices that should use the tunnel; the rest stay on Direct.
• Every device except the ones I choose: everything is protected, a new device included, so this is the mode that does not leak when a phone rotates its private Wi-Fi address.

A device set to Direct is never blocked by the kill switch. If you want site-based rules, the client can step back and let passwall2, podkop or pbr route into fvpn0; the help page for running beside them lists what was tried and what was not, and the one on device modes covers the three modes.

Does a kill switch work on OpenWrt?

It does when something builds one, and a plain WireGuard interface does not. The leak case is the interface going down or failing to come up, for example at boot before the endpoint name resolves: its route disappears, and the lan-to-wan forwarding rule carries traffic out in the clear. When the peer merely goes silent, wg0 stays up with its route, so traffic is dropped rather than leaked.

By hand, the usual shape is to forbid forwarding from lan to wan, so the only way out is the VPN zone. That works until someone edits or re-adds the lan-to-wan forwarding, or adds a second exit and forgets this one.

ForestVPN's client splits the job in two halves that fail independently. A routing half sends protected devices into a table whose only exits are the tunnel or nowhere. A firewall half is written as ordinary OpenWrt firewall configuration, so a reload rebuilds it, and neither depends on the client program staying alive. The kill switch page has the levels and the limits, and the caveat is real: the router's own traffic and any device on Direct are outside it, and under the Standard level there are listed cases where protected devices go direct.

DNS and IPv6 deserve their own check, because guides stop at "ping works". On the client, lookups from protected devices go to the tunnel's resolver over IPv4, and DNS over TLS from them is refused. With the nftables firewall, IPv6 from protected devices goes into the tunnel when it has an address and is refused when it has none. On the older fw3 firewall the whole LAN's forwarded IPv6 is refused while protection is on. A browser using its own secure DNS escapes the router's view whichever route you pick.

What does a managed client do that a manual interface does not?

It handles the parts of the job that are the same on every router, so you do not rebuild them. Registration, key handling, the firewall zone, the kill switch, device modes, DNS routing and updates come in one package, forestvpn, installed from ForestVPN's own signed software source.

What you pay for that is control and one trust decision. The trust page is blunt: ForestVPN's update button checks two signatures, but if you upgrade through the package manager yourself, you trust the repository key alone. A server at home cannot be reached through the tunnel, so you mark it Direct; the same goes for a game console, which otherwise sees a strict NAT type. A router with no account is on the Free plan, and a household can use that up in a day, as the limits list puts it.

Its tunnel runs on an unmodified Noise_IKpsk2 handshake, the same one WireGuard uses, with a core derived from boringtun, the Cloudflare project; the WireGuard comparison page sets the two side by side. Interoperability with a WireGuard server you run yourself is a different question, and this article does not claim it.

How does the ForestVPN client install on OpenWrt?

By package manager, with a checksum printed beside every file. On OpenWrt 24.10 and older, which use opkg, you upload the install file (.ipk) in System > Software and compare the SHA256 your router shows with the one printed beside the file on the OpenWrt download page, which you reach from the download hub. On 25.12 and newer, which use apk, one command fetches a script whose SHA-256 is printed beside it, so you can download it, check it and read it before it runs. The setup file is not available.

The floor is OpenWrt 21.02, on ARM or x86-64, with some MIPS chips built, and the OpenWrt download page marks each build as tried on real hardware, built and tried in a lab, built only, or not yet tried. Read that mark before you trust a router with it.

One caveat travels with every instruction: the router pages say the client is not yet verified on hardware as a whole. Per the install page, the install file ran on one real router and the one command ran in a lab only, and nobody has followed the steps on a router of every kind listed. The router help pages each carry a version of that caveat, and so do we.

How do the three sit beside pbr, mwan3, passwall2 and podkop?

Each routing tool wants the same things you do: a routing table, a rule priority and a packet mark. Two programs using the same number send packets by each other's rules, and that is how a router gets quietly wrong.

A manual interface leaves the numbers to you. ForestVPN's router client uses routing table 241, rule priorities 1900 and 1901, and packet marks 0x10000000 and 0x20000000, outside the marks mwan3 (0x3f00) and pbr (0x00ff0000) use; the table and priorities can be moved, the marks are fixed. Passwall2 and podkop can use fvpn0 as an interface once you press Let another app route. The coexistence page marks which pairs were tried in a lab and which have not been tried end to end, podkop and pbr among the second kind.

Which route should you choose?

Choose by the job you want to own, not by the protocol.

• Choose manual WireGuard if you already run a WireGuard server or have a provider that publishes its keys, you like owning every rule, and you will test the failure case yourself.
• Choose OpenVPN if your provider hands you an OpenVPN profile, or you need TCP transport.
• Choose the ForestVPN router client if you want devices chosen from a menu, a kill switch and DNS handling written for you, and you are fine with a client you did not assemble.

If you are on MikroTik instead, the same client runs as a RouterOS container, and the MikroTik install recipe is the place to start.