WireGuard VPN setup on elementary OS

WireGuard gives elementary OS a compact, fast VPN that can protect traffic on café Wi-Fi, home broadband and mobile hotspots. It creates an encrypted tunnel between your computer and a VPN server, then sends network requests through that server. It is a practical choice for remote work, everyday browsing and keeping applications away from untrusted local networks.

WireGuard is not a cloak of anonymity and does not make every online activity legal. Service providers can still identify account holders, websites can detect unusual traffic, and access rules may differ by country. This guide covers a standard full-tunnel IPv4 connection using NetworkManager, the connection manager behind the desktop’s network settings, with commands that work even when the graphical editor has no WireGuard option.

For Australian users, the setup is useful in a Melbourne café, a Brisbane shared workspace, a Sydney airport lounge or on a Perth phone hotspot. It works over NBN broadband, fixed wireless, 5G and ordinary Ethernet. Telstra, Optus and Aussie Broadband provide home connections that can carry the tunnel; your internet provider does not need to offer WireGuard itself.

The steps below assume you already have a legitimate WireGuard-enabled VPN service and its configuration details. This is separate from a free browser extension: extensions usually proxy browser traffic only, while a system tunnel can cover other applications. Ordinary personal VPN use is not prohibited in Australia, but the Telecommunications Act 1997 regulates carriers and service providers, and the Privacy Act 1988 applies to covered organisations. Provider terms and service-specific rules still matter, and neither law turns a VPN into an anonymity guarantee.

Understand what the tunnel changes

A full tunnel sends IPv4 traffic through WireGuard’s encrypted virtual interface. The endpoint can be a hostname or public IP address and UDP port. Your computer authenticates with a private key; the server verifies its matching public key. The exchange is designed to be small and quick, so it usually adds less overhead than older VPN protocols.

You can route only selected networks through the tunnel, but that is split tunnelling and needs deliberate allowed-IP rules. For a home desktop, a full tunnel is easier to reason about: applications do not need separate proxy settings, and ordinary web requests follow the VPN. A router-based setup can cover every device on the network, but it requires compatible router firmware, client keys and careful handling of DNS and firewall rules.

Encryption starts at your computer and ends at the VPN server. Your ISP can generally see that you are communicating with the provider, but not the contents of the encrypted tunnel. The VPN provider can observe traffic unless it has a credible technical and contractual policy limiting collection. That is why provider reputation matters more than a promise printed on a pricing page.

Collect the service profile and keys

Collect the exact values from the provider: the server endpoint and UDP port, the server’s peer public key, your client private key, any assigned tunnel IPv4 address, the provider’s DNS and recommended MTU. A supplied .conf file normally contains these under [Interface] and [Peer]. If the service gave you a registration page instead, it may need your device’s public key before it issues the rest.

Save any supplied private key as ~/.config/wireguard/client-private.key, then protect it with chmod 600. If the service asks you to generate a key instead, run:

umask 077
mkdir -p "$HOME/.config/wireguard"
wg genkey | tee "$HOME/.config/wireguard/client-private.key" \
  | wg pubkey > "$HOME/.config/wireguard/client-public.key"

Give the service the contents of client-public.key; never send it the private file.

Do not confuse the client public key with the server public key required as the peer. Use a separate client key for each computer or phone unless the service explicitly supports shared credentials. If a device is lost, remove or revoke its key in the provider’s dashboard instead of continuing to reuse it.

Install the required components

Recent elementary OS releases use a Linux kernel with WireGuard support, but the desktop packages and NetworkManager version can vary. Check the release in Settings before changing the network, then install the command-line tools and NetworkManager plugin. On a current release, the commands are:

sudo apt update
sudo apt install wireguard-tools network-manager-wireguard

If apt reports that network-manager-wireguard is unavailable, update elementary OS through AppCenter or apt and check that nmcli is present. Older installations may need a newer NetworkManager and kernel rather than a collection of unrelated tools. NetworkManager, not wg-quick, will own the connection in this method.

Check nmcli general permissions to confirm that your account can manage networks. Do not replace NetworkManager with an unrelated daemon, because that can break the desktop’s network controls and VPN integration. Avoid running wg-quick up on the same profile at the same time: it can create a second route table and compete with NetworkManager for DNS and default routes.

Build the NetworkManager connection

Open Terminal and replace the example values with the ones issued for this connection. The tunnel address below is only an example; a mismatched address will not work.

PEER_PUBLIC_KEY="replace-with-server-public-key"
ENDPOINT="vpn.example.com:51820"
TUNNEL_ADDRESS="10.8.0.2/32"

sudo nmcli connection add type wireguard \
  ifname wg0 con-name wg0 \
  ipv4.method manual ipv4.addresses "$TUNNEL_ADDRESS" \
  ipv6.method disabled

Now attach the private key and describe the server peer. NetworkManager creates the routes associated with the allowed IP range, so 0.0.0.0/0 makes this a full IPv4 tunnel:

nmcli connection modify wg0 \
  wireguard.private-key "$HOME/.config/wireguard/client-private.key"

nmcli connection modify wg0 \
  wireguard.peer "$PEER_PUBLIC_KEY" \
  endpoint "$ENDPOINT" \
  allowed-ips 0.0.0.0/0 \
  persistent-keepalive 25

Set DNS explicitly if the provider supplies it. This public resolver is a fallback, not a claim that DNS queries are encrypted:

nmcli connection modify wg0 ipv4.dns "1.1.1.1" ipv4.ignore-auto-dns yes

Replace 1.1.1.1 with the provider’s DNS addresses if required, then inspect the finished profile with nmcli connection show wg0. Check that the endpoint, peer key and tunnel address match your provider’s documentation.

Connect and verify the tunnel

Bring up the connection and inspect its state:

nmcli connection up wg0
nmcli connection show --active
sudo wg show wg0

A healthy connection shows a recent handshake, a peer and transfer counters. If there is no handshake, check the endpoint spelling, UDP port, public key and whether the endpoint hostname resolves. Never paste a private key into a forum post; a public key and redacted error messages are enough for diagnosis.

Confirm the exit address in your provider’s account or IP-check page, then test DNS with resolvectl query example.com. Use ip route to inspect routes, remembering that NetworkManager may use policy routing rather than a simple default line. Turn the tunnel off with nmcli connection down wg0 when you want the normal network back. Reconnect applications opened before the tunnel if you need to be certain their new connections use the VPN.

Control DNS, IPv6 and MTU

DNS and routing need separate attention. A tunnel can carry your IP traffic while queries still go to a local resolver if DNS settings are wrong. To use a specific resolver:

nmcli connection modify wg0 ipv4.dns "1.1.1.1" ipv4.ignore-auto-dns yes
nmcli connection up wg0

Run resolvectl query example.com after reconnecting and check that the resolver shown is associated with the tunnel. Repeat the check on different Australian networks, such as home broadband and a mobile hotspot, because resolver selection can change with the underlying connection.

This recipe deliberately uses IPv4 only. If the physical connection has a working IPv6 default route, some traffic may bypass the tunnel. For genuine IPv6 coverage, obtain the provider’s IPv6 tunnel address and add ::/0 to the peer’s allowed IPs. If the service has no IPv6 support, disable IPv6 on the physical connection in NetworkManager instead of assuming it is protected. ip -6 route reveals whether an IPv6 default route remains.

MTU mismatches often appear as pages that load partly, stalled uploads or SSH sessions that freeze. WireGuard normally starts around 1420 bytes for IPv4 over Ethernet, but a mobile or fixed-wireless path may need less. Use the provider’s value; as a diagnostic, try 1380:

nmcli connection modify wg0 wireguard.mtu 1380
nmcli connection up wg0

Persistent keepalive of 25 seconds helps with NAT mappings that expire on some NBN, fixed-wireless and 5G connections. It does not repair an unavailable server or replace a provider with unreliable infrastructure.

Keep the setup secure and dependable

Keep the profile and key files on encrypted storage, give each device its own credentials and revoke access promptly if one is lost. Update elementary OS and the WireGuard packages regularly, then restart when a kernel update asks for it. A VPN client is only as current as the software and keys protecting it.

Australian privacy law does not make any provider trustworthy by default. The Privacy Act 1988 and Australian Privacy Principles apply to organisations that meet their thresholds, while the Telecommunications Act 1997 regulates telecommunications carriers and providers. Overseas providers may operate under different rules, so check what each service records, where it operates and whether independent audits support its claims.

University, workplace and airport networks may require portal sign-in or restrict UDP, which can prevent WireGuard from connecting. Open the ordinary web page and complete any legitimate access process first; do not bypass employer policy. This NetworkManager method also does not promise a kill switch, so a dropped tunnel can briefly return traffic to the normal connection.

What should remain in your mind is the final check: a valid peer key, a protected private key, a recent handshake, the expected public IP, and IPv4 routes and DNS that genuinely use the tunnel.