How to Connect to a VPN from the Linux CLI

A VPN on Linux does not need a window. Many people spend all day in a terminal, run machines through SSH, or manage servers that have no desktop at all, and for them a tunnel that starts with one command is both simpler and easier to automate. The price of that simplicity is that the command line will let you do things a graphical tool would not, such as cutting off the very SSH session you are typing in.

This guide is for linux vpn command line use. It does not teach what a VPN is, and it does not repeat the desktop installer steps in the Linux setup guide. It assumes you already have a configuration file, from an employer, a university lab or a server you run, and want to bring it up, keep it up, check it and shut it down cleanly from a shell.

When the command line is the right tool

Choose the CLI when one of these is true.

• The machine has no desktop. A VPS, a Raspberry Pi in a cupboard or a headless home server.
• You connect through SSH. You want a tunnel for one job and a clean exit afterwards.
• You want it scripted. A backup that runs through the tunnel only when the tunnel exists, or a cron task that checks it.
• You need to see everything. Terminal output shows each step, which is better than a menu that says "failed".

Choose a graphical tool when you are on a laptop that changes Wi-Fi networks all day. NetworkManager reacts to those changes; a plain command does not. The article on adding a VPN in Linux NetworkManager covers that side.

Preflight: five checks before you connect

Spending thirty seconds here prevents most trouble.

1. Who owns the file? Run ls -l wg0.conf or the .ovpn file. It should belong to you or root and not be readable by others, because it can contain a private key. chmod 600 file fixes that.
2. Is a tunnel already up? ip link show type wireguard and ip addr | grep tun reveal leftovers. Two tunnels with the same name conflict.
3. What is the current route? Save the output of ip route and ip -6 route. You will compare it afterwards and use it to recover if something goes wrong.
4. What does DNS look like? resolvectl status shows the servers before the tunnel changes anything.
5. Do you have a second way in? If you are on SSH, make sure you can reach the machine another way, such as a console or an out-of-band session, before you start a full tunnel.

Keep a note of your public address from an IP-check page before connecting. You need the "before" value to see a difference.

Three ways to connect from a terminal

Tool	Command	Best for	Watch out for
wg-quick	sudo wg-quick up wg0	A WireGuard config; one command sets address, routes and DNS	Needs a resolver hook for the DNS line to apply
openvpn	sudo openvpn --config work.ovpn	An .ovpn file; runs in the foreground and prints progress	Occupies the terminal unless run as a service or daemon
nmcli	nmcli connection up work	A profile already stored in NetworkManager	The profile must exist first

The tools do not mix. Do not start wg-quick up wg0 while NetworkManager already manages an interface called wg0. Choose one owner. To understand the trade-offs between the two protocols behind these tools, read WireGuard vs OpenVPN and OpenVPN explained.

Running the tunnel step by step

WireGuard with wg-quick. Put the file at /etc/wireguard/wg0.conf, then:

sudo wg-quick up wg0
sudo wg show
sudo wg-quick down wg0

The wg show output lists the peer, the endpoint and a "latest handshake" time. If the handshake line is missing after half a minute, the server is not answering. The interface name comes from the file name, so office.conf gives office.

OpenVPN in the foreground. Run the client and read the output.

sudo openvpn --config ~/work.ovpn

Success ends with a line saying the initialization sequence completed. Press Ctrl+C to stop it. For credentials stored in a file, add --auth-user-pass /path/to/auth.txt and keep that file readable only by root. To run in the background, add --daemon and --log /var/log/openvpn-work.log, then read the log.

NetworkManager from the shell. If a profile exists, nmcli connection up work and nmcli connection down work are all you need, and nmcli -p connection show work prints the whole profile.

A tip for experiments: open a second terminal and run watch -n 2 'ip route; echo; resolvectl status | head -20'. You see the routes and DNS change the moment the tunnel comes up.

The SSH trap: do not saw off the branch you are sitting on

This is the single most common CLI mistake. If you connect to a server over SSH and start a full tunnel, the default route changes. The server may now send replies to your SSH client through the tunnel, while your client expects them from the original path. The session freezes, and often you cannot get back in.

Ways to avoid it:

1. Exempt your own address. Before connecting, add a route for your SSH client's address through the original gateway: sudo ip route add 203.0.113.10 via 192.0.2.1 dev eth0. Replace the values with your own, taken from the saved ip route output.
2. Use a narrow tunnel. Set AllowedIPs to just the subnets you need rather than 0.0.0.0/0, so the default route stays alone.
3. Test with a timer. Start the tunnel with a dead-man switch: sudo wg-quick up wg0; sleep 120; sudo wg-quick down wg0 run from a terminal multiplexer, so it comes down by itself if you lose the session.
4. Keep a console. Cloud and home servers should have a way in that does not depend on the network you are changing.

Address ranges 192.0.2.0/24 and 203.0.113.0/24 above are reserved for documentation, so they are safe examples; use your own.

Keeping it running after you log out

A tunnel started in a terminal dies with the terminal. Use one of these.

• systemd for WireGuard. sudo systemctl enable --now wg-quick@wg0 starts it now and at every boot. sudo systemctl status wg-quick@wg0 shows whether it is up. Disable it with sudo systemctl disable --now wg-quick@wg0.
• systemd for OpenVPN. Distributions provide a client unit that reads files from a client folder, often openvpn-client@NAME. Put the config there and enable the unit; the exact path depends on the distribution, so check its package notes.
• tmux or screen for quick tests. Run the foreground command in a session and detach. This is fine for an afternoon, not for something you depend on.

If the service must start after the network is ready, check that the unit waits for the network-online target. On a machine that boots faster than its Wi-Fi, a tunnel that starts too early simply fails and stays down.

Proving that it works

Do not trust silence. Run four checks.

ip route get 1.1.1.1
sudo wg show
resolvectl query example.org
curl -s https://example.org -o /dev/null -w "%{http_code}\n"

1. ip route get shows which interface carries traffic to an outside address. For a full tunnel it should name the VPN interface.
2. wg show should report a recent handshake and growing transfer counters.
3. resolvectl query shows which link answered the DNS lookup; the explanation of why that matters is in what DNS does on the Cloudflare learning site. If the answer comes from your Wi-Fi link, name lookups bypass the tunnel.
4. curl confirms that ordinary web traffic works.

Then compare your public address with the "before" value you saved. The full test method, including leaks and failure behaviour, is in how to test a VPN. If you are worried about traffic escaping when the tunnel drops, read about a Linux VPN kill switch.

A short scenario shows how the pieces fit. Arjun maintains a home server and wants a nightly backup to reach an office machine through a tunnel. He writes a small script that brings the tunnel up, waits until wg show reports a handshake, runs the copy, and then takes the tunnel down again whether the copy worked or not. Because the script saves and restores nothing about the default route, he uses a narrow AllowedIPs that covers only the office subnet, so the server's normal traffic never changes. The log records the handshake time and the exit status, so a failed night is easy to diagnose in the morning.

Disconnecting and cleaning up

Shutting down should return the machine to how it started.

1. Stop the tunnel: sudo wg-quick down wg0, Ctrl+C for a foreground OpenVPN, or sudo systemctl stop for a service.
2. Compare ip route with the copy you saved. Any route that remains from the tunnel can be removed with sudo ip route del.
3. Check resolvectl status. The tunnel's DNS entries should be gone from the main link.
4. Remove temporary routes you added for SSH.
5. Delete credentials you created for the test, such as an auth file in your home folder.

If a crash left an interface behind, sudo ip link delete wg0 removes it.

Troubleshooting by message

What you see	What it usually means	What to try
RTNETLINK answers: Operation not permitted	Not running as root	Add sudo
Cannot find device "wg0"	The interface is not up, or the name differs from the file	Check the file name; run ip link
Error: Unknown device type	Kernel or tools lack WireGuard	Install wireguard-tools; check the kernel
TLS Error: TLS key negotiation failed	Packets are not reaching the OpenVPN server	Check the server address, port and clock
Handshake missing	Wrong key, wrong endpoint or blocked port	Check public key and endpoint; try another network
Connected, but DNS fails	The DNS line was ignored	Check the resolver hook; use resolvectl status
Session froze after connecting	Default route moved	Reboot or console in; apply the SSH advice above

The wider checklist in VPN not connecting applies here as well.

Summary

Connecting from the Linux terminal comes down to a short routine: run preflight checks and save your routes, use one tool to bring the tunnel up, protect your SSH session before you change the default route, run the tunnel as a service if it must survive logout, prove it works with route, handshake, DNS and an IP check, and clean up afterwards. If you would rather use a ready-made desktop app, the download page and the pricing page show the options.