Plan the WireGuard lab

We will connect a laptop to an Ubuntu server. Before touching a single config file, we decide everything on paper. VPN debugging is miserable when you are guessing what the setup was supposed to look like.

Here is the plan for the whole module:

private VPN network    10.14.0.0/24
server VPN address     10.14.0.1
laptop VPN address     10.14.0.2
server listens on      UDP port 51820
public endpoint        203.0.113.10:51820
routed via the VPN     10.14.0.0/24 only — no Internet egress yet

Each choice has a reason. 10.14.0.0/24 is an RFC 1918 range that home routers rarely use, so it will not collide with the Wi-Fi networks the laptop visits. Port 51820 is the conventional WireGuard port, though any free UDP port works. And this first setup routes only the VPN subnet — a split tunnel. You can add full Internet egress after the private tunnel works. Debugging a broken default route on a machine you can only reach through that route is a special kind of pain.

Two safety rails before changing anything on the server.

First, keep the current SSH session open while changing the server. An established session keeps working through firewall mistakes that would refuse any new connection. Open it now, in a terminal you will not close:

ssh [email protected]
# leave this session running for the entire lab

Second, confirm the provider console works before touching the firewall. That out-of-band console is your recovery path if you lock yourself out of SSH entirely. Log in to it once today, so you are not discovering a broken console password during an emergency.

While you are in the provider dashboard, check whether a cloud firewall or security group sits in front of the server. UDP 51820 will need to pass through it later, and forgotten provider firewalls cause more “WireGuard doesn’t work” reports than WireGuard does.

Write the plan down somewhere you can see it. The mistake this prevents is real: picking a VPN subnet that overlaps a network one of the peers already sits on, then wondering why routes behave strangely. You chose 10.14.0.0/24 deliberately. When something fails later, you will compare reality against this plan instead of against memory.