WireGuard VPN on a VPS for a Trip: Ubuntu 24.04 Setup and Teardown

To run a WireGuard VPN on a VPS for a trip, deploy a small Ubuntu 24.04 server, install the wireguard package, create a key pair for the server and for each device, turn on IP forwarding and NAT, open UDP port 51820, and scan a QR code with your phone. When you get home, remove the tunnel from your devices and delete the server, because deleting is what stops billing.

On hotel, airport or conference Wi-Fi, the local network then sees only encrypted packets going to one IP address, and websites see your server instead of the hotel. This guide uses commands from the Ubuntu Server, WireGuard and ufw documentation. It keeps the firewall closed to everything except the tunnel, shows how the config closes DNS and IPv6 leaks, and prices a 7-day trip on a Quartz Q1 billed by the hour: $1.68 for all 168 hours.

Key takeaways

• On Ubuntu 24.04 the server side takes seven steps: deploy and secure it, install wireguard, create keys, write wg0.conf, enable IPv4 forwarding, add NAT, a route rule and UDP 51820 in UFW, and start wg-quick@wg0.
• Put the NAT rule in /etc/ufw/before.rules and allow only tunnel-to-internet forwarding, so UFW's default forward policy can stay at deny.
• Give every client a DNS line and AllowedIPs = 0.0.0.0/0, ::/0; without them, DNS lookups and IPv6 traffic can bypass the tunnel.
• The phone's QR code contains its private key: treat it like a password, and delete client keys from the server once your devices connect.
• Rent the server by the day on hourly billing and delete it after the trip: deleting stops billing, a stopped server is still billed, and a long trip never costs more than the plan's monthly price in a billing period.

What does a WireGuard VPN on a VPS hide, and from whom?

A VPN moves the place where your traffic becomes visible: from the Wi-Fi you are sitting on to a server you rent. That trade is worth making on networks you do not trust, as long as you know exactly what changes.

Who is watching	Without the VPN	With your WireGuard VPN
The hotel, café or airport network	The names you look up and the addresses you connect to (page contents stay encrypted by HTTPS)	Encrypted UDP packets to one IP address: your server
Websites and apps	The network’s public IP address and its location	Your server’s IP address and its city
The DNS resolver	Usually the one the local network hands out	The resolver you put in the DNS line of your config
Your server’s network and its upstream providers	Nothing from you	Your server’s outgoing connections, the same view any internet provider has

Know the limits. A personal VPN does not hide who you are from the sites you sign in to, and the server’s IP address is used only by you and is tied to your hosting account. It protects you from the network you are on, not from the services you use. Some sites also treat data-center IP addresses with extra caution, so a bank may ask you to confirm a login.

Your own VPN or a VPN service: which fits your trip?

	Your own WireGuard VPS	A commercial VPN service
Who runs the server	You. You hold every key and decide what is logged	The VPN company; you rely on its policies
Exit IP address	One dedicated IPv4 address, used only by your devices	Usually shared with other customers
Locations	Wherever your host has data centers (for us: Istanbul today, with New York coming soon)	Typically many countries
Setup and upkeep	The seven steps below; you apply updates	Install an app and sign in
Billing	By the hour while the server exists, never more than the monthly price in a billing period; delete it after the trip	Usually a subscription
Better fit when	You travel now and then, want to hold the keys, and are comfortable with SSH	You want many countries, a one-tap app, or an IP address shared with other people

If the right-hand column describes you, a VPN service is the simpler choice. The rest of this guide is for the left-hand column. Not sure WireGuard is the right protocol? WireGuard vs OpenVPN compares speed, security and networks that block UDP. Rather not manage keys and ports yourself? A Tailscale exit node on a VPS does the same job, with Tailscale handling the keys and NAT traversal.

How much does a VPS VPN cost for a 7-day trip?

WireGuard is light. On Ubuntu 24.04 it runs inside the Linux kernel, and its ChaCha20-Poly1305 cipher is, in the words of the WireGuard project, “extremely fast in software on virtually all general purpose CPUs.” For one person’s phone and laptop, the smallest plan is a reasonable start: Quartz Q1 has 1 shared vCPU and 1 GB of RAM, which meets Ubuntu’s documented 1 GB minimum for 24.04 cloud images. That is sizing reasoning from the docs, not a benchmark. Quartz Q2 doubles the memory if you want headroom.

Renting a VPS by the day is hourly billing counted in days, with no daily cycle to prepay. Quartz Q1 costs $0.01/hour, so one day of 24 hours comes to $0.24/day and a 7-day trip of 168 hours to $1.68. However long the trip, you never pay more than the plan’s monthly price, $5.00, for the server in a billing period (one month from your order date).

Quartz Q1 for one afternoon, one day, a long weekend, one week, two weeks and a month, billed by the hour and capped at the monthly price

Duration	Hours on the meter	Cost $0.01/hour · cap $5.00/month	Note
4 hours	4	$0.04
1 day	24	$0.24
3 days	72	$0.72
7 days	168	$1.68
14 days	336	$3.36
30 days	720	$5.00	Capped at the monthly price

The same hourly billing covers a single afternoon, such as a conference: four hours on Quartz Q1 cost $0.04, deducted from the server’s balance hour by hour. For any other length, the VPS cost calculator does the math, and our guide to hourly billing explains each rule.

Which server location suits a trip VPN?

Pick the location closer to where you will be. Every request detours through the server on its way to the website and back, so a nearby server adds the least delay, and websites see the server’s city, not yours.

The exception: if what you need on the road is services from home, such as your bank’s site, a server near home can fit better. Our guide to choosing a VPS location shows the latency math for both cases.

Traffic matters too. A VPN relays everything you download, so each byte crosses the server’s network port twice: once from the website and once, encrypted, to you. Istanbul plans include the monthly traffic allowance listed for each plan, prorated for a server that exists for part of a billing period. If you plan long video calls, compare the allowance on the plan card below with the location details.

How to set up WireGuard on an Ubuntu 24.04 VPS

Run every command as your sudo user, in one SSH session, in order. The examples use the private range 10.13.13.0/24 inside the tunnel: the server is 10.13.13.1, your phone 10.13.13.2 and your laptop 10.13.13.3. Ubuntu’s gateway guide notes that the tunnel range must not clash with the network you are on, so if a hotel ever hands you a 10.13.13.x address, switch to another private range everywhere.

Step 1: Deploy and secure the server

Deploy Ubuntu 24.04 LTS in the location you chose and log in over SSH (see how to connect to a VPS). Before you open any port, work through our VPS security checklist: a sudo user with an SSH key, no root or password logins, and current updates. A VPN server carries all of your traffic, so it deserves the same care as any other server.

sudo apt update && sudo apt upgrade

Step 2: Install WireGuard and qrencode

WireGuard itself lives inside the Linux kernel, so on Ubuntu 24.04 the wireguard package (version 1.0.20210914 in the noble archive, October 2026) depends only on wireguard-tools, which provides wg and wg-quick. qrencode draws the QR code for your phone.

sudo apt install wireguard qrencode

Debian 12: the same packages exist, but Debian does not install UFW by default, so run sudo apt install wireguard qrencode ufw instead. Every later step is identical.

Step 3: Create one key pair per device

Every device gets its own key pair. Create them in a private folder; umask 077 makes each new file readable by you alone, exactly as the wg(8) manual shows.

mkdir -m 700 ~/wg-trip && cd ~/wg-trip
umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee phone.key | wg pubkey > phone.pub
wg genkey | tee laptop.key | wg pubkey > laptop.pub

Creating the phone’s key on the server is what makes the QR code possible. The trade-off is that the server briefly holds the phone’s private key, so you will delete those copies once your devices connect.

Next, save the server’s network interface and public IPv4 address in two shell variables, so the following steps paste without edits:

WAN_IF=$(ip -4 route show default | sed -E 's/.* dev ([^ ]+).*/\1/' | head -n 1)
SERVER_IP=$(ip -4 -o addr show dev "$WAN_IF" scope global | sed -E 's|.* inet ([0-9.]+)/.*|\1|' | head -n 1)
echo "$WAN_IF $SERVER_IP"

The output looks like eth0 203.0.113.10, and the address must match the IPv4 address in your portal. Shell variables do not survive a logout: if you reconnect, run cd ~/wg-trip, umask 077 and these lines again.

Step 4: Write the server config (wg0.conf)

This writes /etc/wireguard/wg0.conf with the server’s private key and one [Peer] section per device, filling in the keys from the files you just created:

sudo install -d -m 700 /etc/wireguard
sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
Address = 10.13.13.1/24
ListenPort = 51820
PrivateKey = $(cat server.key)

[Peer]
# phone
PublicKey = $(cat phone.pub)
AllowedIPs = 10.13.13.2/32

[Peer]
# laptop
PublicKey = $(cat laptop.pub)
AllowedIPs = 10.13.13.3/32
EOF
sudo chmod 600 /etc/wireguard/wg0.conf

On the server, AllowedIPs works as an access list: the WireGuard documentation calls this cryptokey routing. A packet from your phone is accepted only if it decrypts with the phone’s key and comes from 10.13.13.2. Port 51820 is the port used in the wg(8) manual’s examples.

Step 5: Turn on IP forwarding

The server must route packets from the tunnel to the internet. This is the setting and file name from Ubuntu’s gateway guide:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/70-wireguard-routing.conf
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf

Both commands print net.ipv4.ip_forward = 1. One detail that is easy to miss: UFW applies /etc/ufw/sysctl.conf when it starts, and the file’s own header says its settings override /etc/sysctl.conf and /etc/sysctl.d. Its forwarding lines ship commented out, so they leave your setting alone. The reboot test later proves it on your server.

Step 6: Open UDP 51820 and add NAT in UFW

Three things remain: accept WireGuard’s UDP packets, allow forwarding from the tunnel to the internet, and rewrite the tunnel’s private source addresses to the server’s IP (masquerading). Many guides put iptables commands in wg0.conf, and Ubuntu’s gateway guide keeps its rule in /etc/rc.local. On a server that already runs UFW, the ufw-framework(8) manual keeps everything in the firewall’s own files: a nat table at the end of /etc/ufw/before.rules plus one route rule. UFW’s default forward policy stays at deny.

[ -n "$WAN_IF" ] && sudo tee -a /etc/ufw/before.rules > /dev/null <<EOF

# NAT for the WireGuard tunnel
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.13.13.0/24 -o $WAN_IF -j MASQUERADE
COMMIT
EOF

The test at the start skips the write if $WAN_IF is empty. Run the block once, because a second run appends a second copy, and confirm with sudo tail -n 5 /etc/ufw/before.rules that the MASQUERADE line names your interface.

Then add the rules and load them. sudo ufw enable warns that it may disrupt SSH connections; OpenSSH is allowed first, so answer y.

sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw route allow in on wg0 out on "$WAN_IF" from 10.13.13.0/24
sudo ufw enable
sudo ufw reload

The route rule lets traffic in from the tunnel and out to the internet. Nothing is forwarded in the other direction except replies, which UFW’s default rules already accept as established connections, and phone-to-laptop traffic inside the tunnel stays blocked, apart from ping, which UFW’s default rules allow. Check the result with sudo ufw status verbose: the defaults line must say deny (routed), and the rule list must contain an ALLOW FWD line. If it says disabled (routed), forwarding from step 5 is off.

Step 7: Start WireGuard

sudo systemctl enable --now wg-quick@wg0
sudo wg show

The enable part brings the tunnel back after every reboot, as Ubuntu’s common tasks guide describes, and --now starts it immediately. wg show should list interface wg0, listening port: 51820 and your two peers, with no handshakes yet.

Connect your phone with a QR code (and your laptop with a file)

Each device needs a config with its own private key and tunnel address, a DNS server, and the server’s public key and address. This loop writes one config per device from the key files:

for entry in phone=10.13.13.2 laptop=10.13.13.3; do
name=${entry%%=*}
addr=${entry#*=}
cat > "$name.conf" <<EOF
[Interface]
PrivateKey = $(cat "$name.key")
Address = $addr/24
DNS = 9.9.9.9, 149.112.112.112

[Peer]
PublicKey = $(cat server.pub)
Endpoint = $SERVER_IP:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
EOF
done

Line	What it does	Documented in
Address	The device’s address inside the tunnel; it must match its AllowedIPs on the server	wg-quick(8)
DNS	The resolvers the device uses while connected; here Quad9’s two recommended IPv4 addresses	Quad9, Ubuntu
Endpoint	Your server’s public IP address and UDP port	wg(8)
AllowedIPs = 0.0.0.0/0, ::/0	Sends all IPv4 and all IPv6 traffic into the tunnel	wg(8)
PersistentKeepalive = 25	Sends an empty packet every 25 seconds so NAT on hotel and mobile routers keeps the path open	wg(8)

Phone: scan the QR code

Install the official WireGuard app (the WireGuard installation page links to the App Store and Google Play), then print the phone’s config as a QR code in your SSH window:

qrencode -t ansiutf8 < phone.conf

In the app, tap the + button, choose to scan a QR code, and point the camera at the terminal. If the code does not fit, enlarge the window or reduce the font size. Give the tunnel a name you will recognize, such as trip-vpn.

Laptop: copy the file over SSH

Install the WireGuard app for your laptop’s operating system from the same installation page, then copy the config over SSH. Run this on the laptop, with your own user name and server IP:

scp [email protected]:wg-trip/laptop.conf .

Import the file with the app’s import-from-file option, then delete the downloaded copy. On an Ubuntu laptop, Ubuntu’s documentation notes that the DNS line relies on resolvconf, which Ubuntu does not install by default. Replace that line with PostUp = resolvectl dns %i 9.9.9.9; resolvectl domain %i \~., copy the file to /etc/wireguard/wg0.conf and start it with sudo wg-quick up wg0.

Once both devices connect (test them in the next sections first), delete the client keys and configs from the server. The server only needs public keys, and its own private key already lives in wg0.conf:

rm ~/wg-trip/phone.key ~/wg-trip/phone.conf ~/wg-trip/laptop.key ~/wg-trip/laptop.conf ~/wg-trip/server.key

Add a device later (tablet, second phone or travel router)

A new device needs its own key pair, the next free address and a new [Peer] section. If you logged out, run cd ~/wg-trip, umask 077 and the two variable lines from step 3 first. This adds a tablet as 10.13.13.4:

wg genkey | tee tablet.key | wg pubkey > tablet.pub
sudo tee -a /etc/wireguard/wg0.conf > /dev/null <<EOF

[Peer]
# tablet
PublicKey = $(cat tablet.pub)
AllowedIPs = 10.13.13.4/32
EOF
sudo systemctl reload wg-quick@wg0

Ubuntu’s common tasks guide notes that reload adds or removes peers without dropping the tunnels already connected. Then run the client loop above with tablet=10.13.13.4 as its only entry, import the config, and delete tablet.key and tablet.conf. A travel router that supports WireGuard client mode (check its manual) is just another device: give it its own keys and address, never a copy of your phone’s config.

How do you prevent DNS and IPv6 leaks?

A leak is traffic that skips the tunnel or tells the local network what you are doing. Ubuntu’s gateway guide describes the common case: even with all traffic in the tunnel, a device can keep asking the DNS server the hotel network handed out, so the hotel still learns every site name. The DNS line in each client config fixes that, and the official apps apply it while the tunnel is up. You have three choices of resolver:

Resolver	Who sees your lookups	Extra setup
A public resolver such as Quad9 (used above)	The resolver’s operator. Queries travel inside the tunnel and leave from your server’s IP	None
Your host’s resolver (resolvectl status on the server shows it, per Ubuntu’s guide)	The hosting provider’s resolver	Put that IP address in the DNS line
Your own resolver on the VPS (Ubuntu’s guide uses bind9)	Only the name servers your resolver queries (root, top-level domain and each site’s own), which see your server’s IP	sudo apt install bind9, then sudo ufw allow in on wg0 to any port 53 and DNS = 10.13.13.1

If you run your own resolver, allow port 53 on wg0 only. An open DNS resolver on the public interface breaks our acceptable use policy, because attackers abuse open resolvers for amplification attacks.

Why ::/0 matters: the IPv6 leak

If the hotel network gives your phone an IPv6 address and your config routes only 0.0.0.0/0, IPv6 connections can go around the tunnel. The ::/0 in AllowedIPs sends IPv6 into the tunnel as well. This server does not forward IPv6, and cryptokey routing drops any packet whose source address is not in the peer’s AllowedIPs (10.13.13.2/32 for the phone), so IPv6 simply fails while you are connected and most apps fall back to IPv4 inside the tunnel. Routing IPv6 through the server is possible, but it needs IPv6 forwarding and NAT as well; for a one-week trip, IPv4 is enough.

• WireGuard’s app for Windows adds a kill switch automatically when a tunnel has one peer with a /0 route: it blocks traffic outside the tunnel and allows DNS only to the servers in your config (network configuration quirks).
• Android can keep the tunnel on with its Always-on VPN setting. Turn it on for the trip and off before you delete the server.
• Browsers with secure DNS (DNS over HTTPS) turned on can send lookups to the provider set in the browser instead of your DNS line. Those requests are encrypted and still travel through the tunnel, but a leak test will show that provider.

Test the VPN before you leave

Test from a network that is neither your home nor the server’s: turn off Wi-Fi on your phone so it uses mobile data, and switch the tunnel on. Then, on the server:

sudo wg show

1. The phone’s peer shows latest handshake a few seconds ago and a transfer line that grows as you browse.
2. A what-is-my-IP page on the phone shows your server’s IP address, the SERVER_IP from step 3.
3. The standard test on dnsleaktest.com, which Ubuntu’s guide suggests, lists only servers of the resolver you chose, never your mobile carrier’s.
4. An IPv6 test page such as test-ipv6.com finds no IPv6 address while the tunnel is on.
5. The same checks pass on the laptop.

Finally, prove that everything survives a restart. Reboot the server:

sudo reboot

Reconnect over SSH once the server is back and check forwarding, the tunnel and the firewall. Expect net.ipv4.ip_forward = 1, a listening wg0 and deny (routed); your phone reconnects on its own with its next packet.

sudo sysctl net.ipv4.ip_forward
sudo wg show
sudo ufw status verbose

Troubleshooting on hotel and airport Wi-Fi

Symptom	Likely cause	Check	Fix
No handshake at all	UDP 51820 blocked, wrong Endpoint IP, or a key in the wrong place	sudo ufw status lists 51820/udp; sudo wg show has no latest handshake	Open the port; compare each PublicKey with its .pub file (keys come first in Ubuntu’s checklist)
Handshake works, nothing loads	Forwarding off, NAT missing or on the wrong interface	sudo sysctl net.ipv4.ip_forward; sudo iptables -t nat -S POSTROUTING shows MASQUERADE on your interface	Repeat steps 5 and 6, then sudo ufw reload
IP addresses work, names do not	DNS line missing, or your own resolver is firewalled	The tunnel details in the app list DNS servers	Add the DNS line; for bind9, allow port 53 on wg0
Works on mobile data, not on hotel Wi-Fi	Captive portal not accepted yet, or the network blocks unusual UDP ports	Turn the VPN off and open any web page	Sign in to the portal first; if UDP 51820 stays blocked, move to UDP 443 (below)
Small pages load, large ones stall	MTU too large for the network path	Uploads and big downloads hang	Add MTU = 1280 to the client’s [Interface] section
Messages and calls arrive late while the phone is idle	The NAT mapping on the hotel or mobile router expired, so the server cannot reach the phone until it sends again	PersistentKeepalive missing from the client	Keep PersistentKeepalive = 25, the interval the wg(8) manual gives for peers behind NAT
Required key not available when you ping	The destination is not in AllowedIPs	Compare AllowedIPs on both sides	Fix AllowedIPs, as Ubuntu’s troubleshooting guide explains

WireGuard runs over UDP only. Its known limitations page says it “explicitly does not support tunneling over TCP” and leaves obfuscation to other tools. Some guest networks pass only common ports. UDP 443 is often open because browsers use it for HTTP/3, but not everywhere. To move the server to it:

sudo sed -i 's/^ListenPort = 51820/ListenPort = 443/' /etc/wireguard/wg0.conf
sudo ufw allow 443/udp
sudo ufw delete allow 51820/udp
sudo systemctl restart wg-quick@wg0

Then edit the tunnel in each app and change the port in Endpoint from 51820 to 443.

If pages stall instead, add the MTU line from the matrix. wg-quick(8) picks the MTU automatically when the line is absent; 1280, the smallest MTU IPv6 allows, is a conservative manual value, not one the WireGuard docs prescribe.

After the trip: delete the server and the tunnels

A trip VPN should not outlive the trip. When you are home, work through this list in order:

1. Remove the tunnel from every device. Switch off Always-on VPN or any auto-connect option first; otherwise a device may block traffic while it waits for a server that no longer exists. Then delete the tunnel in the app. After deletion the server’s IP address returns to our pool and may later be assigned to another customer, so no device should keep pointing at it.
2. Delete any snapshot you took. A snapshot is a copy of the disk, including the server’s private key.
3. Delete the server in the portal. Deletion is immediate and cannot be undone: the virtual disk is deleted, as our security page explains. It also ends billing; a last partial hour is rounded to the nearest cent.
4. Check the portal shows no active service for that server.

There is nothing to keep: next time, deploy a fresh server and repeat the seven steps with new keys and a new QR code. Our checklist before you delete a VPS covers backups, DNS records and billing checks in more detail.

Is it legal to use your own VPN abroad?

Encrypting your own traffic is legal in many countries, but some restrict or regulate VPN use, and the rules change. Check the law of every country on your route before you rely on a VPN, and follow the terms of the networks you join, such as a hotel’s or an employer’s. A VPN does not change what is legal where you are, and it is not a way around a country’s rules or a streaming service’s terms.

Our acceptable use policy applies to everything your server sends. For a trip VPN, that means:

• Your devices only. This guide builds a VPN for your own devices, not a service to share or sell. The policy makes you responsible for everything your server sends, including what anyone you let on it does.
• No open proxy. WireGuard accepts only peers whose public keys you added, so this setup is not one. Keep it that way.
• No open resolver. If you add your own DNS server, allow port 53 on the tunnel interface only.
• The usual rules still apply. Illegal content, spam and attacks are banned whichever route they take, and the policy counts the law of the country where your server sits, not only where you are.

When you are ready, a VPS rented by the day in the location nearest your trip is all this setup needs.