Self-hosted WireGuard vs a VPN service

Our first run handshook, answered three pings and still failed the fetch. The clean runs went from first key to a fetched page in one short stretch; the job around the tunnel takes the time.

We timed it: two Debian containers, a server and a client, plus a plain target to fetch from, from installing the tools to a fetch through the server's NAT (network address translation), with a clock on every step.

Is a self-hosted WireGuard server worth it, or should you use a VPN service?

For one person who wants one exit address and enjoys owning the settings, a self-hosted server is worth it. For everyone who wants apps on every device and a status they can read, a service saves more work than a server does. We did not compare cost.

The tunnel itself is not where the two differ.

WireGuard's protocol page names its construction, the key-exchange pattern WireGuard runs when two ends meet, as Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s, and ForestVPN's core uses the same unmodified Noise_IKpsk2 handshake (protocol page). What differs is who does the work around it.

Choose a self-hosted server if you:

• want to read every line of your own configuration;
• are happy to patch a machine and to be the only person who can fix it;
• need one fixed address that only you use.

A service fits better if you:

• want apps for phones, TVs and laptops instead of a config file per device;
• want to see whether data flows, in words, instead of reading wg show;
• would rather the keeping-up was somebody's job.

Other options, and where to read about them:

• OpenVPN, which you can also host yourself: OpenWrt WireGuard sets it beside WireGuard on a router.
• A mesh tool, if you only want your own devices to reach each other: our Tailscale comparison.
• WireGuard itself, head to head: the WireGuard comparison page.
• The protocol level: WireGuard vs OpenVPN.

This post is about the build-or-buy decision.

How long does it take to set up a WireGuard server?

In run 3 the elapsed time from the first key to a page fetched through the server's NAT was 5.401 seconds, including the gaps between commands and a 2.1-second three-packet ping; run 3's timed rows after the installs add up to 4.537 seconds. Installing the packages took over 200 seconds in total, but the installs ran amd64 under emulation on an arm64 host, which inflates them, and we did not time a native install.

Three terms before the table:

• AllowedIPs: the addresses a peer may send from, and the addresses wg-quick routes to that peer.
• wg-quick: the script that reads wg0.conf and brings the interface up.
• PersistentKeepalive: makes a client send a packet at a set interval so a NAT keeps the path open.

In all three runs the handshake was already in place on the polling loop's first check, before the loop had sent a ping; we did not capture which packet started it.

The web log on the target showed the request coming from the server's own address, not the client's tunnel address: that is what the MASQUERADE rule does.

What happens when ip_forward is 0 on a WireGuard server?

In the first run the fetch timed out with curl's exit code 28 after 5.171 seconds, while the handshake and the three pings had worked. The cause was ip_forward at 0, which tells the kernel not to pass packets between interfaces, so the NAT rule had nothing to forward.

Setting it from inside the container failed: sysctl -w answered "permission denied on key". The fix was to start the server container with the sysctl already set, which is why the table shows only a check.

On a normal Debian host it is one command and one line in a config file, but this is the shape of the failure to expect: a tunnel that handshakes, pings and still carries nothing.

What do you have to keep up on your own WireGuard server?

A self-hosted WireGuard server leaves you the operating system, a key and an address per device, keepalive, reboot persistence and backups. The tunnel needs no daemon of its own once it is up, but the machine around it does.

Three of the seven rows are plain gaps in what we tested, and a fourth, updates, was installed once but never upgraded. They are also the ones that bite at 3 a.m.

The NAT rule in the table was typed into a shell, which means it is gone when the host restarts unless you save it somewhere. We did not test that, and we will not pretend a lab minute proves a year.

WireGuard's install page lists Debian among the systems with a module and tools, and also lists apps for other platforms, so the client side is rarely the hard part. The server's long life is.

Does a self-hosted VPN give you more privacy than a VPN service?

It moves the trust to a different place rather than removing it. A server you rent has one exit address, one renter and one billing identity, and the renter is you.

That cuts both ways. Nobody else's traffic leaves from your address, which is the point for some people. Everything that leaves it is attributable to a single customer account at the host.

What that host records and allows is written on its own terms page, which you should read before you rent. We rented nothing in this run, so we make no claim about any host.

What does ForestVPN hold about you?

On ForestVPN's side the account is a 32-character number, optional on Free, with no email or password (account number), and the security page answers "Does ForestVPN know who I am?" with "No name, no email and no password." The payment step still leaves a purchase record with a store or processor; VPN without email lays out who holds what. Read the policy of whoever you pay.

What does a VPN service do for you that your own server does not?

It does the jobs around the tunnel: apps, exits you do not have to patch, and a status in words. A server hands you the tunnel and leaves the rest as a task list.

Look at the status row first. In our first run the pings came back and wg show counted bytes received, so data did flow both ways through the tunnel; what failed was forwarding past the server. ForestVPN's status page has a verdict for that state, ExitUnreachable: "The path to the exit works; the exit can't reach the internet." (see status). We did not test ForestVPN against this failure.

Can you use your home computer as the exit instead of renting a server?

Yes, and it keeps the self-hosted idea, your own exit address, without renting a server. In ForestVPN you turn on Use as an exit on the home computer, then pick it under My exits in Locations from your phone or laptop (home anywhere).

It has honest limits, and the page says so:

• The computer has to be on, or that exit is offline.
• Your home connection's upload speed is the ceiling for everything you move through it.
• Sharing works on every plan: up to 10 exits, each shared with up to 5 people, from a device that has been on your account for a week or more.
• An iPhone can use an exit and reach your other devices, but cannot be one yet.

Compared with a self-hosted server at home, the difference is setup: the home-anywhere page says there is no port forwarding and no router setup, and you write no NAT rule.

If your home line is behind a router that does NAT, a hand-built server needs its UDP port reachable from outside first, and that is a project of its own. Similar router-side work, for people who want a tunnel on the router itself, is covered in OpenWrt WireGuard.

When should you build your own WireGuard server instead of paying for a VPN?

Build the server if the build is the point: you will learn what NAT (masquerade) does and own every setting. Before you trust it, reboot the host once and check that wg0, the forwarding setting and the NAT rule all come back; our run did not, and that test shows the gap.

Use a service, or your own computer as an exit inside one, if the point is the result. The plans are below.