Guide
How to set up a VPN on Linux
The provider’s client from its own repository, the alternative of a configuration file in the system’s own tools, the DNS detail that leaks on Linux more than anywhere else, and the checks from a terminal. Written against Ubuntu 26.04 LTS and NetworkManager.
Before you start
This guide does not pick one for you
Every step below is the same whichever provider you use, which is why none is named here. Choosing is a separate job and it is done on the register, where the choice is made against a published score rather than against a download page.
Install the client from the provider’s own repository, with the signing key from the provider’s own instructions. Never paste a one-line install command from a forum or a blog into a terminal: the command runs as root, and you have no idea what it fetched. A package from a signed repository can be checked; a script piped into a shell cannot.
Install the client
Two routes exist on Linux and both are honest. The provider’s own client is the first; it brings a kill switch, a server picker and the DNS handling for free. A configuration file in the system’s own tools is the second, and the section at the end of this guide says what it costs.
- Sign in on the provider’s website and open its Linux instructions from the account area. They name the repository, the key and the package; follow those and nothing else.
- Add the repository and its key, then install the package with the distribution’s package manager. The key is what lets the package manager refuse a tampered package, so a repository added without it is a repository you have taken on trust.
- Enable the client’s service so it starts at boot. A client is usually a root daemon and a desktop app that talks to it; the daemon owns the tunnel, and a kill switch that should hold from boot needs it running from boot.
- Sign in to the client — from the app, or from the command line with the token the account area gives you — and name the device something that does not identify you.
- Do not connect yet. Open the settings first. Two of the three below are off by default in most clients.
The three settings worth checking
Client menus differ, the settings do not. Every one of the three has an entry in the glossary if the name is unfamiliar.
The kill switch
Blocks all traffic if the tunnel drops, instead of quietly letting the connection fall back to the ordinary network. On Linux it is a set of firewall rules the client writes: everything except the tunnel interface and the tunnel’s own endpoint is dropped. Turn it on, and take the always-on or lockdown form where the client offers it, so the rules hold from boot and not only while connected. What the switch is for is on its own page.
DNS inside the tunnel
Name lookups can leave the machine outside the tunnel even when everything else is inside it, and on Linux this is the leak that happens most, because the resolver is a moving part. On Ubuntu that part is systemd-resolved: each interface has its own resolvers, and the one with the default route for DNS answers everything not matched by a more specific domain. The client should point that default at the provider’s resolver through the tunnel interface. Set the client’s DNS to the provider’s own, not a third party’s; the second party who sees only the lookups is one more party. How a leak happens is on the DNS leaks page.
The protocol
Leave it on the modern default unless something is broken — the protocol page lists which are current and which are legacy. If the client offers an older option to fix a connection problem, that is a trade to make knowingly and then undo: the register marks the weakest protocol a provider still offers, and selecting it by hand is choosing that mark for yourself.
Confirm it is actually working
Connect, then check rather than assume. Three checks from a terminal, in this order:
- Your address changed.
curlany “what is my IP” service, or open one in the browser, and confirm the country matches the exit you chose.ip route getto a public address should name the tunnel interface, not the Wi-Fi or Ethernet one. - Lookups are inside the tunnel.
resolvectl status: the tunnel interface should carry the provider’s resolver and the DNS default route; the physical interface’s resolver should be unused. A DNS leak test in the browser is the second opinion, and anything belonging to your internet provider means the DNS setting did not take. - The kill switch does what it says. With a download running, stop the client’s service with
systemctl stop, or bring the tunnel interface down withip link set … down, so the tunnel drops without the client being asked. The transfer should stop dead. If it carries on, the switch is decorative.
The longer battery of tests, and what each one can and cannot show, is its own guide.
What those checks prove
+Your traffic is leaving through the exit server, in the country you selected
+The resolver answering your lookups is the provider’s, inside the tunnel
+A dropped tunnel fails closed rather than quietly falling back
What they do not
−They say nothing about what the provider keeps — that is a documents question, answered on the retention pages
−They do not make you anonymous: your browser and your logins are unchanged, see what a VPN does not protect you from
−A passing test today is not a promise about the next package update or the next kernel
The configuration-file route, and what it costs
Most providers publish configuration files for the two common protocols from the account area. A WireGuard file imports into NetworkManager from the connection editor or with nmcli connection import, and runs equally well under wg-quick; an OpenVPN file imports the same way with the OpenVPN plugin. You get the tunnel, the system’s own interface toggle, and nothing the provider did not put in the file.
What you lose is the rest of the client. There is no kill switch unless you write the firewall rules yourself; a file imported into NetworkManager that drops simply hands traffic back to the ordinary network. There is no DNS handling. Only the DNS line in the file applies, and a file without one is the leak in the first troubleshooting answer. There is no server picker: each file is one exit, and changing exit means another file. Generate the files from the account area and keep them private: a WireGuard file contains the private key that is your identity to the provider.
The route is right for a server, a headless machine or a distribution the client does not support. On a laptop, prefer the client; the switch it brings is the thing a configuration file cannot.
When it does not work
The tunnel is up but DNS still goes to my internet provider
The classic Linux leak. A configuration file that sets no DNS leaves systemd-resolved using the resolver the network handed out, outside the tunnel. Run resolvectl status: the tunnel interface should list the provider's resolver and carry the default route for DNS, marked with a plus sign.
Add a DNS line to the configuration, or set the DNS on the connection in NetworkManager, and reconnect. The provider's own client sets this itself, which is one of the reasons to prefer it.
Everything stops working when the tunnel drops, and that is annoying
That is the kill switch doing its job: a dropped tunnel is a dead connection rather than a silent fallback to the bare network. Reconnect rather than turning the switch off.
If it drops often on one network and rarely elsewhere, switch the protocol once and try a nearer exit. If no protocol holds on that network, the network is blocking VPN traffic, and this guide stops there.
The client asks for sudo or a password every time
Creating a network interface is a privileged operation, and a client that does not install a background service has to ask each time. Most do install one — a daemon that runs as root and a desktop app that talks to it — and the repeated prompt means the service is not running or not enabled.
Check it with systemctl status and the service name from the provider's instructions, and enable it so it starts at boot.
Same steps, other machines
The rest of the platforms
Every platform has a guide of its own rather than a tab on this one. The steps diverge as soon as the installer opens, and a page that answers three platforms at once answers none of them properly.