VPN on Arch Linux: WireGuard and NetworkManager

Arch Linux does not choose a network stack for you, and that is both its charm and its trap. A fresh install has a kernel, a shell and almost nothing else, so every part of your VPN setup is a decision you made yourself: which network manager, which DNS resolver, which firewall tool. When people say a VPN "does not work on Arch", the real situation is usually that two of those choices disagree.

This guide covers vpn for arch linux with WireGuard and NetworkManager, the combination most desktop users end up with. It starts with the choices that matter, installs with pacman, imports a configuration, deals with DNS, and finishes with the habits that keep a rolling-release machine from breaking after an update. The examples assume you have a WireGuard configuration from a server you control, an employer or a lab. If you use the VPNclient desktop app with an XPASS pass, the Linux setup guide covers that separate route.

Why Arch is different for VPNs

Three facts shape everything else.

• There are no defaults to lean on. Other distributions arrive with NetworkManager and a resolver wired together. On Arch you might run NetworkManager, systemd-networkd with iwd, netctl, or plain ip commands. A VPN guide that does not say which one it assumes is guessing.
• WireGuard lives in the kernel. The standard linux and linux-lts kernels include it, so there is no module to compile. The userspace package only adds the wg and wg-quick commands.
• The system is rolling. Kernel, NetworkManager and systemd all move forward every time you run pacman -Syu. A tunnel that worked last Tuesday can meet a new kernel on Friday. That is not a bug, but it means you need a short routine for checking afterwards.

The practical effect: spend five minutes confirming your stack before you copy a single configuration line.

Pick and confirm your network stack

Run these read-only checks.

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
systemctl is-active systemd-resolved
ls -l /etc/resolv.conf

Use the answers like this.

What you see	What it means	Recommended path
NetworkManager active	Desktop setup with menus and nmcli	Import the WireGuard file into NetworkManager
systemd-networkd active, NetworkManager not	Minimal or server style	Use a .netdev and .network pair, or wg-quick
Both active	They fight over interfaces	Pick one; disable the other
resolv.conf is a link to the stub file	systemd-resolved owns DNS	Put DNS in the profile; NetworkManager hands it over
resolv.conf is a plain file	Something else writes it	Install and enable one resolver on purpose

If two managers are active, fix that before touching the VPN. Two programs trying to bring up the same Wi-Fi card produce random disconnects that look like VPN problems.

Install the packages with pacman

On a desktop with NetworkManager, the packages are small.

sudo pacman -S wireguard-tools networkmanager
sudo systemctl enable --now NetworkManager

If you want a graphical applet, network-manager-applet provides the tray icon on many window managers, and desktop environments such as GNOME and KDE bring their own front-ends. For OpenVPN profiles, networkmanager-openvpn is the plugin; WireGuard itself needs no plugin because NetworkManager handles it directly.

Check that the kernel can do WireGuard:

sudo modprobe wireguard
lsmod | grep wireguard

If that fails on a custom kernel, install the DKMS package and the headers for your kernel. On the stock kernels it succeeds immediately. Remember that a kernel update replaces the running kernel's modules on disk; until you reboot, modprobe for a module you have not loaded yet may fail with an error about missing files. Rebooting after a kernel update solves this.

Create or obtain the configuration

A client file looks like this. Every value in capitals is a placeholder you replace with your own.

[Interface]
PrivateKey = YOUR_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Treat the private key like a password. Save the file as wg0.conf, restrict it with chmod 600 wg0.conf, and never paste it into a chat or a public repository. If you generate keys yourself, wg genkey | tee private.key | wg pubkey > public.key creates a pair. The server administrator needs only the public key.

Two lines deserve attention. AllowedIPs = 0.0.0.0/0, ::/0 sends all IPv4 and IPv6 traffic through the tunnel. A narrower list, such as one subnet, sends only that traffic and leaves the rest alone. PersistentKeepalive = 25 keeps a path open through a home router, which matters on laptops that sit behind network address translation.

Import it into NetworkManager

NetworkManager reads a standard WireGuard file directly.

sudo nmcli connection import type wireguard file ~/wg0.conf
nmcli connection show
nmcli connection up wg0

The profile is stored under /etc/NetworkManager/system-connections, and from then on you toggle it from the tray menu or with nmcli connection up and down. To start it automatically, nmcli connection modify wg0 connection.autoconnect yes is enough. NetworkManager also reapplies the tunnel when you move from one Wi-Fi network to another, which wg-quick does not do on its own.

If you would rather build the profile field by field, nm-connection-editor has a WireGuard tab. For the broader picture of how profiles, plugins and routes fit together, read adding a VPN in Linux NetworkManager.

The wg-quick alternative

wg-quick reads the same file and brings up the interface with routes and DNS in one command.

sudo cp ~/wg0.conf /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

Choose between the two routes honestly.

Question	NetworkManager	wg-quick with systemd
Laptop that moves between networks	Better: reacts to changes	Needs extra scripting
Always-on server or desktop at home	Works	Simple and predictable
Tray toggle for non-technical users	Yes	No
Hooks such as PostUp rules	Limited	Full support
Risk of conflicts	Low	High if you also import the file into NetworkManager

Never enable wg-quick@wg0 and import the same interface into NetworkManager. Both would try to create wg0, and you will see an error such as "device already exists". Pick one owner for each interface. If you want a firewall rule that blocks traffic outside the tunnel, the hooks in wg-quick are the usual place; see configuring a Linux VPN kill switch for a careful treatment.

DNS on Arch: make it explicit

Because Arch ships no resolver by default, a DNS = line in the file does nothing unless something reads it. The cleanest setup is systemd-resolved with the stub link.

sudo systemctl enable --now systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl status

With NetworkManager and systemd-resolved together, the DNS servers from the profile are registered on the tunnel link, and resolvectl status wg0 should list them. If you prefer openresolv, wg-quick uses it automatically, but then do not enable systemd-resolved at the same time. After connecting, test with resolvectl query example.org and look at which link answered. A refresher on why this matters is in what a DNS leak is, and the IPv6 side is in IPv6 leaks.

Routing, MTU and the handshake

Most remaining problems fall into three groups.

1. No handshake. Run sudo wg show. If "latest handshake" is missing after thirty seconds, the packets are not reaching the server or the keys do not match. Check the endpoint address, the public key and the server's firewall. The VPN handshake article explains what the numbers mean.
2. Handshake but no traffic. Check ip route and ip rule. With AllowedIPs of 0.0.0.0/0, NetworkManager and wg-quick both add policy routing so that the tunnel's own packets do not loop. If you added custom routes, remove them and retest.
3. Large pages stall while small ones load. This points to MTU. WireGuard's usual value of 1420 suits most links, but a connection with extra encapsulation may need less, such as 1380. Add MTU = 1380 to the interface section and retest. The reason is described in RFC 1191 on path MTU discovery.

A routine for rolling updates

Add this to your habit after every large pacman -Syu.

1. If the kernel or systemd changed, reboot before connecting.
2. Run sudo find /etc -name "*.pacnew" and merge changes for NetworkManager and resolver files.
3. Run nmcli connection show to confirm the profile exists, then bring it up.
4. Check sudo wg show for a recent handshake and resolvectl status for DNS.
5. Open a leak test only after those pass.

A worked example makes the routine concrete. Lena runs Arch on a laptop and updates every Sunday. One week the update replaces the kernel and a newer NetworkManager. On Monday she opens the lid at a cafe, joins the Wi-Fi, and the tunnel shows as connected but no page loads. Instead of reinstalling anything, she follows the routine: she notices the machine was never rebooted since the update, restarts it, and the tunnel works. Later she finds a NetworkManager.conf.pacnew file, merges one line about DNS handling, and the quiet DNS problem she had been ignoring disappears too. Ten minutes of checks replaced an evening of guessing.

If an update breaks something, journalctl -b -u NetworkManager is the first log to read. Downgrading a package is possible from the pacman cache, but reading the log usually gives a faster fix.

Backing up before you experiment

Because Arch encourages tinkering, keep a copy of your working setup. Copy /etc/NetworkManager/system-connections and /etc/wireguard to a safe, encrypted place, and note the package versions with pacman -Q wireguard-tools networkmanager. If a later experiment goes wrong, you can restore the files and be back in a few minutes. Never store these copies in a public repository, because they contain keys.

Common mistakes

• Running NetworkManager and systemd-networkd on the same interface.
• Copying a config that has a DNS = line while no resolver is installed.
• Leaving the private key file readable by every user.
• Enabling wg-quick at boot and also importing the file into NetworkManager.
• Forgetting to reboot after a kernel update and then blaming WireGuard.
• Assuming a tunnel is protecting IPv6 when AllowedIPs lists only IPv4.

Summary

On Arch, a VPN is only as reliable as the choices underneath it. Confirm that one network manager and one DNS resolver are in charge, install wireguard-tools and NetworkManager with pacman, import the file, and check the handshake and DNS before trusting the tunnel. Keep a short post-update routine and you can enjoy a rolling release without surprises.

If you would rather use a ready-made app with a prepaid pass, the download page and the pricing page show what is available.