VPN for Linux: WireGuard from the terminal or the network menu

Do you need a VPN app on Linux?

No. The WireGuard protocol has shipped in the mainline kernel since version 5.6, and the user-space tools sit in every major distribution's repositories. SuaVPN generates a standard .conf file, the same format the official apps use elsewhere, so wg-quick or NetworkManager is all you need on the client side.

Most VPN services treat Linux as an afterthought; WireGuard turns that around, because any distribution with a recent kernel already has the hard part. The panel also shows a QR code, but that is for phones: on Linux, the file is the way in.

What you get is what a VPN gives you anywhere else: the network you are on (a coworking space, a hotel, a campus) stops seeing which sites you visit, and those sites see the SuaVPN server's address instead of yours. What you do not get is anonymity: sign in to email or a social account and that service knows who you are, tunnel or not. Our guide on what a VPN is covers those limits.

Installing wireguard-tools

On kernel 5.6 or newer the module is already present. What you install is the user-space package, which provides two commands: wg, which shows and changes the state of an interface, and wg-quick, which reads a .conf file and sets up the interface, address, routes and DNS. Check your kernel with uname -r first.

The tools are in the official repositories everywhere, so there is no third-party PPA to add:

• Ubuntu and Debian: sudo apt install wireguard
• Fedora: sudo dnf install wireguard-tools
• Arch Linux and Manjaro: sudo pacman -S wireguard-tools
• openSUSE: sudo zypper install wireguard-tools
• Older kernels (some LTS servers and older Raspberry Pi images): install wireguard-dkms to build the module, or update the kernel. The install page at wireguard.com lists the cases.

Bringing the tunnel up with wg-quick and systemd

In the SuaVPN panel, under Devices, create a device named after the machine, pick a location from those listed on the status page, and save the .conf file. Copy it to /etc/wireguard/suavpn.conf and run sudo chmod 600 /etc/wireguard/suavpn.conf. The file holds the device's private key, so treat it like an SSH key: if it leaks, revoke the device in the panel and generate a new one.

Bring the tunnel up with sudo wg-quick up suavpn and take it down with sudo wg-quick down suavpn; the interface name is the file name without the extension. Run sudo wg to check: "latest handshake" confirms the tunnel is exchanging data with the server, and "transfer" shows bytes in and out. Then open any site that shows your public IP address: it should display the location you picked. If it still shows your own address, the tunnel is not carrying your traffic; check the DNS section below first.

The package installs a systemd template unit, so starting the tunnel at boot is one line: sudo systemctl enable --now wg-quick@suavpn. Reverse it with sudo systemctl disable --now wg-quick@suavpn and inspect it with systemctl status wg-quick@suavpn. On a laptop that changes networks all week, that is always-on protection.

NetworkManager on GNOME and KDE

If you prefer a switch in the network menu, NetworkManager supports WireGuard natively on current GNOME and KDE desktops. Import the file with nmcli connection import type wireguard file suavpn.conf. The connection appears next to your Wi-Fi networks and can be toggled from the menu; nmcli connection up suavpn and nmcli connection down suavpn do the same from a terminal.

Pick one method and stick with it. Running wg-quick and NetworkManager against the same configuration produces two interfaces fighting over the same routes, and the symptom (a tunnel that reports as up while nothing loads) is confusing to debug. If you imported into NetworkManager, do not also enable the systemd unit.

Why does DNS still leak on Linux?

Because wg-quick applies the configuration's DNS line by calling resolvconf, and if that helper is missing the tunnel comes up with the right routes while name lookups quietly stay where they were. Every domain you visit is still resolved by the local network. It is the most common Linux-specific gap.

The SuaVPN configuration includes that DNS line precisely so lookups travel inside the tunnel rather than going to whatever resolver the local network handed out.

On Debian and Ubuntu, install resolvconf or openresolv; on Arch, openresolv or systemd-resolvconf. On systems running systemd-resolved (Ubuntu desktop, Fedora and most current distributions), a resolvconf command that forwards to resolvectl may already be present, so wg-quick often works as is. To confirm, run resolvectl status with the tunnel active and look for a DNS server on the suavpn interface, or read /etc/resolv.conf. A DNS leak test site gives a second opinion: the resolver it reports should belong to the VPN server, not your ISP.

Servers, Raspberry Pi, routers and common problems

The same .conf works on a headless server, a VPS, a Raspberry Pi or an OpenWrt router. Put it on a small box at the edge of your home network and every device behind it is protected while using a single device slot. Each configuration corresponds to one device in the panel: Basic includes 3, Pro 5 and Family 10, so a laptop, a phone and a Pi fit inside the smallest plan.

By default the configuration routes everything (AllowedIPs = 0.0.0.0/0), and that is how we recommend running it. SuaVPN has no split tunneling feature. If part of your traffic must stay outside the tunnel, the WireGuard way is to edit AllowedIPs by hand and list only the networks you want inside it; that is a manual change the panel does not manage, so test it before relying on it.

Current prices are on the pricing page; you can pay by card through Stripe from anywhere, cancel at any time, and get a refund within 7 days under Brazilian consumer law, enough time to test it on your own distribution. If something does not work, run through the list below before contacting support, and include the output of sudo wg. The Windows and Mac guides cover the same setup on other machines.

• wg-quick complains about resolvconf: install openresolv or resolvconf, or confirm systemd-resolved is running.
• No handshake: check outbound UDP on your firewall (ufw, firewalld, nftables) and the server on the status page.
• Tunnel up but no internet: look for a second tunnel or a conflicting route with ip route; take any other VPN down first.
• "RTNETLINK answers: Operation not supported": the kernel module is not loaded. Install wireguard-dkms or update the kernel, then run modprobe wireguard.
• Permission warnings on the .conf: the file must be owned by root and readable by root only (chmod 600).